Opened 2 months ago
Closed 8 weeks ago
#35828 closed Cleanup/optimization (wontfix)
Switch to statically declaring version number in pyproject.toml
Reported by: | James Bennett | Owned by: | |
---|---|---|---|
Component: | Packaging | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django's version number is currently declared as the tuple django.VERSION
, which is then processed into a PEP-440-compliant version string by django.utils.version.get_version()
to set the attribute django.__version__
, which is then dynamically read by setuptools during packaging to declare the version number of the package.
This is mostly a historical relic of days when the packaging ecosystem was less robust and less standardized; today, while we can use a complex dynamic-attribute scheme to set Django's version number, we don't need to. Instead, we can:
- Declare the version number statically in
pyproject.toml
. - Use
importlib.metadata.version("Django")
(available since Python 3.8, thus in all currently-supported Python versions for Django'smain
branch) anywhere Django's version number is needed in code.
For backwards compatibility, for a couple of releases django.utils.version.get_version()
could be updated to return the result of importlib.metadata.version("Django")
and could be used to set a django.__version__
attribute. Although the long-term goal should be to remove both get_version()
and __version__
entirely, directing users who want to programmatically access Django's version number to importlib.metadata.version()
.
The main tradeoffs here are:
importlib.metadata.version()
raises an exception if the requested package is not installed, so use cases of "installing" Django without actually having a standards-compliant Python package manager install it would not be able to read the version number. The two primary cases here are "vendoring" Django as a directory, and non-Python packaging and distribution systems, such as Django being packaged by a Linux distribution. Vendoring is a case that I'm not sure needs to be supported to that extent, and Linux distributions presumably have their own package-metadata systems they'd want to use in place of the Python-specific tooling.- An editable install of Django would continue to report the version number as it existed at the time of
pip install -e
unless/untilpip install -e
is re-run to update the metadata of the installation. This seems acceptable to me.
Change History (2)
comment:1 by , 2 months ago
comment:2 by , 8 weeks ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Hello James! Thank you for the ticket and for proactively starting the forum thread. Given the existing ticket triage policy, I have to close this as wontfix
until the forum post demonstrates clear consensus, which is not yet the case.
I'll keep an eye on it though!
Forum thread:
https://forum.djangoproject.com/t/setting-djangos-version-statically-35838/35549