Each project should have autonomy over Python version restrictions

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the FAQ and general documentation and believe that my question is not already covered.

Background

Poetry has been mainstream for a while now, and the world is a better place for it… but what we’re observing is that there are a world of really great and stable libraries out there which aren’t actively maintained, and will always be slow to bump their max-python-version constraint, but are nevertheless working great on newer versions of Python - to the joy of developers. Yet, despite the fact that libraries just work with no changes, the project consuming these projects have zero resource to actually use them - unless we fork the project and bump the version constraints ourselves.

It is right and proper that every library builds in a python restriction of <[whatever-is-not-out-yet], but that best practice does not actually mean that the library won’t work on the newer version. Months later, everyone is doing exactly the right thing: the python-core team are adding new features that are generally backwards-compatible, and the library was built using features that are all still supported in the latest version.

Feature Request

When all is working perfectly, can we allow consumers of perfectly-compatible dependencies to just ‘tell’ poetry that the library in question is indeed compatible?

The parent project is taking responsibility for end-to-end testing and presumably can also take responsibility for declaring that a sub-project is indeed compatible-enough with the newer version of Python in order to not force a hard failure during dependency resolution.

It is correct for each repo to declare which versions have and have not been tested - but it’s also right that consumers should be able control their own declarations of python compatibility.

Proposal

Allow pyproject to override the max python version of a specific dependency, or (since our project already defines the desired python version constraint), simply specify ignore or inherit as the python constraint.

Sample case:

• https://github.com/MeltanoLabs/tap-github/pull/162#issuecomment-1293749751

[brettcannon]

I don’t think fixating on major vs minor Python versions is useful – maybe @brettcannon or someone else from CPython wants to weigh in, but the general stance of the core contributors has been that the major version number is as meaningful as Linux’s (that is to say, there will be no more transitions like 2 -> 3 and it’s mostly meaningless).

We don’t even know what a 3 -> 4 transition would look like as we haven’t even agreed if we will ever even do one. 😁 All I can say is we will never do anything as drastic as 2 -> 3 and there will be a migration path for many years if we ever do a 3 -> 4 that has significant changes.

1. do not constrain Requires-Python based on a test matrix, but instead hard incompatibility only (e.g. Python extension ABI incompatibility)

This is definitely the advice I give anyone: just specify what you definitely won’t work with and then leave it open-ended otherwise as you may work with other versions.

[aaronsteers]

Thanks, @brettcannon ! Super helpful. 🙏