[Catalog-sig] PEP 425 / 427 compatibility tags
dholth at gmail.com
Fri Mar 1 21:25:52 CET 2013
On Fri, Mar 1, 2013 at 11:37 AM, PJ Eby <pje at telecommunity.com> wrote:
> On Fri, Mar 1, 2013 at 4:24 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 01.03.2013 10:02, Reinout van Rees wrote:
>>> On 28-02-13 21:08, holger krekel wrote:
>>>>> I have seen that position in this discussion ("I have to upload 120
>>>>> >files per release, so I won't do that", for instance).
>>>> haven't seen that.
>>> Marc-Andre Lemburg said this, which I took to mean 120 uploads per release:
>>> However, taking our egenix-mx-base package as example, we have
>>> 120 distribution files for every single release. Uploading those
>>> to PyPI would not only take long, but also ...
>> Correct, with a total of over 100MB per release. However, the above
>> quote is slightly incorrect: I did not say "I won't do that", just
>> that there are issues with doing this:
>> * It currently takes too long uploading that many files to
>> PyPI. This causes a problem, since in order to start the upload,
>> we have to register the release on PyPI, which tools will then
>> immediately find. However, during the upload time, they won't
>> necessarily find the right files to download and then fail.
> Actually, easy_install doesn't pay any attention to what releases are
> registered. It just looks for primary and secondary links. If there
> are links for a version that it can use, it uses it. If it does not
> find links for a version, then that version does not exist, as far as
> it is concerned. So registering without files is not a problem.
>> The proposed pull mechanism (see
>> would work around this problem: tools would simply go to
>> our servers in case they can't find the files on PyPI.
> That proposal is unnecessary, actually. You could *right now* simply
> place binary download links (with optional "#md5=...." verification)
> in your package's description field, and the moment you registered the
> package, existing tools would find those links and download them from
> your site. You could then remove your home page and download URLs
> from the relevant fields, and place them also in the description.
> (easy_install does not follow non-download links within the
> description -- i.e., links that don't end in .egg, .tgz, etc. and
> don't have an #egg tag.)
>> * PyPI doesn't allow us to upload two egg files with the same
>> name: we have to provide egg files for UCS2 Python builds and
>> UCS4 Python builds, since easy_install/setuptools/pip don't
>> differentiate between the two variants.
> They can if it's part of the platform string; the catch is that right
> now it's not. We'd have to go through an upgrade cycle of the tools
> to support that. I need to take a look at what PEP 427 is doing (and
> you should too, if you haven't already) to get this part sorted out.
The compatibility tags are specified in
http://www.python.org/dev/peps/pep-0425/ and are first used with PEP
427. The scheme defines a tag which is a combination of
implementation, abi, and platform tags, and an algorithm for choosing
the "most preferred" among the available builds for a particular
release of some distribution.
The ABI tags are basically abbreviated versions of the tags from
http://www.python.org/dev/peps/pep-3149/ and look like "cp32dmu" for a
debug, malloc, wide unicode build of CPython 3.2, or just "cp32" for a
Python 3.2 with none of those features compiled in. Your package would
probably use tags like "cp32-cp32mu-linux_x86_64".
Even though PEP 3149 is a Python 3.2 feature, the *PEP 425* ABI tags
are supposed to work in the same way with older version of Python,
e.g. "py26u" for a Python 2.6 unicode build.
More information about the Catalog-SIG