[Distutils] draft PEP: manylinux1

Robert T. McGibbon rmcgibbo at gmail.com
Thu Jan 21 15:02:44 EST 2016

On Jan 21, 2016 11:55 AM, "Chris Barker" <chris.barker at noaa.gov> wrote:
> On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>  Glyph told us last week that this proposal is exactly how the
cryptography package wants to handle their openssl dependency:
> well, SSL is a pretty unique case --  there's one where controlling the
version of the lib, and having it be recent it critical.
> We will have issues with all sorts of other "Pretty common, but can't
count on it" libs.
>> Is manylinux1 the perfect panacea for every package? Probably not. In
particular it's great for popular cross platform packages, because it works
now and means they can basically reuse the work that
>> they're already doing to make static windows and OSX wheels;
> except that static linking is a pain on LInux  -- the toolchain really
doesn't want you to do that :-) It's also not part of the culture.
> Windows is "working" because of Chris Gohlke's heroic efforts.
> OS-X is kind-of sort of working, because of Matthew Brett's also heroic
> But Anaconda and Canopy exist, and are popular, for a reason -- they
solve a very real problem, and many linux is only solving a very small part
of that problem -- the easy part.
> Maybe there will be a Gohlke-like figure that will step up and build
statically linked wheels for all sorts of stuff -- but is that the end-game
we want anyway? everyting statically linked?
> One plus -- with Docker and CI systems, it's getting pretty easy to set
up a build sandbox that only has the manylinux libs on it -- so not too
hard to automate and test your builds....
>> > The idea to include the needed share libs in the wheel
>> > goes completely against the idea of relying on a system
>> > vendor to provide updates and security fixes. In some cases,
>> > this may be reasonable, but as design approach, it's
>> > not a good idea.
> Is this any different than static linking -- probably not. And that's
pretty much what I mean by the culture os dynamic linking on Linux.

The difference between static linking and vendoring the shared libraries
into the wheel using ``auditwheel repair`` is essentially just that the
second option is much easier because it doesn't require modifications to
the build system. Other than that, they're about the same.

This is why Nathaniel was able to make a PySide wheel in 5 minutes. I don't
think heroic efforts are really required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160121/8b889012/attachment.html>

More information about the Distutils-SIG mailing list