On 30 January 2014 20:09, Squeaky <squeaky_pl@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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia