At 12:59 PM 1/7/2006 +0800, Jeff Pitman wrote:
> If you need .so that's built and exported by the same packaged egg, you
> may just consider installing it in a more benign area such as /usr/local/lib.
As I mentioned before, this breaks multi-version support, although I
suppose one could perhaps force the egg version to always be included in
the filename... that would lead to some interesting problems as far as
keeping the build area clean, though! You'd have to run a "clean --all"
whenever the version number changed, and the extensions using the library
would have to refer to the exact version.
Unfortunately, this would *still* require users to mess with
LD_LIBRARY_PATH in order to use private library versions, and so isn't
particularly useful. Some variant of the "patch the extensions' runtime
path at installation/cache extraction time" approach would still be necessary.
There is actually a hook in pkg_resources whose purpose was to support
doing this kind of thing with any code resources extracted to the egg
cache, so it's probably doable, and I could probably also make the code
usable by easy_install during egg unpacking. It pretty much means the
"unzip the egg manually" concept is a dead duck when libraries are
involved, though. You could only safely unpack an egg using a
manually-created ResourceManager with an appropriate extraction path base.
On Mac OS there's an option to automatically pad the rpath area, but on
other OSes I'd need to do the padding myself by supplying an extra-long
rpath entry that could then be overwritten during the extraction process.
What bothers me about all of this is that moving an installed egg then
*breaks* it, because the rpath is now hard-wired. Sigh. Ironically
enough, an egg containing a shared library would then need to be labeled as
"not unzip safe", i.e., it's really only safe to use if it remains
zipped. A new category of egg, to be sure. :)
Interestingly, this is one of the few times where I have to say that
Windows is actually better-designed than Unix. Sure, the same design
choice enables all other sorts of DLL hell, but on this very narrow
specific issue Windows kicks ass. :)
Anyway, I really wish there were a way to hook into the dynamic link
process that didn't require one to manage the entire linkage one's
self. The dl.open() function lets you get access to symbols, but that
doesn't seem sufficient. :(