[Distutils] SOABI for Unicode ABI on 2.x (was: wheel 0.27.0 released)

Nick Coghlan ncoghlan at gmail.com
Sat Feb 6 00:04:48 EST 2016

On 6 February 2016 at 03:53, Nate Coraor <nate at bx.psu.edu> wrote:
> On Fri, Feb 5, 2016 at 12:46 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Feb 5, 2016 8:47 AM, "Nate Coraor" <nate at 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.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list