A tool that I use frequently is virtualenvwrapper, which is a very small set of smart defaults and command aliases that makes working with virtual environments more intuitive. Let's install this to our global system now:
$ pip install virtualenvwrapper
Next, you'll want to add the following lines to the end of your shell startup file. This is most likely ~/.bashrc, but in case you've changed your default shell to something else such as zsh, then it could be different (for example, ~/.zshrc):
export WORKON_HOME=$HOME/.virtualenvs source /usr/local/bin/virtualenvwrapper.sh
The first line in the preceding code block indicates that new virtual environments that are created with virtualenvwrapper should be stored in $HOME/.virtualenvs. You can modify this as you see fit, but I generally leave this as a good default. I find that keeping all my virtual environments in the same hidden folder in my home directory reduces the amount of clutter in individual projects and makes it a bit more difficult to mistakenly add a whole virtual environment to version control.
Note
Adding an entire virtual environment to version control might seem like a good idea, but things are never as simple as they seem. The moment someone running a slightly (or completely) different operating system decides to download your project, which includes a full virtualenv folder that may contain packages with C modules that were compiled against your own architecture, they're going to have a hard time getting things to work.
Instead, a common pattern that is supported by pip and used by many developers is to freeze the current state of the installed packages in a virtual environment and save this to a requirements.txt file:
(testing) $ pip freeze > requirements.txt
This file may then be added to a version control system (VCS). As the intent of the file is to declare which dependencies are required for the application, and not provide them or indicate how they should be constructed, users of your project are then free to obtain the required packages in any way they so choose. Generally, they will install them via pip, which can handle a requirements file just fine:
(testing) $ pip install –r requirements.txt
The second line adds a few convenient aliases to your current shell environment in order to create, activate, switch, and remove environments:
mkvirtualenv test: This will create an environment named test and activate it automatically.mktmpenv test: This will create a temporary environment named test and activate it automatically. This environment will be destroyed once you invoke the deactivate script.workon app: This will switch you to the app environment (already created).workon(alias lsvirtualenv): When you don't specify an environment, this will print all the existing environments that are available.deactivate: This will disable the currently active environment, if any.rmvirtualenv app: This will completely remove the app environment.
We'll use the following command to create an environment to install our application packages:
$ mkvirtualenv app1
This will create a blank app1 environment and activate it. You should see an (app1) tag in your shell prompt.
Note
If you are using a shell other than Bash or ZSH, this environment tag may or may not appear. The way in which this works is that the script that is used to activate the virtual environment also modifies your current prompt string (the PS1 environment variable) so that it indicates the currently active virtualenv. As a result, there is a chance that this may not work if you're using a very special or non-standard shell configuration.