[Distutils] Making pip and PyPI work with conda packages

[Paul Moore]

On 19 May 2015 at 16:22, Chris Barker <chris.barker at noaa.gov> wrote:
> The other issue is social: this would really only be a benefit if a wide
> variety of packages shared the same libs -- but each of those packages is
> maintained by different individuals and communities. So it's had to know if
> it would get used. I could put up a libpng wheel, for instance, and who
> knows if the Pillow folks would have any interest in using it? or the
> matplotlib folks, or, ... And this would be particularly difficult when the
> solution was hacked together...

Honestly, I still haven't seen a solid explanation of why (at least on
Windows) static linking isn't a viable option. If someone were to
create and publish a Python compatible static ".lib" file for the
various hard-to-build dependencies, extensions could specify that you
link with it in setup.py, and all the person building the wheel has to
do is download the needed libraries for the build.

If there's a technical reason why dynamic linking at runtime is better
than static linking (sufficiently better that it justifies all the
effort needed to resolve the issues involved), then I've yet to see a
good explanation of it. The only things I've seen are disk space, or
maintenance (where this usually means "it's easier to release a new
DLL with a security fix than get all the various statically linked
packages updated - that's a valid point, but given how hard it is to
get a working dynamic linking solution in this environment, I have to
wonder whether that argument still holds).

All of this applies to Windows only, of course - dynamic linking and
system management of shared libraries is very much a per-platform
issue, and I don't pretend to know the trade-offs on OSX or Linux.

Paul