[Django] #35828: Switch to statically declaring version number in pyproject.toml

[Django]

#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.

[Django]

#35828: Switch to statically declaring version number in pyproject.toml
-------------------------------------+-------------------------------------

Reporter: James Bennett | Owner: (none)
Type: | Status: new
Cleanup/optimization |
Component: Packaging | Version: dev
Severity: Normal | Resolution:

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by James Bennett):

Forum thread:

https://forum.djangoproject.com/t/setting-djangos-version-
statically-35838/35549
--
Ticket URL: <https://code.djangoproject.com/ticket/35828#comment:1>

[Django]

#35828: Switch to statically declaring version number in pyproject.toml
-------------------------------------+-------------------------------------
Reporter: James Bennett | Owner: (none)

Type: | Status: closed

Cleanup/optimization |
Component: Packaging | Version: dev

Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* resolution: => wontfix
* status: new => closed

Comment:

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!
--
Ticket URL: <https://code.djangoproject.com/ticket/35828#comment:2>