I was under the impression that virtualenv --no-site-packages would create a completely separate and isolated Python environment, but it doesn’t seem to.

For example, I have python-django installed globally, but wish to create a virtualenv with a different Django version.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

From what I can tell, the pip -E foo install above is supposed to re-install a new version of Django. Also, if I tell pip to freeze the environment, I get a whole lot of packages. I would expect that for a fresh environment with --no-site-packages this would be blank?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

Am I misunderstanding how --no-site-packages is supposed to work?

I had a problem like this, until I realized that (long before I had discovered virtualenv), I had gone adding directories to the PYTHONPATH in my .bashrc file. As it had been over a year beforehand, I didn’t think of that straight away.

You have to make sure you are running the pip binary in the virtual environment you created, not the global one.

env/bin/pip freeze

See a test:

We create the virtualenv with the --no-site-packages option:

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

We check the output of freeze from the newly created pip:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

But if we do use the global pip, this is what we get:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

That is, all the packages that pip has installed in the whole system. By checking which pip we get (at least in my case) something like /usr/local/bin/pip, meaning that when we do pip freeze it is calling this binary instead of mytest/bin/pip.

Eventually I found that, for whatever reason, pip -E was not working. However, if I actually activate the virtualenv, and use easy_install provided by virtualenv to install pip, then use pip directly from within, it seems to work as expected and only show the packages in the virtualenv

I know this is a very old question but for those arriving here looking for a solution:

Don’t forget to activate the virtualenv (source bin/activate) before running pip freeze. Otherwise you’ll get a list of all global packages.

Temporarily clear the PYTHONPATH with:

export PYTHONPATH=

Then create and activate the virtual environment:

virtualenv foo
. foo/bin/activate

Only then:

pip freeze

--no-site-packages should, as the name suggests, remove the standard site-packages directory from sys.path. Anything else that lives in the standard Python path will remain there.

A similar problem can occur on Windows if you call scripts directly as script.py which then uses the Windows default opener and opens Python outside the virtual environment. Calling it with python script.py will use Python with the virtual environment.

This also seems to happen when you move the virtualenv directory to another directory (on linux), or rename a parent directory.

I was having this same problem. The issue for me (on Ubuntu) was that my path name contained $. When I created a virtualenv outside of the $ dir, it worked fine.

Weird.

One of the possible reasons why virtualenv pip won’t work is if any of the parent folders had space in its name /Documents/project name/app renaming it to /Documents/projectName/app solves the problem.

I came accross the same problem where pip in venv still works as global pip.
After searching many pages, i figure it out this way.
1. Create a new venv by virtualenv with option “–no-site-packages”

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

please note that although the “–no-site-packages” option was default true since 1.7.0 in the doc file of virtualenv, but i found it not working unless you set it on manually. In order to get a pure venv, i strongly suggest turning this option on 2. Activate the new env you created

source ./my_env_name/bin/activate

3. Check your pip location and python location and make sure these two commands are under virtual envirement

pip --version
which python

4. Use pip under virtual env to install packages free from the global packages interuption

pip install package_name

Wish this answer helps you!

Here’s the list of all the pip install options – I didn’t find any ‘-E‘ option, may be older version had it. Below I am sharing a plain english usage and working of virtualenv for the upcoming SO users.

Every thing seems fine, accept activating the virtualenv (foo). All it does is allow us to have multiple (and varying) python environment i.e. various Python versions, or various Django versions, or any other Python package – in case we have a previous version in production and want to test the latest Django release with our application.

In short creating and using (activating) virtual environment (virtualenv) makes it possible to run or test our application or simple python scripts with different Python interpreter i.e. Python 2.7 and 3.3 – can be a fresh installation (using --no-site-packages option) or all the packages from existing/last setup (using --system-site-packages option). To use it we have to activate it:

$ pip install django will install it into the global site-packages, and similarly getting the pip freeze will give names of the global site-packages.

while inside the venv dir (foo) executing $ source /bin/activate will activate venv i.e. now anything installed with pip will only be installed in the virtual env, and only now the pip freeze will not give the list of global site-packages python packages. Once activated:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo) before the $ sign indicates we are using a virtual python environment i.e. any thing with pip – install, freeze, uninstall will be limited to this venv, and no effect on global/default Python installation/packages.