[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions
Nate Coraor
nate at bx.psu.edu
Fri Feb 5 12:35:02 EST 2016
On Sat, Jan 30, 2016 at 3:37 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Jan 29, 2016 at 11:52 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 30 January 2016 at 09:29, Nathaniel Smith <njs at pobox.com> wrote:
> >> Hi all,
> >>
> >> I think this is ready for pronouncement now -- thanks to everyone for
> >> all their feedback over the last few weeks!
> >>
> >> The only change relative to the last posting is that we rewrote the
> >> section on "Platform detection for installers", to switch to letting
> >> distributors explicitly control manylinux1 compatibility by means of a
> >> _manylinux module.
> >
> > In terms of the proposal itself, I think this version is excellent :)
> >
> > However, I realised that there's an implicit assumption we've been
> > making that really should be spelled out explicitly: manylinux1 wheels
> > targeting CPython 3.2 and earlier need to be compiled against a
> > CPython built in wide Unicode mode, and in those cases, the detection
> > of manylinux1 compatibility at the platform level should include
> > checking for "sys.maxunicode > 0xFFFF".
>
> Doh, excellent catch!
>
> I've just pushed the obvious update to handle this directly to the
> copy of the PEP in the manylinux repository.
>
> Diff:
> https://github.com/manylinux/manylinux/commit/2e49cd16b89e0d6e84a5dc98ddb1a916968b73bc
>
> New text in full:
>
> https://raw.githubusercontent.com/manylinux/manylinux/2e49cd16b89e0d6e84a5dc98ddb1a916968b73bc/pep-513.rst
>
> I haven't sent to the PEP editors, because they already have another
> diff from me sitting in their inboxes and I'm not sure how to do this
> in a way that doesn't confuse things :-)
>
Now that pip and wheel both support the Python 3 SOABI tags on 2.X, is this
necessary? The ABI tag should be set correctly on both the build and
installation systems, so is including it as part of the manylinux1 ABI (and
fixing it to wide builds only) overkill?
--nate
>
> > The main reason we need to spell this out explicitly is that while
> > distros (and I believe other redistributors) build CPython-for-Linux
> > in wide mode as a matter of course, a Linux checkout of CPython 2.7
> > will build in narrow mode by default.
>
> I can confirm that Debian and Anaconda builds of CPython 2.7 both have
> sys.maxunicode == 0x10ffff, but Enthought Canopy has sys.maxunicode ==
> 0xffff. Hmm. I guess they should fix that.
>
> Also the manylinux docker image currently has sys.maxunicode ==
> 0xffff, so we should definitely fix that :-).
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160205/b03af3a0/attachment.html>
More information about the Distutils-SIG
mailing list