On Sat, Jan 30, 2016 at 8:37 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Fri, Jan 29, 2016 at 11:52 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 30 January 2016 at 09:29, Nathaniel Smith <n...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
