python: what's the difference between pythonbrew and virtualenv?

Question

I am new to python and I am planning to learn django. I had a bit of experience with ruby (not rails) and I am familiar with RVM however I don't understand the difference between pythonbrew and virtualenv. I know pythonbrew is a mimic of RVM but I thought virtualenv is already doing what RVM does (or vice versa that pythonbrew is already doing what RVM does). Can someone please explain and perhaps provide some concrete examples/usages to help me understand it. Thanks very much!

Answer 1

Pythonbrew is akin to Ruby's rvm: It's a shell function that allows you to:

• Build one or more complete self-contained versions of Python, each stored locally under your home directory. You can build multiple versions of Python this way.
• Switch between the versions of Python easily.

The Pythons you build are completely isolated from each other, and from whatever version(s) of Python are installed system-wide.

Virtualenv is similar, but not quite the same. It creates a Python virtual environment that, conceptually, sits on top of some existing Python installation (usually the system-wide one, but not always). By default, on Unix platforms (and the Mac), it creates symbolic links to the various Python library modules, so you're literally sharing those modules with the "real" underlying Python implementation. But, virtualenv has its own "bin" directory and "site-packages" directory. Anything extra you install in the Python virtual environment is only available within that environment.

One advantage to Pythonbrew is that the Python environments it creates are truly, and completely, self-contained. They cannot be contaminated by anything that gets screwed up in an underlying base Python install, because there isn't an underlying base install. This is not true of virtualenv environments. If you create a virtualenv Python, and then you somehow screw up the base Python instance it sits above (e.g., accidentally deleting part of the base Python's "site" directory while logged in as root), you'll screw up any virtualenv environment based on that Python, too.

However, virtualenv has its own advantages. Probably the biggest advantage is that it is lightweight. Since Pythonbrew compiles Python from scratch, to create one of its environments, creating a Pythonbrew Python environment takes some time. By comparison, creating a virtualenv Python environment is really fast.

You can, in fact, use them together. Here's one situation where you might want to do that.

• Your base system uses Python 2.6.
• You need to install Python 2.7.
• For whatever reason, you can't (or don't want to) install Python 2.7 system wide, side-by-side with Python 2.6.

In such a case, you could use Pythonbrew to install a base Python 2.7 under your home directory, where it doesn't conflict with anything installed elsewhere. Then, you can create one or more lightweight virtualenv Python environments that are based on your Pythonbrew-installed 2.7 Python. For instance, you could use virtualenv to spin up short-lived test environments for Python 2.7 that way.

I doubt most people actually do that. (I don't.) But there's no reason you can't.

Answer 2

For what its worth I've never heard of PythonBrew before, but I know (and love) virtualenv.

Virtualenv is used to create separate environments, based on the python install you have on your machine. That is, if I have python 2.7 I can create a number of isolated python 2.7 environments, but I can't create python2.6 environments.

According to this (which I found via google) Pythonbrew seems to be focussed on installing other python versions. So I guess you would use 'brew to install py2.6 and 2.7 and then virtualenv to create environments for each.

Or, it seems, 'brew can create the environments too, using virtualenv.

Why a different python interpreter is not really an isolated environment.

Each python installation has a set of packages (placed in 'site-packages' I think). If you install a new package it is added to this set, and available for all your python code.

This can be a problem if you have one project that you build on Django0.96 and you want to start a new project using Django1.3. If you just update your system version of Django that would affect you old project too.

With virtualenvs you could create one environment with Django1.3 and another with Django0.96, both being python2.7. If you were OK with running your old project in python2.6 and the new one in python2.7 you could do that too, but what about your next two projects using diffenret versions from Django-Trunk then?