[Distutils] draft PEP: manylinux1

Nathaniel Smith njs at pobox.com
Fri Jan 22 05:03:09 EST 2016

On Fri, Jan 22, 2016 at 1:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 21.01.2016 20:05, Matthew Brett wrote:
>> 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?
> I already posted a change proposal earlier on in the thread.
> I'll repeat it here (with a minor enhancements):

Okay, I think I get it now. I'll try to repeat back to summarize and
see if I have understood your proposal correctly:

In the PEP 513 "manylinux1" approach, when users do 'pip install foo',
then one of three things happens:
1) they get a working foo and are immediately good-to-go, or
2) pip says "I'm sorry, there's no compatible wheel", or
3) something else happens, in which case this is a bug, and the spec
provides some framework to help us determine whether this is a bug in
the wheel, a bug in pip, or a bug in the spec.

In your approach, users do 'pip install foo', and then pip installs
the wheel, and then when they try to use the wheel they get an error
message from the dynamic linker about missing libraries, and then the
user has to read the docs or squint at these error messages in order
to figure out what set of apt-get / yum / pacman / ... commands they
need to run in order to make foo work. (And possibly there is no such
combination of commands that will actually work, because e.g. the
wheel was linked against Debian's version of libbar.so.7 and Fedora's
version of libbar.so.7 turns out to have an incompatible ABI, or
Fedora simply doesn't provide a libbar.so.7 package at all.)

I won't express any opinion on your alternative PEP with its own
platform tag without reading it, but we're not going to change PEP 513
to work this way.

>  * no lock-out of package authors who would like to push
>    wheel files for their packages to PyPI, but happen to
>    use libraries not in the predefined list of the original
>    draft PEP



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

More information about the Distutils-SIG mailing list