<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> Glyph told us last week that this proposal is exactly how the cryptography package wants to handle their openssl dependency: <a href="https://www.mail-archive.com/distutils-sig@python.org/msg23506.html" target="_blank">https://www.mail-archive.com/distutils-sig@python.org/msg23506.html</a><br></p><p dir="ltr">
</p></blockquote><div>well, SSL is a pretty unique case -- there's one where controlling the version of the lib, and having it be recent it critical.</div><div><br></div><div>We will have issues with all sorts of other "Pretty common, but can't count on it" libs.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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 </p></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">they're already doing to make static windows and OSX wheels; </p></blockquote><div>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.</div><div><br></div><div>Windows is "working" because of Chris Gohlke's heroic efforts.</div><div><br></div><div>OS-X is kind-of sort of working, because of Matthew Brett's also heroic efforts.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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....</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><p dir="ltr">> The idea to include the needed share libs in the wheel<br>
> goes completely against the idea of relying on a system<br>
> vendor to provide updates and security fixes. In some cases,<br>
> this may be reasonable, but as design approach, it's<br>
> not a good idea.<br></p></div></div></blockquote><div>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. </div><div><br></div><div>On Windows, dll hell is such that we've all accepted that we're going to need to statically link and provide dlls.</div><div><br></div><div>On OS-X, at least the base system is pretty well defined -- though I sure wish they'd supply more of what really should be basic libs.</div><div><br></div><div>-CHB</div></div><div class="gmail_extra"><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>