On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Aug 29, 2018 at 10:25 AM, Brett Cannon <br...@python.org> wrote: > > > > > > On Wed, 29 Aug 2018 at 01:56 Nathaniel Smith <n...@pobox.com> wrote: > >> > >> On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon <br...@python.org> > wrote: > >> > py36 > >> > > >> > py36-none-% but not py36-none-any: 2 (example) > >> > > >> > py3 > >> > > >> > py3-none-% but not py3-none-any: 142 (example) > >> > >> Oh right, and these ones are totally sensible: this is the correct tag > >> for a project that ships some vendored shared libraries, and accesses > >> them using cffi's ABI mode, or through ctypes: it cares about the > >> CPU/OS ABI, but doesn't use the Python C ABI. >
What you say below would also suggest that Python 3.7 should support down to py30-none-% as well. > > > > > > Yep. I was just surprised that py37-none-% wasn't being emitted as > > acceptable since that technically makes sense. > > Setuptools never creates such wheels, so I guess it's not well tested. > The main reason they exist at all is that Armin Ronacher jumped > through a bunch of hoops to make it happen in his milksnake [1] > project, and it's not even a year old. > > [1] https://github.com/getsentry/milksnake > > > I think figuring out what makes sense in terms of compatibility will be > the > > toughest bit. E.g. for Python 3.7, pip will check for py37-none-any down > to > > py30-none-any as well as py3-none-any. With python_requires in metadata > well > > as the py3 interpreter tag, I'm not sure if it still makes sense to > > enumerate all the way down to py30, especially when Python doesn't follow > > strict semver. Maybe for Python 3.7 py37, py3, and py36 makes the most > sense > > by assuming code is warning-free in Python 3.6 and so should be > relatively > > safe to use in 3.7 with warnings? Otherwise I wouldn't expect e.g. 3.5 > code > > to work in 3.7 since there's new keywords that old code might break on. > > 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. > > So, it's arguably better to be optimistic and assume that all py3x > wheels will work on py3(x+k), even if it's sometimes wrong, because > when we're wrong the failure modes are more acceptable. > Quite possibly, but at this point I don't want to take anything for certain. :) I mean in the end it's just a string coming from a generator so it's cheap to include, but I just want to make sure we appropriately justify its inclusion when it's inferred versus specified.
-- 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/YOF2UIHC345KKNWSOXONRQP6FVIWG3RB/
