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 <n...@pobox.com> wrote: > On Thu, Aug 30, 2018, 08:23 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-...". >> > > 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 -- 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/K72BHTS6S3JX2U7BWYVDK2EZB3ZY3VI4/ >
-- 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/NY77HNUPMLLZIDZRBMHHEALSCHUXNPTE/
