Python: What's the Difference Between Pythonbrew and Virtualenv

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

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.

Manage python version in different virtualenv with pythonbrew

Maybe you should look http://pypi.python.org/pypi/pythonbrew/ instead. When I did it, I used pythonbrew to create the venv

pythonbrew install 2.7.3
pythonbrew switch 2.7.3
pythonbrew venv create proj

Worked like a champ.

I've taken to creating my virtual environments in a .folder underneath my git repo so that I can dispose of the virtual environment without messing with my code and rebuild it if I so desire. I bumped into this technique while working with jenkins which does the git clone for you, then you have to figure out how to build a virtual environment around it.

Python/proj
    .proj           <---- Virtual environment is in here!
        lib
        site-packages
    settings
    requirements
    apps

I also have a bash function that does workon for me.

function workon() {
     if [ -d ~/Python/$1 ]
     then
            cd ~/Python/$1
            if [ -d .$1 ]
            then
                . .${1}/bin/activate
            else
                . bin/activate
                cd $1
            fi
     fi
}

This one is overly complicated to deal with old projects where the clone was done inside the virtual environment as well as the new ones where the virtual environment is inside the project.

What is the difference between pyenv, virtualenv, anaconda?

Edit: It's worth mentioning pip here as well, as conda and pip have similarities and differences that are relevant to this topic.

pip: the Python Package Manager.

You might think of pip as the python equivalent of the ruby gem command
pip is not included with python by default.
You may install Python using homebrew, which will install pip automatically: brew install python
The final version of OSX did not include pip by default. To add pip to your mac system's version of python, you can sudo easy_install pip
You can find and publish python packages using PyPI: The Python Package Index
The requirements.txt file is comparable to the ruby gemfile
To create a requirements text file, pip freeze > requirements.txt
Note, at this point, we have python installed on our system, and we have created a requirements.txt file that outlines all of the python packages that have been installed on your system.

pyenv: Python Version Manager

From the docs: pyenv lets you easily switch between multiple versions of Python. It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well. This project was forked from rbenv and ruby-build, and modified for Python.
Many folks hesitate to use python3.
If you need to use different versions of python, pyenv lets you manage this easily.

virtualenv: Python Environment Manager.

From the docs: The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.
To create a virtualenv, simply invoke virtualenv ENV, where ENV is is a directory to place the new virtual environment.
To initialize the virtualenv, you need to source ENV/bin/activate. To stop using, simply call deactivate.
Once you activate the virtualenv, you might install all of a workspace's package requirements by running pip install -r against the project's requirements.txt file.

Anaconda: Package Manager + Environment Manager + Additional Scientific Libraries.

From the docs: Anaconda 4.2.0 includes an easy installation of Python (2.7.12, 3.4.5, and/or 3.5.2) and updates of over 100 pre-built and tested scientific and analytic Python packages that include NumPy, Pandas, SciPy, Matplotlib, and IPython, with over 620 more packages available via a simple conda install <packagename>
As a web developer, I haven't used Anaconda. It's ~3GB including all the packages.
There is a slimmed down miniconda version, which seems like it could be a more simple option than using pip + virtualenv, although I don't have experience using it personally.
While conda allows you to install packages, these packages are separate than PyPI packages, so you may still need to use pip additionally depending on the types of packages you need to install.

See also:

conda vs pip vs virtualenv (section in documentation from anaconda)
the difference between pip and conda (stackoverflow)
the relationship between virtualenv and pyenv (stackoverflow)

Use different Python version with virtualenv

NOTE: For Python 3.3+, see The Aelfinn's answer below.

Use the --python (or short -p) option when creating a virtualenv instance to specify the Python executable you want to use, e.g.:

virtualenv --python="/usr/bin/python2.6" "/path/to/new/virtualenv/"

Set python version for each virtualenv using virtualenvwrapper

You should be able to use the -p option when creating a virtualenv using virtualenvwrapper to specify the version: mkvirtualenv -p /usr/bin/python2.7 my_env.

How can I run a python script using pythonbrew venv from the command line?

I believe it can be done by using the python binary directly from you pythonbrew virtual environment.
By default its in ~/.pythonbrew/venvs/Python-<version>/<name of venv>/bin/python
But I think you can change the path with an environmental variable.

So just change the first half of the line you added to reference the pythonbrew virtual environment python binary and it should work.

Python: What's the Difference Between Pythonbrew and Virtualenv