pip installing in global site-packages instead of virtualenv

Question

Using pip3 to install a package in a virtualenv causes the package to be installed in the global site-packages folder instead of the one in the virtualenv folder. Here's how I set up Python3 and virtualenv on OS X Mavericks (10.9.1):

I installed Python3 using Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Changed the $PATH variable in .bash_profile; added the following line:

export PATH=/usr/local/bin:$PATH

Running which python3 returns /usr/local/bin/python3 (after restarting the shell).

Note: which python3 still returns /usr/bin/python though.

Installed virtualenv using pip3:

pip3 install virtualenv

Next, create a new virtualenv and activate it:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Note: if I don't specify -p python3, pip will be missing from the bin folder in the virtualenv.

Running which pip and which pip3 both return the virtualenv folder:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Now, when I try to install e.g. Markdown using pip in the activated virtualenv, pip will install in the global site-packages folder instead of the site-packages folder of the virtualenv.

pip install markdown

Running pip list returns:

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Contents of /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Contents of /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

As you can see, the global site-packages folder contains Markdown, the virtualenv folder doesn't.

Note: I had Python2 and Python3 installed before on a different VM (followed these instructions) and had the same issue with Python3; installing packages in a Python2 based virtualenv worked flawlessly though.

Any tips, hints, … would be very much appreciated.

Answer 1

for Windows you have to temporary delete original python path in environment variable

check your current Path with echo %PATH%, example result

C:\Program Files\;C:\Python\;C:\Python\Scripts\;C:\Windows\system32;

we need to delete C:\Python\;C:\Python\Scripts\; now open env\Scripts\activate.bat add line

set PATH=%PATH:C:\Python\;C:\Python\Scripts\;=%
set PATH=%PATH%;D:\env;D:\env\Scripts

replace D:\env with your real env location

Answer 2

It's amazing how many solutions there are to this intricate problem, and especially amazing (for me) how none of them were what I needed to resolve my issue. In my case, the pip.ini file had specified a target value and removing the target resolved the problem.

broken pip.ini

[global]
index-url = work-artifactory-cloud-api-key
trusted-host = work-artifactory-cloud
proxy = http://work-artifactory-cloud.com:2000/
target = ~/site-packages

fixed pip.ini

[global]
index-url = work-artifactory-cloud-api-key
trusted-host = work-artifactory-cloud
proxy = http://work-artifactory-cloud.com:2000/

you may not need "index-url", "trusted-host" and "proxy" if you're using a personal machine. I'm not great at python, and I'm much worse at SysAdmin, but thankfully I stumbled across the right GitHub Issue that helped debug this issue for me: https://github.com/pypa/pip/issues/11154

You can find where your pip.ini file is by running pip config debug and you can see what's inside this pip.ini by running pip config list

Answer 3

I had the same problem, I solved it by removing venv directory and recreating it!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Now everything works like a charm.

Edit: Here's the above code modified for Python3's venv:

deactivate # (if venv is activated first deactivate it)
rm -rf venv # Delete the old venv directory
python3 -m venv venv # Recreate a new, empty venv
. venv/bin/activate # Activate it
pip3 install -r requirements.txt # Install the dependencies

Answer 4

I had the same problem. Pip installing only globally. It means there is a problem in pip's configuration.

First, find pip config files:

python -m pip config debug

It will list all pip config files. If there 'false' (no file), create it (or add line respect - virtualenv = true):

   [global]
   default-timeout = 60
   respect-virtualenv = true
   download-cache = /tmp
   log-file = /tmp/pip-log.txt

Answer 5

I had this problem and fixed it by removing spaces in my directories leading to venv path.

Answer 6

For those who checked the python and pip has correct virtualenv path, another possible problem lies in pip configuration

In my case, i added --prefix in config file to install packages in different paths. This is picked up by virtualenv pip which resulted in installing in the same place as global pip.

Answer 7

I checked all the answers here but none of them worked for me. Especially checked Chase Ries's answer and directories were correct in pip.exe and activate.bat ( for Windows )

I solved the issue by copying the pip.ini ( for Windows, I think it's something else for other OS) which was located in C:\Users\oguno\AppData\Roaming\pip to C:\Users\oguno\Desktop\iec61850\myenv3 where my venv located and change the the target as C:\Users\oguno\Desktop\iec61850\myenv3\Lib\site-packages which shows the site-packages in my virtual environment.

Answer 8

1. Activate virtual env
2. Use where pip to find out pip location, if in base env, probably 'pip' is not installed
3. Type

conda install pip

Enjoy!

Answer 9

I had a similar problem on Windows. It was caused by renaming folder structures in my project within a virtualenv folder name. The paths in files didn't change but stayed as they were when virtual env was created. As Chase Ries mentioned I've changed the paths to VIRTUAL_ENV and python.exe in files

1. ./venv/Scripts/activate.bat, set "VIRTUAL_ENV=path_to_venv\venv" 11 line in file
2. ./venv/Scripts/Activate.ps1, $env:VIRTUAL_ENV="path_to_venv\venv" 30 line in file
3. ./venv/Scripts/pip.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line, I am working on disc d so at the begining of the path is the letter of it
4. ./venv/Scripts/pip3.7.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line
5. ./venv/Scripts/pip3.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line

Answer 10

I also encountered this problem, it troubled me for a long time, until I solved it according to @Chase Ries method.

The key to solving the problem is：

Try checking your bin/pip and bin/activate scripts. In bin/pip, look at the shebang. Is it correct? If not, correct it. Then on line ~42 in your bin/activate, check to see if your virtualenv path is right. It'll look something like this

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

If it's wrong, correct it, deactivate, then . bin/activate, and if our mutual problem had the same cause, it should work.

Below, I will explain this process in detail in the Ubuntu environment, the same is true for Windows and MacOS.

The meaning of this sentence is that we need to check whether the first line #!/path/python of the bin/pip file in the virtual environment is correct.

As originally shown in my file:

#!/home/banni/dai/.venv/bin/python3

Run pip in terminal（absolute path）：

/home/banni/dai/.venv/bin/pip

Will find an error：

bash: ./pip: /home/banni/dai/.venv/bin/python3: bad interpreter: No such file or directory

Now I am confused why I can't find this python3, because python3 exists in the folder .venv/bin where the virtual environment is located.

I check the absolute path of the folder .venv/bin. After executing the pwd command, it displays:

/home/banni/Research/dai/.venv/bin

Carefully observe that the path of the .venv folder has changed. Change the first line of the /bin/pip file to

#!/home/banni/Research/dai/.venv/bin/python3

In the same way, check and modify the bin/activate file.

I changed VIRTUAL_ENV="/home/banni/dai/.venv" to VIRTUAL_ENV="/home/banni/Research/dai/.venv"

At this point, after activating the virtual environment, the pip command can be executed normally.

So, for me, the reason for this problem is that the path of the folder where the virtual environment is located has changed (a secret problem that was left when the folders were organized before).

However, due to the change in the location of the folder where the virtual environment is located, there may be many path errors, so the easiest way is to restore the folder where the virtual environment is located to the original location.

Answer 11

WINDOWS

For me solution was not to use mkvirtualenv, but:

python -m venv path/to/your/virtualenv

workon works correctly.

while in virtualenv: pip -V shows virtualenv's path to pip

Answer 12

I had the same issue on macos with python 2 and 3 installed.

Also, I had aliases to point to python3 and pip3 in my .bash_profile.

alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3

Removing aliases and recreating virtual env using python3 -m venv venv fixed the issue.

Answer 13

Lot of good discussion above, but virtualenv examples were used. Since 'conda' is now the recommended tool to manage virtualenv, I have summarized the steps in running pip in conda env as follow.

I'll use py36r as the name of the env, and /opt/conda/envs is the prefix to the envs):

$ source /opt/conda/etc/profile.d/conda.sh # skip if already done 
$ conda activate py36r
$ pip  install pkg_xyz
$ pip  list | grep pkg_xyz

Note that the pip executed should be in /opt/conda/envs/py36r/bin/pip (not /opt/conda/bin/pip).

Alternatively, you can simply run the following without conda activate

$ /opt/conda/envs/py36r/bin/pip

Also, if you install using conda, you can install without activate:

$ conda install -n py36r pkg_abc ...

Answer 14

Short answer is run Command virtualenv with parameter “—no-site-packages”.

Long answer with explanation :-

So after running here and there, and going through lot of threads i found my self the problem. Above answers have given the idea but I would like to go again over everything though.

• The problem is even if you’re activating the environment it’s referring to the system environment because of the way we have crated the virtualenv.

• when we run the command virtualenv env -p python3 it will install the virtualenv but it will not create no-global—site-packages.txt.

• Because of that when you activate the environment by source activate command there this file called site.py (name can be different, i just forgot ) which runs and checks if this file is not present it will not add your env path to sys.path and use systems python.

• to fix this issue just run virtualenv with extra parameter —no-site-packages it will create that file and when you activate the environment it will add your custom environment path in your PATH variable making it accessible.

Answer 15

I stumbled upon the same problem running Manjaro. I created the virtual environment using python3 -m ven venv and then activated using source venv/bin/actiave. which python and which pip both pointed towards the correct binaries in the virtualenv, however I was not able to install to the virtualenv, even when using the full path of the binaries. Turned out that when I uninstalled the python-pip package with sudo pacman -R python-pip python-reportlab (had to include reportlab to satisfy dependencies) everything started to work as expected. Not sure why, but this is probably due to a double install where the system package is taking precedence.

Answer 16

I had exactly the problem from the title, and I solved it. Pip started to install in the venv site-packages after I cleaned my PATH: it had a path to my local ~/bin directory at the very beginning.

So, my advice: thoroughly check your environment variables for "garbage" or any non-standard things. Unfortunately, virtualenv can be sensitive to those.

Good luck!

Answer 17

I have to use 'sudo' for installing packages through pip on my ubuntu system for some reason. This is causing the packages to be installed in global site-packages. Putting this here for anyone who might face this issue in future.

Answer 18

I had this problem, and after trying all the above solution I just removed everything and started afresh.

In my own case i used sudo in creating one of the folders in which the virtual environment existed, and sudo give the priviledges to root

I was very pissed! But it worked!

Answer 19

After creating virtual environment, try to use pip located in yourVirtualEnvName\Scripts

It should install a package inside Lib\site-packages in your virtual environment

Answer 20

Go to bin directory in your virtual environment and write like this:

./pip3 install <package-name>

Answer 21

Somehow a setup.cfg file with a prefix="" in the project folder

running pip install on the virtualenv outside the project folder worked so from the inside it was telling pip to use an empty prefix which defaults to "/"

removing the file fixed it

Answer 22

It happened to me when I installed virtualenv with --python=python3.6 flag but afterwards tried to use pip2 install.
Creating virtualenv with flag of the version that you'll use solves permission problems. To check, try which pip or which pip2 or which pip3 (depends on your choice). If any pip you use shows path not to venv here is your problem.

Answer 23

None of the above solutions worked for me.

My venv was active. pip -V and which pip gave me the correct virtualenv path, but when I pip install-ed packages with activated venv, my pip freeze stayed empty.

All the environment variables were correct too.

Finally, I just changed pip and removed virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Reinstall venv:

sudo pip install virtualenv

Create venv:

python -m virtualenv venv_name_here

And all packages installed correctly into my venv again.

Answer 24

Had this issue after installing Divio: it had changed my PATH or environment in some way, as it launches a terminal.

The solution in this case was just to do source ~/.bash_profile which should already be setup to get you back to your original pyenv/pyenv-virtualenv state.

Answer 25

This happened to me when I created the virtualenv in the wrong location. I then thought I could move the dir to another location without it mattering. It mattered.

mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]

Oh crap, I forgot to cd into projects before creating the virtualenv and cloning the rep. Oh well, I'm too lazy to destroy and recreate. I'll just move the dir with no issues.

cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements

Nope, wants more permissions, what the? I thought it was strange but SUDO AWAY! It then installed the packages into a global location.

The lesson I learned was, just delete the virtualenv dir. Don't move it.

Answer 26

This problem occurs when create a virtualenv instance and then change the parent folder name.

Answer 27

I had this problem. It turned out there was a space in one of my folder names that caused the problem. I removed the space, deleted and reinstantiated using venv, and all was well.

Answer 28

Here are some practices that could avoid headaches when using Virtual Environments:

• Create a folder for your projects.
• Create your Virtualenv projects inside of this folder.
• After activating the environment of your project, never use "sudo pip install package".
• After finishing your work, always "deactivate" your environment.
• Avoid renaming your project folder.

---

For a better representation of this practices, here is a simulation:

creating a folder for your projects/environments

$ mkdir venv

creating environment

$ cd venv/ 

$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.

activating environment

$ source google_drive/bin/activate

installing packages

(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...    
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...

package available inside the environment

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>  
>>> gdrive = pydrive.auth.GoogleAuth()
>>>

deactivate environment

(google_drive) $ deactivate 

$ 

package NOT AVAILABLE outside the environment

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>> 

---

Notes:

Why not sudo?

Virtualenv creates a whole new environment for you, defining $PATH and some other variables and settings. When you use sudo pip install package, you are running Virtualenv as root, escaping the whole environment which was created, and then, installing the package on global site-packages, and not inside the project folder where you have a Virtual Environment, although you have activated the environment.

If you rename the folder of your project (as mentioned in the accepted answer)...

...you'll have to adjust some variables from some files inside the bin directory of your project.

For example:

bin/pip, line 1 (She Bang)

bin/activate, line 42 (VIRTUAL_ENV)

Answer 29

The first thing to check is which location pip is resolving to:

which pip

if you are in a virtualenv you would expect this to give you something like:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

However it may be the case that it's resolving to your system pip for some reason. For example you may see this from within your virtualenv (this is bad):

/usr/local/bin/pip (or anything that isn't in your virtualenv path).

To solve this check your pipconfig in:

~/.pipconf
~/.conf/pip
/etc/pip.conf

and make sure that there is nothing that is coercing your Python path or your pip path (this fixed it for me).

Then try starting a new terminal and rebuild your virtualenv (delete then create it again)

Answer 30

For Python 3ers

Try updating. I had this exact same problem and tried Chases' answer, however no success. The quickest way to refactor this is to update your Python Minor / Patch version if possible. I noticed that I was running 3.5.1 and updated to 3.5.2. Pyvenv once again works.