id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35828	Switch to statically declaring version number in pyproject.toml	James Bennett		"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."	Cleanup/optimization	closed	Packaging	dev	Normal	wontfix			Unreviewed	0	0	0	0	0	0