On Wed, Aug 29, 2018 at 10:25 AM, Brett Cannon <brett@python.org> wrote:
>
>
> On Wed, 29 Aug 2018 at 01:56 Nathaniel Smith <njs@pobox.com> wrote:
>>
>> On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon <brett@python.org> wrote:
>> > py36
>> >
>> > py36-none-% but not py36-none-any: 2 (example)
>> >
>> > py3
>> >
>> > py3-none-% but not py3-none-any: 142 (example)
>>
>> Oh right, and these ones are totally sensible: this is the correct tag
>> for a project that ships some vendored shared libraries, and accesses
>> them using cffi's ABI mode, or through ctypes: it cares about the
>> CPU/OS ABI, but doesn't use the Python C ABI.

>
>
> Yep. I was just surprised that py37-none-% wasn't being emitted as
> acceptable since that technically makes sense.

Setuptools never creates such wheels, so I guess it's not well tested.
The main reason they exist at all is that Armin Ronacher jumped
through a bunch of hoops to make it happen in his milksnake [1]
project, and it's not even a year old.

[1] https://github.com/getsentry/milksnake

> I think figuring out what makes sense in terms of compatibility will be the
> toughest bit. E.g. for Python 3.7, pip will check for py37-none-any down to
> py30-none-any as well as py3-none-any. With python_requires in metadata well
> as the py3 interpreter tag, I'm not sure if it still makes sense to
> enumerate all the way down to py30, especially when Python doesn't follow
> strict semver. Maybe for Python 3.7 py37, py3, and py36 makes the most sense
> by assuming code is warning-free in Python 3.6 and so should be relatively
> safe to use in 3.7 with warnings? Otherwise I wouldn't expect e.g. 3.5 code
> to work in 3.7 since there's new keywords that old code might break on.

This is a tricky decision. Any time a new Python comes out, some
existing wheels will continue to work fine, and some will be broken.
One goal is to avoid installing broken wheels. But, there's also
another consideration: if we're too conservative, then with every
release we create a bunch of make-work as projects have to re-roll old
wheels that would have worked fine, and some percentage of projects
won't do this (e.g. b/c they're abandoned), and we lose them forever.
Also, for the py3x tags in particular, if the wheel fails on py3(x+1),
then the sdist probably will too, so it's not like we have any useful
fallback.

So, it's arguably better to be optimistic and assume that all py3x
wheels will work on py3(x+k), even if it's sometimes wrong, because
when we're wrong the failure modes are more acceptable.