Virtualenvs with different interpreters
Update 2011-09-27: Turns out virtualenv and virtualenvwrapper support this out of the box. Most of what’s written below is horrifically complex compared to just using the -p switch when you make your virtualenv. You simply need to do this:
$ mkvirtualenv -p /path/to/some/python coolname
That’ll create a new virtualenv called “coolname” that uses /path/to/some/python for it’s Python interpreter. I’ve tested this with PyPy and it worked great.
A recent comment on the original Virtualenv Burrito announcement asked whether it was possible to create virtualenvs using different Python interepreters. The answer is a cautious: yes!
When virtualenv-burrito installs virtualenv, it prevents the virtualenv command from tying itself to a specific interpreter. I wanted to be able to switch between Python versions, creating virtualenvs for each. I haven’t publicized this feature, nor made it easy to use since there may be hidden pitfalls. That said, I’ve not run into any problems.
The way it works is mkvirtualenv uses the same interpreter invoked by the python command to create the virtualenv. For example, normally when I run mkvirtualenv I get a Python 2.7 environment. Using MacPorts, I can switch from my 2.7 default to 2.6 with:
port select --set python26
Now running mkvirtualenv creates a 2.6 environment.
Regardless of what your current default Python interpreter is, once the virtualenv is made, it stays tied to the Python used during creation.
If you don’t have a nice way to switch your default Python, you can still hack it. The key is making the python command use the interpreter you want.
The following1 will also make a Python 2.6 virtualenv even though 2.7 is the default:
Let me know if it works for you. Especially if you are trying out something other than a CPython!
-
A new directory is made with a symlink pointing
pythonto thepython2.6executable. When callingmkvirtualenv, the PATH environment is set with this new directory first so the 2.6 interpreter is used. ↩
