On Fri, Nov 30, 2018 at 7:35 AM Paul Moore <p.f.moore@gmail.com> wrote:
Only Linux users can really answer this. But what I will say is that on Windows, anything other than the core system libraries must be bundled in the wheel (so, for example, Pillow bundles the various image handling DLLs). Manylinux (as I understand it) does a certain amount of this, but expects dynamic linking for a much wider set of libraries. Maybe that reflects the same sort of mindset that results in Linux distros "debundling" tools like pip that vendor their dependencies. I'm not going to try to judge whether the Linux or the Windows approach is "right", but I'd be surprised if manylinux can take much inspiration from the Windows approach without confronting this difference in philosophy.
Paul
[1] I certainly don't want to spark any sort of flamewar here, but I do feel a certain wry amusement that the term "DLL Hell" was invented as a criticism of library management practices on Windows, and yet in this context, library management on Windows is pretty much a non-problem, and it's Linux (that prided itself on avoiding DLL hell at the time) that is now struggling with library versioning complexity ;-)
The Windows and Linux situations are actually almost identical, except for the folklore around them. Both have a small but sufficient set of libraries that you can rely on being there, and that are carefully designed to maintain ABI backwards compatibility over time, and then you have to vendor everything else. Windows actually used to be worse than Linux at this, because its version of libc wasn't in the set of base libraries, so it had to be vendored along with every app, and you could have all kinds of "fun" if Python and its extensions weren't built against the same libc. But these days they've switched to a Linux-style libc (complete with a clever implementation of glibc-style symbol versioning), so they really are pretty much identical. The hardest thing with distributing binaries on Linux is just convincing Linux hackers that it's OK to do it the same way Windows/macOS do, instead of inventing something more complicated. "DLL hell" refers to how in the bad old days, the standard practice for apps on Windows was not just to include vendored libraries, but to *store all those vendored libraries in the global libraries directory*, which unsurprisingly led to all kinds of chaos as different apps overwrote each other's vendored libraries. -n -- Nathaniel J. Smith -- https://vorpus.org