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

[Marius Gedminas]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160206/d075a009/attachment.sig>