On 15 May 2015 at 06:01, Chris Barker <chris.bar...@noaa.gov> wrote: >> >> I'm confused -- you don't want a system to be able to install ONE >> >> version >> >> of a lib that various python packages can all link to? That's really >> >> the >> >> key use-case for me.... > > >> >> Are we talking about Python libraries accessed via Python APIs, or >> linking to external dependencies not written in Python (including >> linking directly to C libraries shipped with a Python library)? > > > I, at least, am talking about the latter. for a concrete example: libpng, > for instance, might be needed by PIL, wxPython, Matplotlib, and who knows > what else. At this point, if you want to build a package of any of these, > you need to statically link it into each of them, or distribute shared libs > with each package -- if you ware using them all together (which I do, > anyway) you now have three copies of the same lib (but maybe different > versions) all linked into your executable. Maybe there is no downside to > that (I haven't had a problem yet), but it seems like a bad way to do it!
If they are exchanging data structures, it will break at some point. Consider libpng; say that you have a handle to the native C struct for it in PIL, and you pass the wrapping Python object for it to Matplotlib but the struct changed between the version embedded in PIL and that in Matplotlib. Boom. If you communicate purely via Python objects that get remarshalled within each lib its safe (perhaps heavy on the footprint, but safe). -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
