On Fri, Feb 18, 2011 at 1:59 PM, Eric Lemoine <[email protected]> wrote: > On Fri, Feb 18, 2011 at 9:10 PM, Tyler Erickson <[email protected]> wrote: >> I have been working with virtualenv and pip to create isolated Python >> environments and replicatable builds. However, I have encountered a >> (probably common) situation that I don't know how to configure, and >> can't seem to find any examples of. >> >> SCENARIO: The Python project you are developing has a dependency on a >> (non-Python) shared library (potentially a particular version or range >> of versions). How do you specify that a specific shared library is to >> be installed and how do you make sure it is accessible by the virtual >> environment? >> >> Examples: >> * GDAL Python bindings (which depend on libgdal and numpy) >> * Shapely (which depends on libgeos_c) > > To my knowledge Shapely includes ctype-based code for finding where > libgeos_c is located on the filesystem, so whether Shapely is > installed in a virtualenv doesn't make a difference. I don't know > about GDAL though. > >> >> Or maybe I shouldn't be worrying about this. Is it a standard >> practice to just assume a manual installation of a shared libraries on >> the development or production system? If so, how would you deal with >> several virtual environments with dependencies on different versions a >> shared library? > > > I don't know if that's possible, and I'm also interested to know. >
Have you seen this thread on the virtualenv list? https://groups.google.com/forum/?pli=1#!topic/python-virtualenv/-U4epR1YWFk I didn't know about the LD_RUN_PATH variable. Seems like it could be handy within a script that 1) makes a virtualenv, 2) does a CMMI for C libs with --prefix=${virtualenv directory}, and 3) installs Python packages into the virtualenv using the local pip. Cheers, -- Sean
