virtualenv

Yesterday, virtualenv-burrito 2.7 was released. There are two significant changes:

1. All Python packages in the .venvburrito directory are now inside a versioned site-packages directory. For example, if you are running Python 2.7 during the install or upgrade, all packages will now live in lib/python2.7/site-packages.
2. The pip program is no longer user accessible (i.e., in the PATH). You could easily figure out where it’s been moved, but that’s discouraged (and unsupported).

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.

This Python breakfast just got tastier. A major update to the way Virtualenv Burrito works was released this weekend. There is now full support for extension points and a less hackish way of managing the packages¹ under the hood.

Over the weekend I finished¹ a tool called Virtualenv Burrito. It’s goal was to be a single command which would setup Virtualenv and Virtualenvwrapper so you could start hacking on Python projects as quickly as possible. As a bonus, it installs the virtualenv-burrito command which will upgrade those packages to the latest versions I’ve tested.