python_requires is not compliant with PEP-345, PEP-566 and PEP-508

Currently python_requires only accepts a version specifier per PEP-440. This is an error.

Pursuant to PEP-345, as sustained in PEP-566, the specification regarding environmental markers is as follows:

The fields that benefit from this marker are:

Requires-Python
Requires-External
Requires-Dist
Provides-Dist
Obsoletes-Dist
Classifier

PEP-566 further sustains this specification:

Usage of environment markers is otherwise unchanged from PEP 345.

Thus, according to PEP-345, PEP-566 and PEP-508 it should be possible to specify an extremely narrow constraint such as:

python_requires = ==3.9.1; implementation_name=='cpython' and implementation_version=='3.9.1b2'.

As of setuptools 41.4.0 this is an error:

setuptools.extern.packaging.specifiers.InvalidSpecifier: Invalid specifier: '<3.9;implementation_name=='cpython''

[xavfernandez]

I was under impression from @ncoghlan’s explanation that PEP-566 removed the metadata out of the PEP process and delegated it to Core Metadata Specification to avoid PEP process for every metadata update.

As far as I know, Core Metadata Specification is simply an aggregate view of the different PEP, cf Specification Update Process.

Are you saying we should just do nothing right now? If you don’t mind me asking, why?

I’m not saying we should do nothing 😃 I’m suggesting that to solve the current issue (i.e. the fact that “python_requires is not compliant with PEP-345, PEP-566 and PEP-508”) and given how the different major packaging tools (setuptools, pip, PyPI/warehouse and all the other tools that relied on the packaging library) interpreted the Requires-Python for the last 3 years, we should simply clarify/update the PEPs to match its defacto interpretation.

And it doesn’t mean that we should not investigate new ways to specify finer metadata regarding the required python version depending on the interpreter environment but it is likely to need new fields, a new metadata version and some PEP related work.

[ncoghlan]

Fixing this definitely seems worthwhile to me, as it’s not uncommon for projects to be affected by platform-specific standard library limitations that mean they’ll need a newer base Python version in some environments. It also means that a project affected by a regression in a new feature release can clearly indicate that in their metadata:

python_requires = >=3.8.1; python_version=='3.8'

To be fully effective, it would need to be possible to supply multiple python_requires entries, merging the entries that share the same environment marker text.