So based on all of this, here is my proposal of what the compatible tags should become (in priority order from most to least strict). In the list below yellow means the value changed compared to the previous tag, blue means it's something I'm proposing to add, and red is something I'm proposing to remove (using what pip considers compatible tags as the base list of tags). I have left out all of the platform variances of macOS for brevity as there's no questions regarding those.

For PyPy3 6.0.0 (and any other non-CPython interpreter that reports Python 3.5 from sys.version_info, i.e. this represents the default logic for an interpreter that has no special handling):

('pp360', 'pypy3_60', 'macosx_10_13_x86_64')
('pp360', 'none', 'macosx_10_13_x86_64'),
('py35', 'none', 'macosx_10_13_x86_64')
('py3', 'none', 'macosx_10_13_x86_64'),
('py34', 'none', 'macosx_10_13_x86_64')
('py33', 'none', 'macosx_10_13_x86_64')
('py32', 'none', 'macosx_10_13_x86_64')
('py31', 'none', 'macosx_10_13_x86_64')
('py30', 'none', 'macosx_10_13_x86_64')
('pp360', 'none', 'any'),
('pp3', 'none', 'any'),
('py360', 'none', 'any'),
('py35', 'none', 'any'
('py3', 'none', 'any')
('py34', 'none', 'any')
('py33', 'none', 'any')
('py32', 'none', 'any')
('py31', 'none', 'any')
('py30', 'none', 'any')

For CPython 3.7.0 (whose logic will be unique to the CPython interpreter in the library, but other interpreters could have their own custom logic as well when it makes sense; there will be some API to just say "give me what makes sense based on this tag" so users don't have to know any of this if they don't want to):

('cp37', 'cp37m', 'macosx_10_13_x86_64'),
('cp37', 'abi3', 'macosx_10_13_x86_64'),
('cp37', 'none', 'macosx_10_13_x86_64'),
('cp36', 'abi3', 'macosx_10_13_x86_64'),
('cp35', 'abi3', 'macosx_10_13_x86_64'),
('cp34', 'abi3', 'macosx_10_13_x86_64'),
('cp33', 'abi3', 'macosx_10_13_x86_64'),
('cp32', 'abi3', 'macosx_10_13_x86_64'),
('py37', 'none', 'macosx_10_13_x86_64')
('py3', 'none', 'macosx_10_13_x86_64'),
('py36', 'none', 'macosx_10_13_x86_64')
('py35', 'none', 'macosx_10_13_x86_64')
('py34', 'none', 'macosx_10_13_x86_64')
('py33', 'none', 'macosx_10_13_x86_64')
('py32', 'none', 'macosx_10_13_x86_64')
('py31', 'none', 'macosx_10_13_x86_64')
('py30', 'none', 'macosx_10_13_x86_64')
('cp37', 'none', 'any'),
('cp3', 'none', 'any'),
('py37', 'none', 'any'),
('py3', 'none', 'any'),
('py36', 'none', 'any'),
('py35', 'none', 'any'),
('py34', 'none', 'any'),
('py33', 'none', 'any'),
('py32', 'none', 'any'),
('py31', 'none', 'any'),
('py30', 'none', 'any')]

On Thu, 30 Aug 2018 at 09:03 Daniel Holth <dholth@gmail.com> wrote:

It's not an intuitive system. We have wheel tags to choose the best alternative wheel or fall back to sdist. So py3-none-any is fine for f-strings if no other candidate wheel (a list of all available wheels for the same version number of a package) has been compiled to not require f-strings. The tag only has to tell you which wheel is most likely to work.

No sdist or wheel is ever guaranteed to work, for any number of reasons.

On Aug 30, 2018 11:25, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On Thu, 30 Aug 2018 at 09:58, Brett Cannon <brett@python.org> wrote:
> On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <njs@pobox.com> wrote:
>> 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.
>
> Right, but isn't that what the py3-none-any tag is meant to represent? If someone doesn't use that tag then I would take that as there is some version-specific stuff in that wheel.

The problem is that "py3-none-any" doesn't specify a *minimum*
version, so if a project starts using a new feature like f-strings,
they *have* to declare "py36-...".

So even though it isn't what PEP 425 actually says, in practice it's
turned out to be more useful to interpret the Python version tag as
being "version X.Y or later", and only interpret the ABI tag strictly.
That philosophy also makes the "abi3" ABI tag more coherent, since it
means that the "pyXY" part also specifies the minimum required ABI
version.

The marker for "exact version required" could then be to nominate a
specific Python implementation, rather than using the "py" prefix - so
a hypothetical wheel builder could use "cp36-none-any" for a
bytecode-only wheel archive that *only* ran on CPython 3.6, and
wouldn't be portable to other versions or implementations.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-leave@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/FJGFRPQUMAZZ35TONE7JPTGK74PHFKFI/