IMO, please do merge it, but I will say again that I think it is very much short of this discussion (ignoring the thoughts on mid-/longterm improvements). It would be nice if there was even a semi-authoritative place to discourage it even when it is 100% correct conceptually such as in the case for NumPy. The documentation could be that.
+1 to what @seberg suggests.
I’d also add that this there should be a way to have the upper bounds in metadata at some point - either in this field, or in a new to-be-created field. This metadata is definitely relevant, just not for the current state of pip
, Poetry & co that are unable to solve for Python version. When working towards metadata that is actually representative of the package itself, rather than only how it’s built for distribution on PyPI, this is a current gap / pain point. Having downstream distro packagers derive the upper bound empirically from the cp3xx
wheels that are present on PyPI for a given release rather than looking at a metadata file is not great. And with PyBIs or another such solution for packaged Python releases, it may be relevant for PyPI-focused tools in the future as well.
@henryiii Thanks for bringing up this topic. I was curious if this thread ever landed on a solution/decision.
We are in a situation now where tools like uv
and Poetry have diverged.
uv
discards requires-python
upper bounds
- Resolver | uv
- Consider discarding `< 4` upper-bound on `Requires-Python` · Issue #4022 · astral-sh/uv · GitHub
But Poetry respects it (though as of 2.0, the published requires-python
can be separated from the resolver requires-python
)
- The pyproject.toml file | Documentation | Poetry - Python dependency management and packaging made easy
- Remove upper bound checking on Python version · Issue #10136 · python-poetry/poetry · GitHub
I took me quite a while to dig through threads and issues to get to the bottom of this, and I worry the backtracking issue can still be a tripping point for new developers.
I can appreciate the Poetry team’s reluctance to change behavior before the standard is changed. Perhaps it’s time to consider changing the standard?
I plan to write a pre-PEP in the next couple of months that formalizes the semantics of Requires-Python
, based on the discussion in https://discuss.python.org/t/requires-python-and-pre-release-python-versions/62959
It will specify the semantics as only being the language version part of the version string, i.e. 3.10, 3.11, so not something like 3.11.1, and that the only valid operators as “>”, “>=”, and “!=”, and that tools should warn users when they find requires Python strings that don’t match this, and may throw an error (I’m thinking specifically of tools that build source trees).
We’ll see if it achieves consensus and is accepted.