I have a basic understanding of virtualenvs, in essence a virtualenv is a directory where all the dependencies of your python project go. And by dependencies, we mean things like:
- any pip-installed packages
- any C headers or source files those packages depend on
- documentation for those packages
- the pip executable itself
- the python executable itself
- other runnable programs or scripts installed packages might create
So virtualenvs let you take all that stuff and stick it in a per-project directory. This lets you not have to deal with the hassle of keeping these dependencies straight between projects had you installed these things globally.
activate do then?
Basically, it monkeys around with your
$PATH and sets up some aliases to make using the virtualenv easier and save you some typing. Rather than saying
/path/to/virtualenv/bin/pip install django you can just
pip install django, and so on.
The opposite of
activate! Sets your path back to the oringal values, unsets those aliases, etc. etc.
virtualenv is a complex tool with many flags and modes of operation.
virtualenvwrapper wraps it up so that the defaults most people want are available with just a simple invocation of
mkvirtualenv <name of env>.
It also places all these virtualenvs in one directory (usually either
~/.virtualenvs) and provides another script
workon that lets you activate a virtualenv by name, rather than with
It surprises me how difficult this was! Many projects that develop using virtualenv tend to deploy with virtualenv as well (we do at Dark Horse), but as long as you have the correct version of python installed, it should work just fine if you
pip install -r requirements.txt so that the packages are installed globally.
I say that with all the hubris of never having attempted to do so with tootstream of course