[Distutils] SOABI for Unicode ABI on 2.x (was: wheel 0.27.0 released)
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
1. Python 2.7 narrow Unicode builds really don't handle code points >=
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