Comes in handy when:
- you don't want to, or can't install Python packages system-wide (to /usr/local/lib/python2.7/site-packages on Debian, for example).
- only those packages actually required by an application should be made available to it.
- an application needs a version of a package that is older than the one that already is, or would be installed (by your operating system's package manager, for example).
- packages for a specific application should be kept at a certain version (because you want to check the changelogs first, and upgrade applications one by one), or at least they shouldn't be updated automatically, while it still should be possible to update those packages for other applications.
- you want to test a single code base manually with multiple Python interpreters (you can, for example, create environments env2.7 and env3.3, and activate one of them as necessary).
Usually, if virtualenv is installed, a virtual environment in ./some-app-env is created like so:
$ virtualenv some-app-env
$ . some-app-env/bin/activate (some-app-env)$ pip install Flask SQLAlchemy WTForms
There are some differences in using it, compared to the third-party module and earlier Python versions, though.
Instead of virtualenv, use the pyvenv (or pyvenv-3.3) command to create a virtual environment:
$ pyvenv some-app-env
A note from personal experience: It's pyvenv (as in "py-vee-env"), not pyenv (like rbenv). I even made this mistake again when writing this article …
You might want to make sure it actually provides version 3.3 of Python:
$ . some-app-env/bin/activate (some-app-env)$ python -V Python 3.3.2+
Availability of setuptools and pip
(some-app-env)$ wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py -O - | python
(some-app-env)$ curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py (some-app-env)$ python get-pip.py
… and you're ready to go!