25

I create and activate a virtualenv (venv) using Python 3.3's built-in way of doing it:

$ python3.3 -m venv env
$ source env/bin/activate

At this point python is the python in my virtualenv, which I expect:

(env) $ which python
/my_home_directory/env/bin/python

Now I want to install distribute and pip, so I download the setup scripts and run them:

(env)$ wget http://python-distribute.org/distribute_setup.py
(env)$ wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py
(env)$ python distribute_setup.py
(env)$ python get-pip.py

These commands complete successfully. At this point I inspect my venv to find another directory called "local" which wasn't there before. env/local/bin contains my easy_install and pip executables, and they're still aliased to my system's existing easy_install and pip:

(env)$ ls env
bin  include  lib  local  pyvenv.cfg
(env)$ ls env/bin
activate  pydoc  python  python3  python3.3
(env)$ ls env/local/bin
easy_install  easy_install-3.3  pip  pip-3.3
(env)$ which easy_install
/usr/bin/easy_install
(env)$ which pip
/usr/bin/pip

I believe this is a departure from Python 2.x's behavior. At this point I expect easy_install and pip to be using the virtualenv's copies, and using them to install eggs will put them in the virtualenv.

Going a bit further, I crack open env/bin/activate to find that env/bin is prepended to the system path, but env/local/bin is not. That explains the behavior I'm seeing. I can work around this problem by editing env/bin/activate to add the env/local/bin directory to the path, something like:

_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
PATH="$VIRTUAL_ENV/local/bin:$PATH"  # my new line
export PATH

So, what's going on here? Is this a bug, or am I missing something?

I'm on Ubuntu 12.10 in case that makes a difference.

Frank T
  • 8,268
  • 8
  • 50
  • 67
  • I thought the virtualenv was supposed to contain `pip`/`easy_install` already? – MattDMo Mar 12 '13 at 20:41
  • Odd. I use a personal build of Python 3.3 on Debian, and distribute/pip install in `env/bin` for me. Is your copy of 3.3 from the Ubuntu repository? If it is, try building a local copy and see if that works correctly. – Eryk Sun Mar 13 '13 at 08:38
  • 4
    @MattDMo I believe pip and easy_install are included when you use the `virtualenv` command, but that doesn't seem to be the case with Python 3.3's venv module, judging from the docs. @eryksun It is indeed Ubuntu's version of Python 3.3. I'll try building locally and report back. – Frank T Mar 13 '13 at 13:19
  • I'm having trouble repeating the above steps after building Python 3.3 from source, but it appears that using `virtualenv env --no-site-packages --python=python2.7` and installing `pip` using get-pip.py will create an env/local directory, but in this case each of env/local/bin env/local/include and env/local/lib are symlinked to their env/bin env/include and env/lib, respectively. So now the question is "is this different in Python 3.3, or in Ubuntu's version of Python 3.3?" – Frank T Mar 14 '13 at 20:47
  • 3
    local directory was introduced by fix of this [bug](https://github.com/pypa/virtualenv/issues/118#issuecomment-1439290). – Stan Prokop Mar 16 '13 at 06:50
  • @Frank: Same surprise here on the missing distribute (and to some extent pip). Slight improvement suggestion: wget distribute only, then `./bin/easy_install pip` works for me. In Python 3.3.1 I don't see a `local` sub directory after that. – cfi Jun 07 '13 at 10:49
  • For the record, I'm using Ubuntu's Python 3.3 and good old virtualenv works fine, as far as I can tell. I've never tried to use the venv module. – Marius Gedminas Jan 21 '14 at 15:40

3 Answers3

2

I have a feeling there's a bug in Ubuntu's python packages or distribute somewhere… but I haven't tracked it down (and I'm not sure I care to).

For whatever reason, the VIRTUAL_ENV environment variable needs to be set the root of the virtualenv for distribute and pip to install properly.

This gist, adopted from Vinay Sajip's code sample in the Python 3 docs, sets said variable; both distribute and pip will install properly when using it.

Samat Jain
  • 15,758
  • 4
  • 20
  • 13
  • Confirmed: setting VIRTUAL_ENV to the root of the virtualenv will cause pip and distribute to be installed properly. I have tested this on Ubuntu 13.04. Thanks! – Frank T Aug 21 '13 at 13:25
1

It's in the python docs.

'/usr/local' is the default exec_prefix. Read the venv docs for detail how to change the default behaviour. There's even an example there that shows how to make a venv.EnvBuilder that installs distribute and pip for you.

if you find distribute docs, please let me know ;-)

Chris Wesseling
  • 6,226
  • 2
  • 36
  • 72
  • Good information, thanks. When my venv is activated, `sys.prefix` and `sys.exec_prefix` both point to the root of the venv. But I don't see where in the docs it explains how to get `pip` or `easy_install` working with a venv. Specifically I'm looking in the first "Note" section of the venv docs, which seems to be telling me that things should just work given my reproduce steps above. Specifically: "Of course, you need to install them into the venv first: this could be done by running distribute_setup.py with the venv activated, followed by running easy_install pip." Any idea? – Frank T Mar 22 '13 at 18:08
0

I had the same problem. In activate script file I need to add as first line (of cource after #!...):

 unset PYTHON_PATH
WBAR
  • 4,924
  • 7
  • 47
  • 81
  • 3
    If you can expand this to what is the problem and why your solution works, that would be better. – Burhan Khalid Mar 20 '13 at 16:10
  • I got the same error.. but when I add this at top of this file this solve my problem... Try it.. – WBAR Mar 21 '13 at 09:19
  • 1
    This doesn't work for me. Also my env/bin/activate doesn't have #! as its first line. As I mention in my comment above, I have my own work-around by editing env/bin/activate, but I'm trying to determine why a work-around is even necessary. – Frank T Mar 21 '13 at 17:47