Renaming a virtualenv folder without breaking it

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

You can fix your issue by following these steps:

1. rename your directory
2. rerun this: $ virtualenv ..pathrenamed_directory
3. virtualenv will correct the directory associations while leaving your packages in place
4. $ scripts/activate
5. $ pip freeze to verify your packages are in place
6. An important caveat, if you have any static path dependencies in script files in your virtualenv directory, you will have to manually change those.

virtualenv --relocatable ENV is not a desirable solution. I assume most people want the ability to rename a virtualenv without any long-term side effects.

So I’ve created a simple tool to do just that. The project page for virtualenv-mv outlines it in a bit more detail, but essentially you can use virtualenv-mv just like you’d use a simple implementation of mv (without any options).

For example:

virtualenv-mv myproject project

Please note however that I just hacked this up. It could break under unusual circumstances (e.g. symlinked virtualenvs) so please be careful (back up what you can’t afford to lose) and let me know if you encounter any problems.

I always install virtualenvwrapper to help out. From the shell prompt:

pip install virtualenvwrapper

There is a way documented in the virtualenvwrapper documents – cpvirtualenv
This is what you do. Make sure you are out of your environment and back to the shell prompt. Type in this with the names required:

cpvirtualenv oldenv newenv

And then, if necessary:

rmvirtualenv oldenv

To go to your newenv:

workon newenv

Yet another way to do it that worked for me many times without problems is virtualenv-clone:

pip install virtualenv-clone
virtualenv-clone old-dir/env new-dir/env

Run this inside your project folder:

cd bin
sed -i 's/old_dir_name/new_dir_name/g' *

Don’t forget to deactivate and activate.

In Python 3.3+ with built-in venv

As of Python 3.3 the virtualenv package is now built-in to Python as the venv module. There are a few minor differences, one of which is the --relocatable option has been removed. As a result, it is normally best to recreate a virtual environment rather than attempt to move it. See this answer for more information on how to do that.

What is the purpose behind wanting to move rather than just recreate any virtual environment? A virtual environment is intended to manage the dependencies of a module/package with the venv so that it can have different and specific versions of a given package or module it is dependent on, and allow a location for those things to be installed locally.

As a result, a package should provide a way to recreate the venv from scratch. Typically this is done with a requirements.txt file and sometimes also a requirements-dev.txt file, and even a script to recreate the venv in the setup/install of the package itself.

One part that may give headaches is that you may need a particular version of Python as the executable, which is difficult to automate, if not already present. However, when recreating an existing virtual environment, one can simply run python from the existing venv when creating the new one. After that it is typically just a matter of using pip to reinstall all dependencies from the requirements.txt file:

From Git Bash on Windows:

python -m venv mynewvenv
source myvenv/Scripts/activate
pip install -r requirements.txt

It can get a bit more involved if you have several local dependencies from other locally developed packages, because you may need to update local absolute paths, etc. – though if you set them up as proper Python packages, you can install from a git repo, and thus avoid this issue by having a static URL as the source.

Even easier solution which worked for me: just copy the site-packages folder of your old virtual environment into a new one.

Using Visual Studio Code (vscode), I just opened the ./env folder in my project root, and did a bulk find/replace to switch to my updated project name. This resolved the issue.

Confirm with which python

If you are using an conda env,

conda create --name new_name --clone old_name
conda remove --name old_name --all # or its alias: `conda env remove --name old_name`