[Distutils] draft PEP: manylinux1

[Nathaniel Smith]

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.

> Any reason to choose
> gcc 4.8.2 which is known for it's defects?

It's the most recent version of gcc that's able to target CentOS 5
(thanks to RH's backporting efforts in their "devtoolset" releases),
and CentOS 5 is the target baseline that's currently used by
approximately everyone who distributes universal linux binaries
(google e.g. "holy build box").

> This whole thing looks like an
> Anaconda marketing PEP ...

Anaconda's main selling point is that they provide binaries that "just
work", and pip doesn't. Not sure how improving pip to be a stronger
competitor to Anaconda is Anaconda marketing.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org