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

Answer 1

"pythonbrew is a program to automate the building and installation 
 of Python in the users $HOME."

By contrast, virtualenv provides an isolated environment for developing a project - it keeps all of the libraries for that project in one place, and it makes it much easier to relocate (and so deploy) the project.

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?

Answer 3

Python brew is for building and install, maybe like some buildbot. I'm not so familiar. Virtualenv is mainly for, when you got different version of python, or you wan to try some package without disturbing on-system version.

---

Ok, this revels something

Create isolated python environments (uses virtualenv):

pythonbrew venv init
pythonbrew venv create proj
pythonbrew venv list
pythonbrew venv use proj
pythonbrew venv delete proj

From http://pypi.python.org/pypi/pythonbrew/

Answer 4

Since all the answers above are pretty old, I'd like to summarize my findings here. I was trying to figure out how this works with Python after coming from rvm/ruby and could not find a clear explanation anywhere online.

So we have the following options on Macos:

Homebrew (MacOS only)

...Can install python and python3. They will be stored in Homebrew's Cellar and symlinked from /usr/local/bin. Default python installed using brew is 2.7.6 as of now.

Packages installed using pip will go in default location (you also have pip and pip3 symlinked as well).

Pyenv (successor of Pythonbrew)

...Is an alternative to Homebrew (on Macos) way to install and maintain multiple versions of Python. Linux does not have Homebrew so Pyenv is kind of a specialized version of it just for Python. It also builds Python from source.

Pyenv keeps python installations in ~/.pyenv/versions/ and allows to quickly switch between and use same names for binaries (python, pip etc). It uses "shim" binaries which are fake binaries like python, pip etc which mimic Python's and instead just silently redirect execution to the currently active version.

Packages installed using pip will go into active Python installation.

So, neither of those methods really enough to maintain separate python installations and package version sets (like rvm does with gemsets) per project. Hence:

Virtualenv

...Is the closest thing to rvm. To quote this post:

it sets up a clean copy of Python in a new directory by copying or linking files from your primary Python installation to create new bin and lib directories

So it uses the currently active copy of Python and copies it into a separate directory. virtualenvwrapper adds functionality to manage those environments and automatically activate them using cd just like rvm does.

This allows to isolate python version and libraries installed used for each project. However, it does not install python versions itself.

Thus, sounds like most people use a combination of pyenv + virtualenv or brew + virtualenv (brew is Macos specific of course). The first part is used to install python versions (if needed) and the second one is to clone them for different projects and switch between them.

PS: I am just starting to figure it out, please correct me if anything here is wrong.

PPS: It seems to me that this whole business can be improved by combining pyenv and virtualenv under one roof...

Answer 5

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.