virtualenv --no-site-packages and pip still finding global packages?

Question

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?

Deaf

@SalemBenMabrouk Link broken, new link here. Related issue on Github: Did the '--no-site-packages' flag recently disappear? – Malapert

In that link, it says --no-site-packages is DEPRECATED. Retained only for backward compatibility. Not having access to global site-packages is now the default behavior. If you want to access to global site-packages, you might enable --system-site-packages. – Malapert

Deprecated since which version, @Ynjxsjmh? I guess we still need explicit --no-site-packages if older versions of python/virtualenv might be in place? – Deferment

@AaronMcDaid I didn't investigate this, but the author of github issue I mentioned said it disappeared at least in 20.0.0. For older version of virtualenv, we still need explicit --no-site-packages. – Malapert

This question is obsolete: as far as I can tell, Pip hasn't had a -E option in a very long time. – Passing

Answer 1

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.

Vision

My hero! If you just want to check if that is your issue really quickly, you can run printenv to see if PYTHONPATH is there, and if it is, run unset PYTHONPATH. You'll still have to go track down the problem if you don't want the issue to pop up anymore, but that'll let you get a fresh virtualenv set up in the current shell session. – Comical

Homebrew does this too! – Brattice

I wish I could upvote you more. I've come to this page more than once after encountering stuff that was because of my PYTHONPATH being already set. – Humber

I know this is a really (really) old post, but I have searched everywhere, including asking some of my own questions on SO, and I cannot figure out how to get --no-site-packages to work. I'm getting close to just wiping ubuntu and seeing if that fixes things. I thought initially that I was having the same PYTHONPATH problem, but on running printenv, I can't see it. Frustration is mounting, and any help is much appreciated. My sys.path from inside a venv created with --no-site-packages appears to include all of my package directories. I haven't the foggiest how to modify this. Help? – Alecalecia

This can also apply to your global PATH variable if you are finding executables from outside the virtualenv too. – Breathless

Make sure you activate the new env too before obtaining the list of packages of pip freeze. Otherwise you'll get a list of the global packages and not a list of the packages in the new environment. (See finspin's answer.) – Feverous

Unsetting PYTHONPATH before creating virtual environment enabled making clean environment, this answer helped – Starch

Thanks Python Man! I just print envs with printenv as suggested in 1st comment and saw a big old mess. I entered ~./bash_profile and clean all old python messes. – Agitate

Answer 2

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.

Ought

I had the same problem. I wonder how did it happen, since at first calling pip freeze did show me the correct packages, but a couple of days later it started calling the one located at /usr/local/bin/ ... – Araujo

This was the issue for me: I had aliased pip to a specific path to the global pip, which was not being overridden when activating the virtualenv. – Jens

You just saved me, this worked well for me (pip3 & python3.7) Thanks – Ordnance

Answer 3

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

Deaf

FWIW, with current trunk versions of pip and virtualenv your original workflow now does the right thing, for me anyway. That said, I personally still avoid -E and just install pip in each virtualenv. – Angy

Answer 4

Temporarily clear the PYTHONPATH with:

export PYTHONPATH=

Then create and activate the virtual environment:

virtualenv foo
. foo/bin/activate

Only then:

pip freeze

Multiphase

Temporarily cleaning PYTHONPATH by calling unset PYTHONPATH and creating venv immediately afterwards helped. – Starch

Answer 5

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.

Hegelian

CORRECT ANSWER. after initializing virtualenv you must activate it or you will be using the system version of python – Cotyledon

Answer 6

--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.

Gilley

For me cleaning my PYTHONPATH with export PYTHONPATH= seemed to do the trick. – Shanel

Cleaning PYTHONPATH with unset PYTHONPATH helped. After that, calling python3 -m venv ./venv_dir should initiate virtual environment, just that --no-site-packages option is not recognized. Once venv is activated, pip freeze lists packages of a clean virtual environment. – Starch

Answer 7

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.

Energid

There should be a shebang line at the top of the script (begining with '!#') that wil point to the interpreted that is to e used. – Vision

Answer 8

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

Feria

Answer 9

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.

Alecalecia

Answer 10

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.

Assailant

Answer 11

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.

Blackpool

Answer 12

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!

Attired

virtualenv works with python2 by default, it is substituted with venv in python3 – Starch

Answer 13

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.

Smallsword

Answer 14

for anyone updated to ubuntu 22.04 or confused by the same problem, remove the installed pip first, re-install the pip to /usr/local/bin, according to the doc in python.org, by the time is 3.10.5, run:

sudo python get-pip.py --prefix=/usr/

you need to download the script if you don't have one.After success message return, install virtualenv or poetry, it would notice you that /usr/local is not writable, and would install to ~/.local/what/ever, that' fine. And then everything is good to go, use virtualenv to re-create the venv folder in your project dir. if anything strange happend, use which command to check the path of pip3 or virtualenv, and remove them.

Resplendence

Answer 15

My issue was that I had installed virtual env as followed

python3 -m venv venv

Then after activating the venv, I was running

python3 main.py

Which just relied on global packages, as it wasn't prompting me to install packages.

Running the below did the trick

python main.py

Oiler