#35828: Switch to statically declaring version number in pyproject.toml
-------------------------------------+-------------------------------------
Reporter: James Bennett | Type:
| Cleanup/optimization
Status: new | Component: Packaging
Version: dev | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
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:
1. Declare the version number statically in `pyproject.toml`.
2. Use `importlib.metadata.version("Django")` (available since Python 3.8,
thus in all currently-supported Python versions for Django's `main`
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/until `pip
install -e` is re-run to update the metadata of the installation. This
seems acceptable to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/35828>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701927387dc30-43f8cf8b-ca54-434a-b907-57a947ae4acc-000000%40eu-central-1.amazonses.com.
