[Distutils] Making setuptools play nicer with virtualenv

[Alexander Michael]

On Wed, Apr 2, 2008 at 5:31 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi,
>
>  I have just out-clevered myself using setuptools and virtualenv:
>
>   * install foo using "python setup.py develop" (foo being ipython).
>
>   * download some module bar you want to work on in an isolated environment
>
>   * create this isolated environment using "virtualenv bar"
>
>   * in the isolated environment "python setup.py develop" the bar module.
>
>   * still in the isolated environment, try to import bar in a script
>    installed by foo (aka ipython)
>
>     --> fails because foo uses the system python, and virtualenv wants
>         you to use its own python

Currently, virtualenv only inherits libraries (i.e. site-packages),
not scripts (i.e. entry points in bin or Scripts). I believe the idea
is that you want to create a semi-isolated application environment of
a sort that only provides the targeted application. This should be
documented more explicitly.

>  One very easy solution to make this work is to have the setuptools
>  generated scripts use, under unices, "#!/usr/bin/env python" rather than
>  "#!/usr/bin/python". This seems to me like a good solution, in general,
>  to follow the user's expectations.
>
>  Is this a change that would be possible?

This won't work. One of the cool things about virtualenv is that you
don't actually need to "activate" the environment to use
applications/scripts it provides. The correct solution is to create a
custom bootstrap that either installs ipython, or copies the entry
point wrapper from the parent environment to the virtualenv, replacing
the shebang line with the path to the virtualenv provided interpreter.
Scripts are versioned entry points assigned to a particular
environment.

As far as modifying setuptools to install scripts with the suggested
shebang line, I used to patch my local setuptools to do just this but
have learned the hard way the wisdom of being explicit here after
users installed their own python and then complained that the site
scripts broke. It also makes things less fragile when you want to
start transitioning to newer python releases along-side the current
(or system) python.

HTH,
Alex