Opened 5 days ago

Closed 3 days 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:

  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.

Change History (2)

comment:2 by Natalia Bidart, 3 days ago

Resolution: wontfix
Status: newclosed

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!

Note: See TracTickets for help on using tickets.
Back to Top