On Wed, May 20, 2015 at 12:46 AM, Paul Moore <p.f.moore@gmail.com> wrote:

On 19 May 2015 at 16:22, Chris Barker <chris.barker@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.

Because some libraries simply don't work as static libraries, or are too big (MKL comes to mind). Also, we have been historically using static libs for our eggs at Enthought on windows, and it has been a nightmare to support. It just does not scale when you have 100s of packages.

But really, once wheels support arbitrary file locations, this becomes fairly easy at the packaging level: the remaining issue is one of ABI / standards, but that's mostly a non technical issue.

Gholke has 100s of packages using wheels, and we ourselves at Enthought have close to 500 packages for windows, all packaged as eggs, maybe 30-40 % of which are not python but libs, C/C++ programs, etc... It is more about agreeing about a common way of doing things than a real technical limitation.

David

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

_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig