Re: Three clarification questions about PEP 425 and PyPy3

On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith <[email protected]> wrote:

> On Wed, Aug 29, 2018 at 10:25 AM, Brett Cannon <[email protected]> wrote:
> >
> >
> > On Wed, 29 Aug 2018 at 01:56 Nathaniel Smith <[email protected]> wrote:
> >>
> >> On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon <[email protected]>
> 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 -- [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/YOF2UIHC345KKNWSOXONRQP6FVIWG3RB/