On Thu, 30 Aug 2018 at 11:21 Nathaniel Smith <n...@pobox.com> wrote:
> If we're going to rethink this,
>
Well, I didn't want to "rethink" so much as "fill in". :)
> 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,
>
I wouldn't expect that to if the stable ABI was expanded in Python 3.7 and
you used the expanded part.
> but if you *remove* the extension module then it *stops* working on 3.7?
> That's just bizarre...
>
I don't quite follow what you mean by "remove the extension module then it
stops". What stops by removing the extension module(s)?
>
> So my suggestions:
>
> * Make the 3 tag categories totally independent. Compute a separate set
> for each, and then take the full cross product.
>
I think Paul was hinting at this as part of his "wildcard" idea (and I
honestly thought of this initially as well as it greatly simplifies
things). So what would cp36-cp36m-plat expand to?
- cp36: cp3N where N is any positive digit(s)? And then toss in py3 and
py3N? Prefer exact, then generic '3', then older, and finally newer?
- cp36m: that, abi3, and then 'none'? Do we care if someone has some
crazy ABI that no one understands like 'b' (and if so should it only be
applied to 'py' interpreter versions which break your nice cross product
simplicity)?
- plat: depends on platform.
And the match preference goes to platform, interpreter version, and then
ABI? I *think* that would work in terms of ignoring C ABIs that have very
little chance of linking while being the broadest in terms of accepting a
wheel that has some semblance of a chance of running.
And how would that apply to PyPy3? Same ranging on 'pp36N` and drop the
'abi3' insertion?
>
> * 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.
>
What would you do then about preferred match order for pure Python wheels?
E.g. how do you preferably match against Python 3.7 wheels over 3.6 when
running a Python 3.7 interpreter? Or are you suggesting equivalent ABI tags
to make up for the pyXY tags and the interpreter tag simply gets ignored?
-Brett
>
> 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/2HPZTYE5D2AAMQ3XJZVBWCAWREWVMCWB/
