A "virtualenv activate" for Anaconda environments

a-conda-workon-tool.md

A "virtualenv activate" for Anaconda environments

I've been using the Anaconda python package from continuum.io recently and found it to be a good way to get all the complex compiled libs you need for a scientific python environment. Even better, their conda tool lets you create environments much like virtualenv, but without having to re-compile stuff like numpy, which gets old very very quickly with virtualenv and can be a nightmare to get correctly set up on OSX.

The only thing missing was an easy way to switch environments - their docs suggest running python executables from the install folder, which I find a bit of a pain. Coincidentally I came across this article - Virtualenv's bin/activate is Doing It Wrong - which desribes a simple way to launch a sub-shell with certain environment variables set. Now simple was the key word for me since my bash-fu isn't very strong, but I managed to come up with the script below. Put this in a text file called conda-workon, make it executable (chmod 777), and put it on your path somewhere (you can put it in bin, personally I just have a scripts folder in my home directory that I add to my PATH). You also need to set an environment variable ANACONDA_WORKON_HOME. In my case I put

export ANACONDA_WORKON_HOME=$HOME/anaconda/envs

in my .bash_profile

It's pretty basic and I'm sure it could be improved in many ways, but I find it useful and I hope you do too!

EDIT: The latest Anaconda allows you to create Python3 environments. This approach works fine for these environments BUT you have to remember to use python3 and ipython3 instead of python and ipython.

conda-workon

#!/bin/bash

# conda-workon
# A simple way to work on an Anaconda env, based on
# the inve approach described by datagrok 
# https://gist.github.com/datagrok/2199506
#
# Usage:
# set an environment variable (in .profile or equivalent)
# ANACONDA_WORKON_HOME pointing to <anaconda-install>/envs
# 
# Examples:
# conda-workon <env> (optional: <command>)
# 
# conda-workon project-env
# launches a sub-shell with python run from project-env
# 
# conda-workon project-env ipython notebook
# launches the ipython notebook from project-env
    

CONDA_ENV="$ANACONDA_WORKON_HOME/$1"

if [ "" = "$1" ]; then
    echo "must specify an env"
    exit 2
fi
shift;

cd $CONDA_ENV

# Activate
export VIRTUAL_ENV="$CONDA_ENV"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME
exec "${@:-$SHELL}"

without having to re-compile stuff like numpy

Why would you have to recompile numpy when using virtualenv?

virtualenv --system-site-packages

Because most of the time you would probably want to create a virtualenv that doesn't depend on system-site-packages. For instance, I tend to reserve my system for packages sets that are difficult to run in virtualenv because you can't pip-install them, such as PyQT. But in that case if i create a new virtualenv (e.g. for data analytics) if I use system-site-packages my new env if polluted with stuff i don't want. Worse, I may need to update a numpy version for my data analytics env, which would then cause problems in my system env. Also, if I wanted to bundle an app, i would have to painstakingly whitelist which packages i shouldn or should take from the environment, rather than being able to simply package up the whole virtualenv in one go.

Thanks for your interest in conda as a replacement for virtualenv, which is exactly why we created it. I'm not sure how conda-workon, is different from the source activate and source deactivate commands which conda already comes with.

This is a completely different style than source activate. You can specify a command to run rather than a shell. Even if you just create a subshell, you just exit instead of source deactivate.

The semantics are different too. source activate modifies the current process (shell). conda-workon creates a different shell.

I like that the name of this script itself is 'conda-x' instead of 'source activate' which I definitely found obscure.

I have found (so far) that pew workon ~/anaconda is an adequate way to use Anaconda when I must. See: https://github.com/berdario/pew or more opining from me: http://planspace.org/20150120-use_pew_not_virtualenvwrapper_for_python_virtualenvs/

chmod 755 would be better (i.e., don't give write permission to the world...).