If we're going to rethink this, then I would really like to move away from
assigning special meaning to specific combinations of tags. The thing where
if you use cp36m as you Python ABI tag then you're forced to use cp36 as
your python dialect tag doesn't make sense. And the thing where if you have
a wheel with an extension module tagged as cp36-abi3, then that works fine
on 3.7, but if you *remove* the extension module then it *stops* working on
3.7? That's just bizarre...
So my suggestions:
* Make the 3 tag categories totally independent. Compute a separate set for
each, and then take the full cross product.
* Since the stable ABI actually changes over time, we should define new
tags abi35, abi36, etc. that mean "requires the stable ABI as defined by
this version of cpython or higher", instead of relying on abi3 + a dialect
tag. (Imagine if pypy started implementing the stable ABI –we'd have to
start allowing cpXY tags to match PyPy.)
* Plan to move away from the pyXY and cpXY tags over time; they're
confusing and not useful. Of course this will have to be a gradual process,
but if pip stops requiring them now then in a year or two we could make
setuptools stop generating then.
On Thu, Aug 30, 2018, 09:26 Brett Cannon <br...@python.org> wrote:
> 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 <dho...@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" <ncogh...@gmail.com> wrote:
>>
>> On Thu, 30 Aug 2018 at 09:58, Brett Cannon <br...@python.org> wrote:
>> > On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <n...@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 | ncogh...@gmail.com | Brisbane, Australia
>>
>> --
>> Distutils-SIG mailing list -- distutils-sig@python.org
>> To unsubscribe send an email to distutils-sig-le...@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/
>>
>>
>> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@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/6IN774Z4NRGXZJ7TQRURYNON7OARP3XC/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@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/D74QUO556IB3RN3GTQXCYGDRQJAKIHLX/
