pip Requirements are Installed in Containing Virtual Environment

Issue #21 on hold
Chris Streeter
created an issue

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

Comments (6)

  1. Holger Krekel repo owner

    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/...

  2. Log in to comment