IMO implementation names should be compatible with PEP-421.
Also instead of a cryptic long string, maybe some structured one?. For example (JSON): {"implementation":"cpython","machine":"x86_64"}
It's longer but more readable IMO (and easier to parse).
On Wednesday, July 25, 2012 7:55:34 AM UTC-7, Daniel Holth wrote:I am working on a specification that might be useful in the PKG-INFO
Platform or Supported-Platform tags. It tries to express which Python
versions a built distribution works on with a triple
(Implementation+Language Version, ABI, Architecture), anticipating an
ABI that is not tied to a single CPython release.
A typical tag would be py27-noabi-noarch or cp33-cp33dmu-linux_x86_64.
cp27-noabi-noarch is a package that requires CPython 2.7 but doesn't
include extension modules.
The Python implementation is abbreviated. Each implementation has a
two-letter code:
py: Generic Python
cp: CPython
ip: IronPython
pp: PyPy
jy: Jython
concatenated with py_version_nodot “27”. The minor version can be
omitted “py2” or “py3” when appropriate.
The ABI tag is an abbreviated SOABI “cp33m”, or, for “pure Python”
packages, “noabi”. For pypy it was more or less suggested that the ABI
would have to be a hash of the source code revision and the
translation/compilation options.
The platform tag is distutils.util.get_platform() with all periods and
hyphens replaced with underscore, or the string ‘noarch’.
I use the term "built distribution" instead of "binary distribution"
because it includes pure python packages that for example have had
2to3 run ahead of time and are installable without setup.py.
Will it work? The ABI in particular may be so messy that it should be lumped with architecture. What is the ABI for packages that use ctypes or cffi?