virtualenv --no-site-packages and pip still finding global packages?
PythonVirtualenvPipPython Problem Overview
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?
Python Solutions
Solution 1 - Python
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.
Solution 2 - Python
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.
Solution 3 - Python
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
Solution 4 - Python
Temporarily clear the PYTHONPATH with:
export PYTHONPATH=
Then create and activate the virtual environment:
virtualenv foo
. foo/bin/activate
Only then:
pip freeze
Solution 5 - Python
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.
Solution 6 - Python
--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.
Solution 7 - Python
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.
Solution 8 - Python
This also seems to happen when you move the virtualenv directory to another directory (on linux), or rename a parent directory.
Solution 9 - Python
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.
Solution 10 - Python
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.
Solution 11 - Python
Here's the list of all the pip install [options][1] - 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.
[1]: http://pip.readthedocs.org/en/stable/reference/pip_install/#options
Solution 12 - Python
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.
- 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
- Check your pip location and python location and make sure these two commands are under virtual envirement
pip --version
which python
- Use pip under virtual env to install packages free from the global packages interuption
pip install package_name
Wish this answer helps you!
Solution 13 - Python
My problem was the pip and python3 versions. For the latest version of django installation, pip3 is necessary. So my problem was solved after creating the virtual environment using the following commands:
> virtualenv --python=python3 venv
> source venv/bin/activate
> which pip3 #should be different from /usr/local/bin/pip3
...<some-directory>/venv/bin/pip3
PS This problem occurred because the default version of my python in ubuntu was 2.7. By using the above command it would ignore the default version.