On Jan 21, 2016 11:55 AM, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith <n...@pobox.com> wrote: >> >> Glyph told us last week that this proposal is exactly how the cryptography package wants to handle their openssl dependency: https://www.mail-archive.com/distutils-sig@python.org/msg23506.html > > 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 efforts. > > 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.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
