[Phillip J. Eby wrote]
... Some variant of the "patch the extensions' runtime path at installation/cache extraction time" approach would still be necessary.
Yup, unfortunately.
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.
Perhaps 'bin/egg-unzip' or something like that?
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.
Yes, that is what I do for ActivePython (and similar for Active{Tcl|Perl}) for the Unix OSes. Effectively: configure --prefix=.../some_really_really_long_path make && make install
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
But still "egg-unzip" safe, right? :) Aside: I've found this page to be quite helpful for cross-platform shared library handling info: http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html Cheers, Trent -- Trent Mick trentm@activestate.com