pip Requirements are Installed in Containing Virtual Environment

[pytoxbot]

• Bitbucket: https://bitbucket.org/hpk42/tox/issue/21
• Originally reported by: streeter
• Originally created at: 2011-12-10T01:23:02.672

In some cases (I think I know the case), tox will install the pip requirements into whatever virtual environment was active at the time of the tox command. Here's an example of what that looks like:

#!bash

~/dev/project/www$ mkvirtualenv test
~/dev/project/www$ workon test
(test)~/dev/project/www$ pip freeze
tox==1.2
(test)~/dev/project/www$ tox
...
(test)~/dev/project/www$ pip freeze
eautifulSoup==3.2.0
Django==1.3.1
Fabric==1.3.2
...
tox==1.2
unittest2==0.5.1
virtualenv==1.7
wsgiref==0.1.2
(test)~/dev/project/www$

It seems that I had something weird setup with my PIP environment variables.

#!bash

(test)~/dev/project/www$ env | grep VIR
PIP_REQUIRE_VIRTUALENV=true
VIRTUAL_ENV=/Users/streeter/.virtualenvs/test
VIRTUALENVWRAPPER_HOOK_DIR=/Users/streeter/.virtualenvs
PIP_VIRTUALENV_BASE=/Users/streeter/.virtualenvs
PIP_RESPECT_VIRTUALENV=true
VIRTUALENVWRAPPER_LOG_DIR=/Users/streeter/.virtualenvs

It seems that the PIP_REQUIRE_VIRTUALENV was throwing off the pip install, forcing the pip used by the tox installed venv to use the activated venv. Removing that environment variable caused it to work. Here's the output of several commands: http://pastie.org/2992756

[pytoxbot]

Original comment by streeter

Awesome. Glad it was easily fixable.

[pytoxbot]

Original comment by @hpk42

You could verify it helps with "pip install -i http://pypi.testrun.org -U tox" which should give you version "1.3.dev2" at least. Thanks for the good report and analysis, btw!

[pytoxbot]

Original comment by @hpk42

fix issue21 - pip installing to wrong virtualenv, arising when PIP_REQUIRE_VIRTUALENV is set by unsetting it.

→ <<cset 9fc1e12671d1>>

[pytoxbot]

Original comment by @hpk42

Not sure how to best fix the issue. One way is to unset PIP_REQUIRE_VIRTUALENV - in fact tox itself takes some care to only call commands that are installed in the virtualenv so maybe that is sufficient. The other way to fix would involve calling the "activate" script -- not sure if this can easily be made to work on win32/...