[Distutils] draft PEP: manylinux1

[Matthew Brett]

Hi,

On Thu, Jan 21, 2016 at 2:05 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).
>
> IMO, testing the versions of a set of libraries is a safer
> approach. It's perfectly fine to have a few dependencies
> not work in a module because an optional system package is not
> installed, e.g. say a package comes with UIs written in
> Qt and one in GTK.

Please forgive my slowness, but I don't understand exactly what you
mean.  Can you give a specific example?

Say my package depends on libpng.

Call the machine I'm installing on the client machine.

Are you saying that, when I build a wheel, I should specify to the
wheel what versions of libpng I can tolerate on the the client
machine, and if if the client does have a compatible version, then pip
should raise an error, perhaps with a useful message about how to get
libpng?

If you do mean that, how do you want the PEP changed?

Best,

Matthew