setuptools: 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''
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 33 (33 by maintainers)
Commits related to this issue
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
- Allow markers in SpecifierRequirement when specification allows it related to pypa/setuptools#1876 — committed to arcivanov/packaging by arcivanov 5 years ago
As far as I know, Core Metadata Specification is simply an aggregate view of the different PEP, cf Specification Update Process.
I’m not saying we should do nothing 😃 I’m suggesting that to solve the current issue (i.e. the fact that “
python_requiresis not compliant with PEP-345, PEP-566 and PEP-508”) and given how the different major packaging tools (setuptools,pip, PyPI/warehouseand all the other tools that relied on thepackaginglibrary) interpreted theRequires-Pythonfor 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.
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:
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.
In my opinion, and given how the main tools interpreted the existing PEP, the simplest thing to do in the short term would be to clarify/update the relevant PEPs to explain that
Requires-Pythonis only expecting aSpecifierSet.Future metadata updates (2.2 ?) could introduce this new concept with the
Possibly-Requires-Pythonand its implications.