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