On 6 February 2016 at 03:53, Nate Coraor <n...@bx.psu.edu> wrote: > On Fri, Feb 5, 2016 at 12:46 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Feb 5, 2016 8:47 AM, "Nate Coraor" <n...@bx.psu.edu> wrote: >> > >> [...] >> > - Add SOABI tags to platform-specific wheels built for Python 2.X (Pull >> > Request >> > #55, Issue #63, Issue #101) >> >> I can't quite untangle all the documents linked from this PR, so let me >> ask here :-). Does this mean that python 2.x extension wheels now can and >> should declare whether they're assuming the 16- or 32-bit Unicode ABI inside >> the abi field? And if so, should PEP 513 be updated to allow for both >> options to be used with manylinux1? (Right not manylinux1 just >> implies/requires a UCS4 build, for older pythons where this matters.) > > It isn't declared, wheel determines the ABI of the interpreter upon which > the wheel is being built and tags it accordingly. So yes, I think a PEP 513 > update is appropriate.
+1 from me, since it's a genuine bug in the current specification. > As to whether the manylinux1 Docker images should > include UCS-2 Pythons is a separate question, though. If there's interest, I > can provide statistics of how many of Galaxy's UCS-2 Linux eggs were > downloaded over time. While I'd be interested in those stats, my initial inclination is to say "No" to including narrow Unicode runtimes in the build environment, as: 1. Python 2.7 narrow Unicode builds really don't handle code points >= 65,535 correctly 2. Python 3.3+ doesn't have the narrow/wide distinction 3. Canopy users will presumably be getting most of their binaries from Enthought, not PyPI That means the only folks that seem likely to miss out on pre-built binaries this way would be Python 2.7 pyenv users. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
