[Pythonmac-SIG] Advice wanted on dependency building...

[Ronald Oussoren]

On 23 May, 2013, at 7:38, Chris Barker - NOAA Federal <chris.barker at noaa.gov> wrote:

> I just poked a bit into the Anaconda Python distribution. their
> packages are simple tarballs, but I think they have a dependency
> management system of some sort.
> 
> They deliver the dependencies as separate packages (tarballs), one for
> each lib. It looksl ike it all gets unpacked inot a sinlgle dir (in
> /opt), and an example python extension is built like this:
> 
> $ otool -L netCDF4.so
> netCDF4.so:
> 	@loader_path/../../libnetcdf.7.dylib (compatibility version 10.0.0,
> current version 10.0.0)
> 	@loader_path/../../libhdf5_hl.7.dylib (compatibility version 8.0.0,
> current version 8.3.0)
> 	@loader_path/../../libhdf5.7.dylib (compatibility version 8.0.0,
> current version 8.3.0)
> 	@loader_path/../../libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.7)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.0.0)
> 
> 
> I don't know how to get that @loader_path thing in there, but this
> seems like a reasonable way to do it (though I guess it wouldn't
> support virtualenv...)

Interesting... @loader_path could work, it expands into the path of MachO binary
that links to the library (in your example to os.path.abspath(netCDF4.so). That
can be used to point to a fixed location in the sys.prefix tree, the relative path
for every extension could be different but would be known at build time. It might
require a macholib step when building installers, but that shouldn't be a problem.

@rpath could also work for installs outside of virtualenv-s, but would require
changes to the Python build.

Ronald

P.S. I need to check if macholib (and hence py2app) supports @loader_path, but adding
such support shouldn't be hard as the semantics are pretty easy.