[Distutils] draft PEP: manylinux1

[Matthias Klose]

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?  Any reason to choose gcc 
4.8.2 which is known for it's defects?  This whole thing looks like an Anaconda 
marketing PEP ...

Matthias