Thursday, December 19, 2013

anaconda python 3.3 on Windows

I've been using python 2.7, however it seems that now most of the libraries I use are compatible with 64-bit python 3.3 (for some, such as Biopython, there is no official python 3.3 binary, but they are available here). The one package that keeps me from breaking away from python 2.7 for good is Gurobi, which still has no python 3 support.

My main operating systems are Windows 7 and Windows 8, when I need Linux (which is often) I run it through VirtualBox.

After a few years of playing around with different Python distributions, I've found Anaconda python to be the least frustrating option, it also makes it easy to switch between two versions of Python.

The default is python 2.7, but to install python 3, simply run the command:
conda create -n py3k python=3 anaconda
py3k in this case being an arbitrary name for new environment.

To switch to python 3, run:
activate py3k
To switch back to python 2.7 (the default environment), run:

activate and deactivate didn't work for me at first, I think because I had an old version of Anaconda. To get them to work, I first had to run:
conda update conda
and then everything seemed to work fine, and I was able to switch between Python 2 and 3 with ease.

One other thing, to install packages to an environment other than the default environment, you have to specify the environment when you call conda, for example when I wanted to install Django to my Python 3 environment, I used:
conda install -n py3k django==1.6

It seems that the changes made by activate and deactivate are local to a particular instance of the cmd shell, so when you close the shell and reopen it, the changes to environment variables are reset. The commands also don't seem to work with Powershell (which is the shell I typically use). I don't know for sure but I suspect that the reason they don't work in Powershell is that to execute a .bat file, powershell opens and instance of cmd, runs the script, and then closes the instance of cmd, so the changes to PATH only exist in the temporary instance of cmd and don't propagate to the Powershell instance. I'd prefer if the changes were global, but I can see how that might cause problems and unexpected behavior.
The powershell behavior might also be due to a permissions issue as explained in the virualenv documentation.


No comments:

Post a Comment