On Thu, 30 Aug 2018 at 11:29 Donald Stufft <donald@stufft.io> wrote:


On Aug 30, 2018, at 1:59 PM, Nathaniel Smith <njs@pobox.com> wrote:

That's the theory, but I think these tags are useless in practice.

If you're on py35 and pip sees a wheel with py36 as the tag, then it falls back to building from the sdist. For ABI-related tags this makes sense, because given an sdist and an appropriate compiler, you have a good chance of being able to generate wheels for some arbitrary platform, even one that the original authors never heard of. But... the python dialect tags are different. If your wheel uses f-strings, then your sdist probably does too, so all the tag does is move around the error to happen somewhere else.

To avoid this, you have to put a Python-Requires header in your metadata. It's the only thing that works for sdists. And it also works for wheels. And it's strictly more expressive than the wheel tag version (you can write arbitrary restrictions like ">= 3.5.2, != 3.6.1". Note that 3.5.2 actually is a common minimum version for lots of async libraries, because it had a breaking change in the core async/await protocols).

So I don't think there's any case where the pyXY tags are actually useful. You're always better off using Python-Requires.

I haven’t been following this discussion very well, but forgive me for jumping in here.

I find it helpful to generally not think of compatibility tags as hard “this wheel is supported on this platform”, but more along the lines of “if I built a wheel in the specified environment, I would get the same results”. Those results may or may not work. So for example, if you have a pure Python wheel that *only* works on Python 3.5+, but it produces the same output when building the wheel on Python 3.3 (even if it doesn’t ultimately work), then a “py3” wheel is the right tag to use. Arguably you’d even use py2.py3 since you’d produce the same output (but in practice most don’t since that’s extra work).

Yep.
 

Likewise if you have a sdist that uses 2to3 to produce different outputs on py2 and py3, then you’d obviously use only py2 and py3. However if you had something that say, included different files in the wheel in 3.5+ (maybe PEP 484 .pyi files?) then it would be appropriate to use py35 for that wheel, and py30 or even py3 for the other wheel that didn’t include those files.

Agreed.
 

I’m not sure I follow Brett’s last email about the diff he’s thinking about, but that may be because I’m still waking up.

Basically I'm trying to figure out what tags pip and various tools should be matching when determining what wheel to download from PyPI (so that diff is what pip matches against now in two scenarios and how I think what is matched  against should change). The hope is this can be centralized into a library instead of being internalized in each tool like it is now.