[Distutils] draft PEP: manylinux1

Donald Stufft donald at stufft.io
Thu Jan 21 15:21:55 EST 2016

> On Jan 21, 2016, at 3:14 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jan 21, 2016 at 11:54 AM, Matthias Klose <doko at ubuntu.com> wrote:
>> On 21.01.2016 17:13, Nathaniel Smith wrote:
>>> On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>> On 21.01.2016 10:31, Nick Coghlan wrote:
>>>>> On 21 January 2016 at 19:03, M.-A. Lemburg <mal at egenix.com> wrote:
>>>>>> By using the version based approach, we'd not run into this
>>>>>> problem and gain a lot more.
>>>>> I think it's better to start with a small core that we *know* works,
>>>>> then expand later, rather than trying to make the first iteration too
>>>>> wide. The "manylinux1" tag itself is versioned (hence the "1" at the
>>>>> end), so "manylinux2" may simply have *more* libraries defined, rather
>>>>> than newer ones.
>>>> My argument is that the file based approach taken by the PEP
>>>> is too limiting to actually make things work for a large
>>>> set of Python packages.
>>>> It will basically only work for packages that do not interface
>>>> to other external libraries (except for the few cases listed in
>>>> the PEP, e.g. X11, GL, which aren't always installed or
>>>> available either).
>>> The list of allowed libraries is exactly the same list of libraries as are
>>> required by the Anaconda python distribution, so we *know* that it works
>>> for about a hundred different python packages, including lots of tricky
>>> ones (the whole scientific stack), and had been tested by tens or hundreds
>>> of thousands of users.
>> so this is x86_64-linux-gnu. Any other architectures?
> That's by far the dominant architecture for Linux workstations and
> servers, so that's what we've focused on, yeah. I assume that
> mainstream glibc-using distros on x86-32 and ARM are similar; unless
> someone wants to go do the research somehow then I think the simplest
> way forward is to proceed on the assumption that the same spec will
> work, and then fix it up if/when it turns out to break.


Here’s the # of downloads from PyPI in the last week or so that we can identify as a linux machine using pip and what the value of their platform.machine() is: https://caremad.io/s/SIxbkCB82C/

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/20160121/c030028a/attachment-0001.sig>

More information about the Distutils-SIG mailing list