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