Some packages require specific versions of other packages to run. For instance, if you build some code to run explicitly with mypackage
version 1.0.0, and a newer version came out that deprecated a feature you needed, then doing pip install mypackage
would break your code.
Example: If you wanted to package your code, one of your dependencies would be django
. If you try to run your code without django
, it would break, saying ModuleNotFound: No module named 'django'
. Thus, you would need to pip install
it before running your code. Likewise, you would not want a very early version of django
as some of its features might not be available in earlier versions, or they could function differently.
A virtualenv itself is a new python interpreter. It has its own python executable, its own site-packages
directory for packages, etc. You activate
the environment through a command-prompt/shell and then can access it. anaconda
is another example of a virtualenv manager. In a virtual environment, you can curate packages to match specific applications, that way building a new environment won't impact your other code and potentially break said code, because it's an isolated interpreter that isn't tied to the base python install on your machine.
This also allows you to run different interpreters. You could have a venv for python2.7 and one for python3.6