When you do a lot of Python programming, you can make a mess of your system with Pip. Different apps need different requirements. One app needs version 1.2 of a package and another one needs 1.5. And then... you're in trouble.
When you want to know what packages have been installed by Pip, use this:
$ pip freeze
The result can be a very long list.
For every project, whether it's a simple application or a giant Django project, I create a new virtual environment with virtualenv. An easy way to do this is by using virtualenvwrapper.
Getting started with Virtualenv wrapper
$ sudo pip install virtualenvwrapper
There are some advanced settings which you can find in the manual.
When installed, let's make a new environment called "testground".
$ mkvirtualenv testground
If your virtualenvwrapper is working well, you should see something like this:
New python executable in testground/bin/python Installing Setuptools.........done. Installing Pip..............done. virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/testground/bin/predeactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/testground/bin/postdeactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/testground/bin/preactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/testground/bin/postactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/testground/bin/get_env_details (testground)yourname@yoursystem:~$
Take a look at the last line, which now says (testground) before the prompt. Your virtual environment is there, and your are in it.
Now, do a pip freeze, it can result in something like this:
$ pip freeze argparse==1.2.1 wsgiref==0.1.2
That list can be a lot shorter than the one outside the environment.
You can now install something that only effects this environment. Let's try Pillow, version 2.2.2.
$ pip install Pillow==2.2.2
It will now try to install Pillow, when finished, do another pip fip freeze, and see if it's installed
Switchting between virtualenvs
Let's create another environment:
$ mkvirtualenv coolapp
once it's finished, it should have been activated automatically:
...................done. virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/coolapp/bin/predeactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/coolapp/bin/postdeactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/coolapp/bin/preactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/coolapp/bin/postactivate virtualenvwrapper.user_scripts creating /home/yourname/.virtualenvs/coolapp/bin/get_env_details (coolapp)yourname@yoursystem:~$
Now, let's switch to fist the virtualenv we made by the magic word "workon":
$ workon testground (testground)yourname@yoursystem:~$
There you go, it's as simpel as that
No site packages
Like with vitualenv, you can tell virtualenvwapper not to use the systems sitepackages with --no-site-packages:
$ mkvirtualenv anotherenv --no-site-packages
Remove a virtual environment
It's very easy to get rid of a virtual env by using rmvirtualenv:
$ rmvirtualenv coolapp Removing coolapp...
List all virtualenvs
List your sitepackages
$ lssitepackages #can result in this: easy_install.py Pillow-2.2.2-py2.7.egg-info pkg_resources.pyc easy_install.pyc pip setuptools _markerlib pip-1.4.1-py2.7.egg-info setuptools-0.9.8-py2.7.egg-info PIL pkg_resources.py