I don't know about such bootstrapping. If it works, let me know. I was
thinking of a simple shell script:

#!/bin/bash
DIR="/home/me/env1"
virtualenv $DIR
cd $DIR/src/gdal
./configure --prefix=$DIR; make; make install
cd $DIR
source bin/activate
LD_RUN_PATH=$DIR/lib pip install GDAL

Untested, but something like that.

On Mon, Feb 21, 2011 at 11:55 AM, Tyler Erickson <[email protected]> wrote:
> That looks quite promising.  But how would such a script that sets
> LD_RUN_PATH be invoked?
> Would you use a 'bootstrap' script?  I'll admit being a bit confused on how
> the bootstrap scripts that can be created with
> virtualenv.create_bootstrap_script() [1] are intended to be used.  Do you
> simply just call the bootstrap script at the beginning of your setup.py
> file, similar to how the ez_setup bootstrap script is called [2]?
> i.e. add to the top of your setup.py file something like:
>
>     from bootstrap import set_ld_run_path
>     set_ld_run_path()
>
> - Tyler
> [1] http://pypi.python.org/pypi/virtualenv
> [2] http://peak.telecommunity.com/dist/ez_setup.py
>
>
> On Mon, Feb 21, 2011 at 10:37 AM, Sean Gillies <[email protected]>
> wrote:
>>
>> 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
>
>

Reply via email to