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

[Brian Cole]

FWIW, we've seen a large shift in our userbase from UCS-2 to UCS-4 as Anaconda Python becomes the defacto Python2 interpreter in the sciences.

We still ship both UCS-2 and UCS-4 as well.

-Brian

> On Feb 6, 2016, at 5:35 AM, Marius Gedminas <marius at gedmin.as> wrote:
> 
>> On Sat, Feb 06, 2016 at 03:04:48PM +1000, Nick Coghlan wrote:
>>> 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.
> 
> And people who run build Python 2.7 with './configure && make && make install'
> 
> Why does upstream Python default to UCS-2 builds on Linux anyway?
> 
> FWIW the rationale Pyenv gave when they rejected a bug asking for UCS-4
> builds by default was "we prefer to follow upstream defaults".
> 
> Marius Gedminas
> -- 
> Some people around here wouldn't recognize
> subtlety if it hit them on the head.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig