Remove upper bound checking on Python version

[johnthagen]

Issue Kind

Change in current behaviour

Description

Remove upper bound checking on the requires-python and python version specifier for a Poetry project. There is a lot of practical experience that shows upper bounds on Python versions can lead to difficult situations when managing Python dependencies. This thread has a good discussion about them:

• https://discuss.python.org/t/requires-python-upper-limits/12663

One practical one that comes up is how Poetry's upper bounds on the Python version becomes "viral". If I depend on a package with an upper bound on the Python version, then I must also add that upper bound to my package or else Poetry won't resolve it (falling back potentially to an old version of the dependency otherwise). This then can trigger other packages using Poetry and so on.

Edit: The issue above can be solved in Poetry 2: https://python-poetry.org/docs/pyproject/#requires-python

uv has already removed requires-python upper bound checking:

• Add Requires-Python upper bound behavior to the docs astral-sh/uv#10964

Poetry took a small step toward this as well

• default python requirement to >= #9558

I'd propose that it would be a net benefit to follow uv's position here in Poetry as well.

Impact

Users relying on upper bounds of Python version could be impacted. Since Python 4.0 is no where in planning (may never happen) the old default Poetry packages that add this likely had little actual effect/meaning.

[dimbleby]

iMO: if you think the rules are wrong, take it to the packaging authority and get those rules changed.

fwiw, uv has plenty of issue reports from people who are surprised by their choice to ignore those rules.

[dimbleby]

astral-sh/uv#4022 is probably the most useful uv link, both for discussion and for links to many of the resulting issue reports.

[radoering]

One practical one that comes up is how Poetry's upper bounds on the Python version becomes "viral". If I depend on a package with an upper bound on the Python version, then I must also add that upper bound to my package or else Poetry won't resolve it (falling back potentially to an old version of the dependency otherwise). This then can trigger other packages using Poetry and so on.

You are describing the situation with Poetry 1. With Poetry 2, you must not define an upper bound for project.requires-python if you depend on a package with an upper bound. You must only define an upper bound for tool.poetry.dependencies.python. See the docs for an example.

As some of the linked uv issues show, ignoring upper bounds might also be suprising and unwanted so maybe we should just promote not defining an upper bound in project.requires-python more?

[dimbleby]

If you need an upper bound for locking, but do not want to define an upper bound in your package metadata, you can omit the upper bound in the requires-python field and add it in the tool.poetry.dependencies section.

I hadn't realised this was done, very nice. This is one of the things that folk keep wishing for in the many linked discussions.

So it seems to me that poetry 2.0 is already an excellent citizen here:

• default requires-python is uncapped
• has a non-infectious solution if it encounters an incompatible upper bound during locking

I agree that having the help and docs unambiguously recommend that non-infectious solution, rather than simply noting that it is possible, would be reasonable.

Edit: actually it pretty much does that already, I don't know that I even see anything to change. See also faq

[johnthagen]

With Poetry 2, you must not define an upper bound for project.requires-python if you depend on a package with an upper bound. You must only define an upper bound for tool.poetry.dependencies.python. See the docs for an example.

Okay, cool that helps with the viralness problem for packages.

I still find it unfortunate that there is a DRY issues with the Python versions, for example:

[project]
name = "test"
version = "1"
requires-python = ">=3.10"
dependencies = [
    "parsita",
]

[tool.poetry]
package-mode = false

Will lock an old 1.4.1 version of parsita because it uses Poetry's old default which defaults to <4.0 in its Requires-Python

• https://pypi.org/project/parsita/2.2.1/#description

So for applications that use Poetry as the dependency manager, to be safe and ensure that one of their many dependencies doesn't back track in the future if one adds an upper bound, it seems like one should always add something like:

[project]
name = "test"
version = "1"
requires-python = ">=3.10"
dependencies = [
    "parsita",
]

[tool.poetry]
package-mode = false

[tool.poetry.dependencies]
python = ">=3.10,<4.0"

Which feels a bit unfortunate still since it requires updating a minimum Python version twice. But I do understand why Poetry has taken this position, even if I feel the standard leads to a poor user experience in real life. I suppose this is why uv dropped upper bounds on Python entirely.

I suppose I can ask on Discourse if this can be reconsidered at a standards level.

[dimbleby]

if it is important to you that parsita supports python 4.0 - or allows you to lock while using python 4.0 - then submit a merge request at that repository.

As I said in #9558 this seems to me quite unimportant.

But anyway: now that poetry will not force anyone to put caps in their metadata if they do not want to - and will default to an uncapped python requirement - I expect that some combination of

• people like you sending merge requests to projects where a cap annoys them
• just waiting for the new default to spread

should be sufficient to see accidental upper bounds gradually disappear.

Again at risk of repeating myself: I do not believe - in spite of the uv precedent - that solvers taking it upon themselves to guess that maintainers meant something different than what they wrote is the right approach.

[johnthagen]

Tracking community progress on this, a PEP is planned to be submitted in the coming months to, among other things, removes upper bounds on requires-python:

• https://discuss.python.org/t/requires-python-upper-limits/12663/84