[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

David Cournapeau cournape at gmail.com
Mon Feb 1 07:51:30 EST 2016


On Sat, Jan 30, 2016 at 8: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 :-)
>
> > 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.
>

Yes, they should :) I am not sure why it was built this way (before my
time), it is unfortunately not easy to fix when you have a large existing
customer base.

David


> 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/20160201/00b868bb/attachment.html>


More information about the Distutils-SIG mailing list