Re: Three clarification questions about PEP 425 and PyPy3

As far as I know no one has released a compiler that turns f-strings into
not-f-strings. If something like that existed, then you could have two
wheels for the same software, one that had been passed through the compiler
to remove f-strings and gain compatibility with older Python. If you were
doing something like that then the pyXY tag becomes useful. Python-Requires
is more useful for the ordinary case.
The arch-only tags are an example of something we had to add because a
previously theoretical case became real.
It is a little silly but harmless to go all the way down to py30. Python
3.2 or 2.6 were perhaps the oldest Pythons bdist_wheel could ever run on
(2012).

On Thu, Aug 30, 2018 at 2:01 PM Nathaniel Smith <[email protected]> wrote:

> On Thu, Aug 30, 2018, 08:23 Nick Coghlan <[email protected]> wrote:
>
>> On Thu, 30 Aug 2018 at 09:58, Brett Cannon <[email protected]> wrote:
>> > On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <[email protected]> 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-...".
>>
>
> 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.
>
> -n
> --
> Distutils-SIG mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/[email protected]/message/K72BHTS6S3JX2U7BWYVDK2EZB3ZY3VI4/
>

--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/NY77HNUPMLLZIDZRBMHHEALSCHUXNPTE/