Should Django Use a Static Version Declaration in pyproject.toml?

I've raised a discussion in the Django ticket #35828 (Switch to statically declaring version number in pyproject.toml) and started a forum thread in advance of potential controversy. I'm an ex-release manager, and I believe the current dynamic version lookup exists because older Python packaging tools required embedding the version at the module level. Nowadays, with the standard library API provided by

PYTHONCopied
importlib.metadata.version("Django")

available in all Python versions supported by Django's main branch, projects can easily access their installed version number without dynamic hacks.

I propose that Django, for a few more releases, use django.version (and django.utils.version.get_version()) to simply call importlib.metadata.version() and read the static version from pyproject.toml.

This change might affect a few cases:

• Vendoring or non-standard installations of Django would now raise an exception when trying to retrieve the version, which I think is acceptable since such installations aren’t covered by our docs.

• Editable installs would work, but if you change the version in pyproject.toml, you’d need to re-run pip install -e to update the reported version. I consider this a rare edge case.

• Linux distributions or non-Python packagers would need to patch in-code references to the version, as importlib.metadata.version() wouldn’t pick up distro-specific metadata. This might streamline their process by pushing toward standardized metadata declarations.

Overall, I feel that this move would encourage using updated, simpler packaging tools while maintaining compatibility.

What are your thoughts?