[Distutils] Letting the Python implementation produce the Python ABI tag

Nick Coghlan ncoghlan at gmail.com
Sat Feb 1 03:14:20 CET 2014

On 30 January 2014 20:09, Squeaky <squeaky_pl at gmx.com> wrote:
> Hi!
> This is my first message to this mailing list. I saw a discussion about
> construction of SOABI and I thought that it might be tiresome to keep code
> to produce that for every possible Python implementation in wheel
> generators. After all it's the Python implementation that knows better in
> which version and why they broke binary ABI.
> Let's say that PyPy 2.2 has this tag set to pp22 but they might have
> released PyPy 2.3 without breaking the ABI and prefer to advertise PyPy2.3
> as pp22 compatible thus reducing the number of wheels a python package
> maintainer has to produce. The ABI is separate from releases.
> Also this would benefit if there were new Python implementations coming into
> ecosystem and they could have a function in their stdlib that advertises
> their abi level. This would allow these new implementations to work with
> wheels instantly.
> Does it make sense or it's an utopia?

It's not utopia, it's the way Python 3.2+ works on POSIX systems (due
to http://www.python.org/dev/peps/pep-3149/). The compatibility
problem is mainly posed by the python.org Windows builds and any
versions prior to 3.2, as those *don't* implement
"sysconfig.get_config_var('SOABI')" correctly, so we're going to have
to come up with a different solution (hopefully one that will also
sensibly handle other implementations that don't yet provide the SOABI
config var).

PEP 425 also defines some specific abbreviations for CPython, PyPy,
IronPython and Jython to help avoid filenames getting excessively long
in the typical case, but the underlying concept is still based on the
SOABI tag introduced in PEP 3149.


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

More information about the Distutils-SIG mailing list