Making setuptools play nicer with virtualenv
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
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?
Cheers,
Gaël
On Wed, Apr 2, 2008 at 5:31 AM, Gael Varoquaux gael.varoquaux@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
Gael Varoquaux wrote:
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
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?
Sometimes you want to inherit the environment you've activated, but in my experience usually this isn't what you'll want. I find it easier to just reinstall any tools (like ipython, nose, etc) that I want to use in the virtualenv.
In an ideal situation they could share eggs with the system packages, but this only kind of works. (Sometimes, for reasons I don't always understand, easy_install will find and install globally-installed packages, creating an executable bound to the virtualenv.)
Ian
participants (3)
-
Alexander Michael -
Gael Varoquaux -
Ian Bicking