[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

Donald Stufft donald at stufft.io
Mon Feb 1 19:30:41 EST 2016

> On Feb 1, 2016, at 6:37 PM, Matthias Klose <doko at ubuntu.com> wrote:
> On 30.01.2016 00:29, Nathaniel Smith wrote:
>> Hi all,
>> I think this is ready for pronouncement now -- thanks to everyone for
>> all their feedback over the last few weeks!
> I don't think so.  I am biased because I'm the maintainer for Python in Debian/Ubuntu.  So I would like to have some feedback from maintainers of Python in other Linux distributions (Nick, no, you're not one of these).
> The proposal just takes some environment and declares that as a standard.  So everybody wanting to supply these wheels basically has to use this environment. Without giving any details, without giving any advise how to produce such wheels in other environments. Without giving any hints how such wheels may be broken with newer environments.

I’m not sure this is true. It tells you exactly what versions of glibc and other libraries it is allowed to link against. It can link against older if it wants, it can’t link against newer.

> Without mentioning this is am64/i386 only.

First sentence: This PEP proposes the creation of a new platform tag for Python package built distributions, such as wheels, calledmanylinux1_{x86_64,i686} with external dependencies limited to a standardized, restricted subset of the Linux kernel and core userspace ABI.

Later on: Because CentOS 5 is only available for x86_64 and i686 architectures, these are the only architectures currently supported by the manylinux1 policy.

I think it’s a reasonable policy too, AMD64 is responsible for an order of magnitude more downloads than all other architectures on Linux combined (71,424,040 vs 1,086,527 in current data set). If you compare AMD64+i386 against everything else then you’re looking at two orders of magnitude (72,142,511 vs 368,056). I think we can live with a solution that covers 99.5% of all Linux downloads from PyPI.

> There might be more. Pretty please be specific about your environment.  Have a look how the LSB specifies requirements on the runtime environment ... and then ask yourself why the lsb doesn't have any real value.

Instead of vague references to the LSB, can you tell us why you think the LSB doesn’t have any real value, and importantly, how that relates to trying to determine a minimum set of binary ABI. In addition, can you clarify why, if your assertion is this isn’t going to work, can you state why it won’t work when it is working for many user’s in the wild through Anaconda, Enthought, the Holy Build Box, etc?

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160201/6fb0fb33/attachment.sig>

More information about the Distutils-SIG mailing list