[Catalog-sig] PEP 425 / 427 compatibility tags

[Daniel Holth]

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
>>   http://wiki.python.org/moin/PyPI/DownloadMetaDataProposal)
>>   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.