The myChEMBL virtual machine comes with a number of python modules already installed, which means in most cases things will work just fine. In case additional modules are needed, virtualenv allows to experiment with different combinations and versions of python on one single instance of the myChEMBL VM. In this gist, I specify the steps necessary to set up virtualenv on the myChEMBL VM.
The first step is to install the python package manager pip. This can be done using easy_install, a more basic package manager for python. It is already installed on myChEMBL but in case it still needs to be installed, this can easily be done using
sudo apt-get install python-setuptools python-dev build-essential
So once that is sorted we can install pip with the command
sudo easy_install pip
And then, with our super-cool package manager pip, we can install virtualenv
sudo pip install virtualenv
Easy!
What we also do is to install a package called virtualenvwrapper. This package makes it a bit easier to work with more than one virtualenv per machine and also makes usage of virtualenv more intuitive. So we can install it using
sudo pip install virtualenvwrapper
This command installs the wrapper - to access it's functions through the shell we add the following line to the file ~/.bashrc:
source /usr/local/bin/virtualenvwrapper.sh
We now use the virtualenvwrapper to access virtualenv functions and create a virtualenv like this
mkvirtualenv test_env
This will create a folder test_env for our virtualenv under the $WORKON_HOME path, which, by default, is ~/.virtualenvs. It is this folder into which new python packages will be installed as long as we are working in the testenv. To specify we are working in test_env, we can type
workon test_env # change into test_env
deactivate test_env # leave test_env to continue working in the 'systems' environment
Note that workon does not change our current directory but rather that it changes our path-variables in the background. Any package we install will now go to our virtualenv and be independent of any other virtualenv. If we want to isolate a virtualenv completely and not even allow it to 'see' packages installed under the 'systems' environment, then we can create a virtualenv like this:
mkvirtualenv nosite_env --no-site-packages
One thing you may have noticed after setting up the nosite_env is that under ipython, we can still import modules that are installed under the systems environment, such as numpy and rdkit - this is because we are still using the sytem-wide ipython. The solution is (logical) to install ipython in the new virtualenv:
pip install ipython
The first time I did this I needed to login a new shell to get this fresh copy of ipython when calling $ ipython - this seems to happen if the command $ ipython was launched before the new version of ipython was installed... maybe I was just not quite awake but the safest seems to be to enter the new virtualenv and install ipython before calling it.
Installing ipython in each virtualenv is painless and logical so should be preferred over workarounds like this unless you are planning to use lots and lots of virtualenvs and don't want to install ipython into every one of them.