`twine check` should guard against `python_requires` conflicting with the wheel tags

[webknjaz]

The Issue

With the sunset of Python 2, distribution maintainers should stop producing universal wheels with (ones with py2.py3 tag).

The solution is to drop universal = 1 or turn that into 0 (pypa/packaging.python.org#726) but it's easy to miss this bit. So this results in people adding things like python_requires = >= 3.6 but still having that py2 tag in the wheels which is rather useless (and, well, incorrect).

The same could happen to platform-specific wheels specifying ABI3 with tags like abi3-py36 while having python_requires = >= 3.7, for example.

I propose improving the twine check command to detect such inconsistencies.

[asottile]

I'd like to voice my -1 -- universal just means "pure python and works on any version" and presumably will hold the same meaning when C-incompatible python 4.x rolls around. For the same reason that python_requires = <4 is bad I don't think this should be implemented.

[webknjaz]

@asottile that's what I was thinking until @gaborbernat pointed out that it's not exactly true. It is currently py2.py3 in the wheel names. How do you suggest we should lint the conflicting metadata?

[asottile]

It is true, or at at least what the documented point of --universal was: pypa/wheel@4a1b292#diff-8d068e8797e88947c320f79e856c3e16a72b730124a8f9d7031e2c4680dfa534R110-R111

the metadata isn't conflicting, pip properly handles python_requires and will only consider the wheel on appropriate python 3 versions

[webknjaz]

equates to the tag "py2.py3".

This is hinting pip to attempt downloading the wheel under Python 2. @pradyunsg seems to think that this could cause problems with the old resolver (combined with Requires-Python: >=3.6, for example) because it doesn't know how to do backtracking.

[webknjaz]

Also, I think that it's not the config for the tool producing wheels that should be linted but the resulting metadata in the wheel.

[gaborbernat]

I'd like to voice my -1 -- universal just means "pure python and works on any version" and presumably will hold the same meaning when C-incompatible python 4.x rolls around. For the same reason that python_requires = <4 is bad I don't think this should be implemented.

To achieve that intent the wheel tag this should map would need to be just py, not py2.py3 . because py2.py3 is not python 4 compatible tag.

[asottile]

It would only cause problems for pip versions that don't understand python_requires (<9) -- which at this point they have much much harder problems installing valid packages

what I'd rather see is if python2 is truly dead then wheel / pip / setuptools should stop producing py2 in the name instead of requiring me to remove valid metadata from my configuration (which I use to signal that my package is pure python) I'll have to annoyingly add back later

[asottile]

To achieve that intent the wheel tag this should map would need to be just py, not py2.py3 . because py2.py3 is not python 4 compatible tag.

I like this idea! let's push to make that happen

[gaborbernat]

I mean, either universal should start meaning py or python 3+ packages should stop using it. The current universal translation to py2.py3 means generated packages end up in an undesirable state because they are incompatible with python 2. At the same time, they contain code that works only with Python 3+.

Can we get some opinion from at least:

• @pfmoore - as BDFL for packaging
• @pradyunsg - as pip maintainer (where this tag is consumed)
• @agronholm - as wheel maintainer (where this setting is used)

Thanks!

[agronholm]

I think pypa/wheel#396 is on the right track, except that I would rather abort the operation if such a discrepancy is detected because otherwise this could go unnoticed by the users.

[pfmoore]

As packaging BDFL, the wheel spec doesn't mention "universal" at all, so I'd consider that an implementation detail of the wheel package.

From pip's POV, we consume the tags, not "universal" directly. I'd be happy if pip were to add a check that the tags and Python-Requires were consistent, but I'd see that as a quality of implementation matter. For correctness, what matters is that pip only considers wheels with supported tags, and it rejects any where Python-Requires isn't satisfied. That's well-defined behaviour even if the tags and python-requires conflict.

[agronholm]

Yep, universal is an implementation detail in the wheel package. This feature will be removed in the eventual 1.0.0 release. In the meantime, raising an error when a conflict is detected between python_requires and universal is my current game plan.