Renaming a virtualenv folder without breaking it

You need to adjust your install to use relative paths. virtualenv provides for this with the --relocatable option. From the docs:

Normally environments are tied to a specific path. That means that you cannot move an environment around or copy it to another computer. You can fix up an environment to make it relocatable with the command:

$ virtualenv --relocatable ENV

NOTE: ENV is the name of the virtual environment and you must run this from outside the ENV directory.

This will make some of the files created by setuptools or distribute use relative paths, and will change all the scripts to use activate_this.py instead of using the location of the Python interpreter to select the environment.

Note: you must run this after you've installed any packages into the environment. If you make an environment relocatable, then install a new package, you must run virtualenv --relocatable again.

I believe "knowing why" matters more than "knowing how". So, here is another approach to fix this.

When you run . env/bin/activate, it actually executes the following commands (using /tmp for example):

VIRTUAL_ENV="/tmp/myproject/env"export VIRTUAL_ENV

However, you have just renamed myproject to project, so that command failed to execute.That is why it says pip is not installed, because you haven't installed pip in the system global environment and your virtualenv pip is not sourced correctly.

If you want to fix this manually, this is the way:

1. With your favorite editor like Vim, modify /tmp/project/env/bin/activate usually in line 42:

   VIRTUAL_ENV='/tmp/myproject/env' => VIRTUAL_ENV='/tmp/project/env'

2. Modify /tmp/project/env/bin/pip in line 1:

   #!/tmp/myproject/env/bin/python => #!/tmp/project/env/bin/python

After that, activate your virtual environment env again, and you will see your pip has come back again.

NOTE: As @jb. points out, this solution only applies to easily (re)created virtualenvs. If an environment takes several hours to install this solution is not recommended

Virtualenvs are great because they are easy to make and switch around; they keep you from getting locked into a single configuration. If you know the project requirements, or can get them, Make a new virtualenv:

• Create a requirements.txt file

  (env)$ pip freeze > requirements.txt

  • If you can't create the requirements.txt file, check env/lib/pythonX.X/site-packages before removing the original env.

• Delete the existing (env)

  deactivate && rm -rf env

• Create a new virtualenv, activate it, and install requirements

  virtualenv env && . env/bin/activate && pip install -r requirements.txt

Alternatively, use virtualenvwrapper to make things a little easier as all virtualenvs are kept in a centralized location

$(old-venv) pip freeze > temp-reqs.txt$(old-venv) deactivate$ mkvirtualenv new-venv$(new-venv) pip install -r temp-reqs.txt$(new-venv) rmvirtualenv old-venv