I’ve created folder and initialized a virtualenv instance in it.
$ mkdir myproject $ cd myproject $ virtualenv env
When I run
(env)$ pip freeze, it shows the installed packages as it should.
Now I want to rename
$ mv myproject/ project/
However, now when I run
$ . env/bin/activate (env)$ pip freeze
it says pip is not installed. How do I rename the project folder without breaking the environment?
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
What I believe is that
"knowing why" matters more than "knowing how". So, here is another approach to fix this.
When you run:
$ . env/bin/activate
it actually execute the following commands:
( I test this in
VIRTUAL_ENV="/tmp/myproject/env" export VIRTUAL_ENV
However, you have just renamed
project, so that command failed to execute.
That is why it says
pip is not installed, because neither you have installed
pip in the system global environment nor your virtualenv
pip is sourced correctly.
If you want to fix this manually, that is the way:
/tmp/project/env/bin/activatewith yout favoriate editor like Vim, usually in
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
(env)$ pip freeze > requirements.txt
- If you can’t create the
env/lib/pythonX.X/site-packagesbefore removing the original
- If you can’t create the
Delete the existing
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
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:
To go to your newenv:
You can fix your issue by following these steps:
- rename your directory
- rerun this:
$ virtualenv ..\path\renamed_directory
- virtualenv will correct the directory associations while leaving your packages in place
$ pip freezeto verify your packages are in place
- An important caveat, if you have any static path dependencies in script files in your virtualenv directory, you will have to manually change those.
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
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).
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.