Take the 2-minute tour ×

Short Question


In my answer to SO question 4314376, I recommended using ez_setup so that you could then install pip and virtualenv as follows:

curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py
sudo easy_install pip
sudo pip install virtualenv

I originally pulled these instructions from Jesse Noller's blog post So you want to use Python on the Mac?. I like the idea of keeping a clean global site-packages directory, so the only other packages I install there are virtualenvwrapper and distribute. (I recently added distribute to my toolbox because of this Python public service announcement. To install these two packages, I used:

sudo pip install virtualenvwrapper
curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py

No more setuptools and easy_install

To really follow that Python public service announcement, on a fresh Python install, I would do the following:

curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper

Glyph's Rebuke

In a comment to my answer to SO question 4314376, SO user Glyph stated:

NO. NEVER EVER do sudo python setup.py install whatever. Write a ~/.pydistutils.cfg that puts your pip installation into ~/.local or something. Especially files named ez_setup.py tend to suck down newer versions of things like setuptools and easy_install, which can potentially break other things on your operating system.

Back to the short question

So Glyph's response leads me to my original question:

share|improve this question
Matthew, I know this thread is rather old. But is there anything new on this front? Is it still a bad idea to do python distribute_setup.py followed by easy_install pip and virtualenv --distribute venv? (see python-guide.readthedocs.org/en/latest/starting/install/…), and if so, why? –  user815423426 Apr 18 '13 at 21:26
As of June 2013, this answer seems to be the most comprehensive with regard to which packaging library should be used with virtualenv. –  chb Jun 17 '13 at 3:32
add comment

11 Answers

You can do this without installing anything into python itself.

You don't need sudo or any privileges.

You don't need to edit any files.

Install virtualenv into a bootstrap virtual environment. Use the that virtual environment to create more. Since virtualenv ships with pip and distribute, you get everything from one install.

  1. Download virtualenv:
  2. Unpack the source tarball
  3. Use the unpacked tarball to create a clean virtual environment. With the right command line options, the virtual environment will automatically contain pip and distribute.
  4. Install virtualenv into that environment.
  5. Use that first "bootstrap" environment to create more!

Here is an example in bash:

# Select current version of virtualenv:
# Name your first "bootstrap" environment:
# Options for your first environment:
# Set to whatever python interpreter you want for your first environment:
PYTHON=$(which python)

# --- Real work starts here ---
curl -O $URL_BASE/virtualenv-$VERSION.tar.gz
tar xzf virtualenv-$VERSION.tar.gz
# Create the first "bootstrap" environment.
$PYTHON virtualenv-$VERSION/virtualenv.py $ENV_OPTS $INITIAL_ENV
# Don't need this anymore.
rm -rf virtualenv-$VERSION
# Install virtualenv into the environment.
$INITIAL_ENV/bin/pip install virtualenv-$VERSION.tar.gz

Now you can use your "bootstrap" environment to create more:

# Create a second environment from the first:
$INITIAL_ENV/bin/virtualenv --no-site-packages --distribute py-env1
# Create more:
$INITIAL_ENV/bin/virtualenv py-env2

Go nuts!


The flags --no-site-packges and --distribute are now the defaults (run virtualenv -h), so you can setup your bootstrap with just python virtualenv.py bootstrap or python3 virtualenv.py bootstrap.

share|improve this answer
Works well. A little tedious, but does work. –  user37078 May 17 '11 at 1:27
Tedious only because it's very generic, a simple download, untar and then python virtualenv.py TARGET_DIRECTORY does the same thing. –  Sebastian Blask Jun 22 '11 at 16:21
This is brilliant. I adapted it to answer my more specific question about installing virtualenv across multiple versions of Python indpendently of system packages - stackoverflow.com/questions/6812207/… - works perfectly. –  d3vid Jul 29 '11 at 15:12
note: current virtualenv don't need '--no-site-packages --distribute' options. The opposite --system-site-packages might be required –  J.F. Sebastian Aug 9 '12 at 19:09
You can get the latest stable tarball with this command: curl -Lo virtualenv-tmp.tar.gz 'https://github.com/pypa/virtualenv/tarball/master' –  Bohr Jul 11 '13 at 4:07
show 2 more comments

I think Glyph means do something like this:

  1. Create a directory ~/.local, if it doesn't already exist.
  2. In your ~/.bashrc, ensure that ~/.local/bin is on PATH and that ~/.local is on PYTHONPATH.
  3. Create a file ~/.pydistutils.cfg which contains


    It's a standard ConfigParser-format file.

  4. Download distribute_setup.py and run python distribute_setup.py (no sudo). If it complains about a non-existing site-packages directory, create it manually:

    mkdir -p ~/.local/lib/python2.7/site-packages/

  5. Run which easy_install to verify that it's coming from ~/.local/bin

  6. Run pip install virtualenv
  7. Run pip install virtualenvwrapper
  8. Create a virtual env containing folder, say ~/.virtualenvs
  9. In ~/.bashrc add

    export WORKON_HOME
    source ~/.local/bin/virtualenvwrapper.sh

That's it, no use of sudo at all and your Python environment is in ~/.local, completely separate from the OS's Python. Disclaimer: Not sure how compatible virtualenvwrapper is in this scenario - I couldn't test it on my system :-)

share|improve this answer
Is ~/.local a bit of a dumb name? What if Ruby wants to do the same? Maybe ~/.python27 would be better? –  Jonathan Hartley Mar 4 '11 at 10:20
Just a note, I just tried the same thing on Windows and had to add both the local folder (called "local" for example) and "local\Lib\site-packages" to PYTHONPATH in order to successfully run distribute_setup.py. –  technomalogical Mar 14 '11 at 23:11
One last problem with this approach: virtualenv is incompatible with using the .pydistutils.cfg file. See github.com/pypa/virtualenv/issues/88 –  user37078 May 12 '11 at 15:14
I think there should be an easy_install pip between step 5 and 6. –  DiggyF Jun 27 '11 at 8:09
The ~/.local thing comes from PEP 370. –  Éric Araujo Jun 30 '11 at 14:51
show 10 more comments

If you follow the steps advised in several tutorials I linked in this answer, you can get the desired effect without the somewhat complicated "manual" steps in Walker's and Vinay's answers. If you're on Ubuntu:

sudo apt-get install python-pip python-dev

The equivalent is achieved in OS X by using homebrew to install python (more details here).

brew install python

With pip installed, you can use it to get the remaining packages (you can omit sudo in OS X, as you're using your local python installation).

sudo pip install virtualenvwrapper

(these are the only packages you need installed globally and I doubt that it will clash with anything system-level from the OS. If you want to be super-safe, you can keep the distro's versions sudo apt-get install virtualenvwrapper)

You then append to your .bashrc file

source /usr/local/bin/virtualenvwrapper.sh

and source it

. ~/.bashrc

This is basically it. Now the only decision is whether you want to create a virtualenv to include system-level packages

mkvirtualenv --system-site-packages foo

where your existing system packages don't have to be reinstalled, they are symlinked to the system interpreter's versions. Note: you can still install new packages and upgrade existing included-from-system packages without sudo - I tested it and it works without any disruptions of the system interpreter.

kermit@hocus-pocus:~$ sudo apt-get install python-pandas
kermit@hocus-pocus:~$ mkvirtualenv --system-site-packages s
(s)kermit@hocus-pocus:~$ pip install --upgrade pandas
(s)kermit@hocus-pocus:~$ python -c "import pandas; print(pandas.__version__)"
(s)kermit@hocus-pocus:~$ deactivate

The alternative, if you want a completely separated environment, is

mkvirtualenv --no-site-packages bar

or given that this is the default option, simply

mkvirtualenv bar

The result is that you have a new virtualenv where you can freely and sudolessly install your favourite packages

pip install flask
share|improve this answer
Doesn't this install both setuptools and distribute? And doesn't that break packages like Tkinter and pyopencl that don't like setuptools? –  hobs Apr 28 '13 at 19:59
Does setting WORKON_HOME to null in bashrc force venvwrapper to use something reasonable like export WORKON_HOME="$HOME/.virtualenvs"? –  hobs Apr 28 '13 at 20:48
Well, it installs whatever your package manager says pip depends on. Currently, that's setuptools in Ubuntu and OS X (brew install python pulls pip+setuptools in). This approach works fine for me. Additionaly, focusing on pip seems to be the future path in Python packaging too. –  kermit666 Apr 30 '13 at 8:10
WORKON_HOME defaults to ~/.virtualenvs, yes. There's a line in /usr/local/bin/virtualenvwrapper.sh that sets workon_home_dir="$HOME/.virtualenvs" if [ "$workon_home_dir" = "" ]. –  kermit666 Apr 30 '13 at 8:12
Got it. Thanks. Your simple approach worked great for me on Ubuntu 12.04 when pip installing modules that are picky about using distribute (pyopencl). The trick for me was following up your pip install virtualenv virtualenv-wrapper line with pip install --upgrade distribute within the activated virtualenv that I then installed pyopencl in. I also added export PROJECT_HOME="$HOME/src" to my bashrc to enable the cool mkproject venv tool. –  hobs Apr 30 '13 at 13:58
add comment

Python 3.4 onward

Python 3.3 adds the venv module, and Python 3.4 adds the ensurepip module. This makes bootstrapping pip as easy as:

python -m ensurepip

Perhaps preceded by a call to venv to do so inside a virtual environment.

Guaranteed pip is described in PEP 453.

share|improve this answer
add comment

Update: As of July 2013 this project is unmaintained. The author suggests using pyenv. (pyenv does not have build-in support for virtalenv, but plays nice with it.)

Pythonbrew is a version manager for python and comes with support for virtualenv.

After installing pythonbrew and a python-version using venvs is really easy:

# Initializes the virtualenv 
pythonbrew venv init

# Create a virtual/sandboxed environment 
pythonbrew venv create mycoolbundle  

# Use it 
pythonbrew venv use mycoolbundle
share|improve this answer
Now deprecated in favour of pyenv. –  kermit666 Sep 15 '13 at 8:20
@kermit666 thanks. What would be the prefered way to mark my answer as outdated? Just delete it? –  kioopi Sep 17 '13 at 10:16
well, you can either leave it as it is (there are instructions on using pyenv for people who follow the link from my comment, which are similar in concept to pythonbrew that you recommended) or better yet edit the answer with e.g. Update September 2013 by appending the new instructions. Maybe pythonbrew will become active once again in the future so I wouldn't delete your old instructions. For more info see meta. –  kermit666 Sep 17 '13 at 15:18
add comment

There is no problem to do sudo python setup.py install, if you're sure it's what you want to do.

The difference is that it will use the site-packages directory of your OS as a destination for .py files to be copied.

so, if you want pip to be accessible os wide, that's probably the way to go. I do not say that others way are bad, but this is probably fair enough.

share|improve this answer
Yes, I used that way. And some time later, invoking pip freeze got me almost frozen - the list of packages, being installed system wide was far too long. Since then, I strongly recommend using "no sudo" and "no os-wide" python package installation. –  Jan Vlcinsky Jul 11 '13 at 19:07
add comment

Install ActivePython. It includes pip, virtualenv and Distribute.

share|improve this answer
add comment

On ubuntu:

sudo apt-get install python-virtualenv

share|improve this answer
python-virtualenv will install both virtualenv and pip. After that just run virtualenv to create Python virtual environments. And run pip from within virtual env to install other packages. –  jemeshsu Oct 31 '13 at 4:34
add comment

I came across the same problem recently. I’m becoming more partial to the “always use a virtualenv” mindset, so my problem was to install virtualenv with pip without installing distribute to my global or user site-packages directory. To do this, I manually downloaded distribute, pip and virtualenv, and for each one I ran “python setup.py install --prefix ~/.local/python-private” (with a temporary setting of PYTHONPATH=~/.local/python-private) so that setup scripts were able to find distribute). I’ve moved the virtualenv script to another directory I have on my PATH and edited it so that the distribute and virtualenv modules can be found on sys.path. Tada: I did not install anything to /usr, /usr/local or my user site-packages dir, but I can run virtualenv anywhere, and in that virtualenv I get pip.

share|improve this answer
add comment

I made this procedure for us to use at work.

cd ~
curl -s https://pypi.python.org/packages/source/p/pip/pip-1.3.1.tar.gz | tar xvz
cd pip-1.3.1
python setup.py install --user
cd ~
rm -rf pip-1.3.1

$HOME/.local/bin/pip install --user --upgrade pip distribute virtualenvwrapper

# Might want these three in your .bashrc
source $HOME/.local/bin/virtualenvwrapper.sh

mkvirtualenv mypy
workon mypy
pip install --upgrade distribute
pip install pudb # Or whatever other nice package you might want.

Key points for the security minded:

  1. curl does ssl validation. wget doesn't.
  2. Starting from pip 1.3.1, pip also does ssl validation.
  3. Fewer users can upload the pypi tarball than a github tarball.
share|improve this answer
add comment

There are good instructions on the Virtualenv official site. https://pypi.python.org/pypi/virtualenv

Basically what I did, is install pip with sudo easy_install pip, then used sudo pip install virtualenv then created an environment with: virtualenv my_env (name it what you want), following that I did: virtualenv --distribute my_env; which installed distribute and pip in my virtualenv.

Again, follow the instruction on the virtualenv page.

Kind of a hassle, coming from Ruby ;P

share|improve this answer
add comment

Your Answer


