8

Edit #2 Solution found; see below.

I'm writing a small application in Flask using VirtualEnv. This is far from the first time I've done this, but the this time and past two times I've tried I've encountered the same problem. When I . flask/bin/activate and try to install a package -- pip install flup, for instance -- it keeps being installed globally, and not in the VirtualEnv. The weird thing is, it only happens after I deactivate, and it does so inconsistently at that.

To wit, I seem to be able to install everything I need if I do it all at once, and even occasionally after I deactivate, but after a certain interval it just stops working and it starts trying to install into my global Python site-packages. (Naturally, it's also asking for permissions when it does this. Before I understood what was going on I tried to force it with sudo, thinking I'd brought it upon myself by accidentally sudo virtualenv flask-ing or something, but nope, it's going global for some other reason.)

I'm not doing anything funny like using the --system-site-packages argument, and I hadn't changed anything in my VirtualEnv configuration before it started happening. The first time it happened, I chalked it up to a fluke. Now it's becoming seriously irritating because I'm not in the mood to uninstall everything and reinstall it each time, or pray that I'll think of everything I need in a bootstrap script.

I'm not including any error messages because they aren't (or don't seem to be) particularly valuable; it's just requirement already satisfied yelling at me over and over.

Edit #1 I'm winnowing down the problem a little bit, but I still don't have a solution. I created a new Flask project in the same directory, cd-ed into it, activated its VirtualEnv, etc., then ran which pip. It was the new VirtualEnv's pip -- the right pip. I deactivated, cd-ed to my original project, activated VirtualEnv, and ran which pip. It spit out the other project's -- the new one's -- pip. I rm -r-ed the new test project, went back to the original, ran which pip again, and it spit out /usr/local/bin/pip. Oh. OK.

Edit #2: Solution I may not have figured out the exact cause, but I did find the solution. The bin/activate and bin/pip scripts themselves were altered somehow, possibly from accidentally running two VirtualEnvs at the same time(?). Maybe it's just coincidence that it happened three times in a row after never happening before. Dunno.

I cat-ed activate and sure enough, on line 42, was

VIRTUAL_ENV="/Users/chaseries/blueprint/python/flask2/flask"

instead of

VIRTUAL_ENV="/Users/chaseries/blueprint/python/flask/flask"

I changed it, ran which pip again, and got the right result. Tried installing, got a stack trace that led me to bin/pip, and found its shebang was wrong. Changed it to the right path, and everything works perfectly.

Chase Ries
  • 2,094
  • 2
  • 15
  • 16
  • 1
    how come it has permission to install on your global python when you run it without sudo? or is it trying and failing? – Guy Gavriely Jan 06 '14 at 04:42
  • It's trying and failing, but I can't figure out why it's trying in the first place. – Chase Ries Jan 06 '14 at 04:44
  • 2
    Just run the virtualenv's pip with its full path (i.e. don't rely on searching the executable path) and you don't even need to activate the environment. It will do the right thing. – Joe Holloway Jan 06 '14 at 05:46
  • 1
    I had the same thing happen. It happened because I moved the environment location. I went and edited the activate path to its new correct location VIRTUAL_ENV="/Users/USERNAME/ENIVRONMENT_NAME" – MGM Sep 12 '14 at 08:43

4 Answers4

3

I had the same problem. For me, the cause was that my virtualenv had spaces in the path.

Moving the virtualenv to a spaceless path solved the problem.

joerick
  • 16,078
  • 4
  • 53
  • 57
3

If you have renamed your project directory containing ENV - virtual environment directory, try wiping out ENV directory and recreate virtualenv and activate it and reinstall pip dependencies.

TL-DR; Delete virtual environment, create new one, activate it and issue pip commands again.

auselen
  • 27,577
  • 7
  • 73
  • 114
  • do you mean that the virtual environment should not have "env" in its name? Because I experienced the error above in my virtual environment that has "env" in its name. (It is also inside a directory with "env" in its name.) – jflaga Jun 29 '17 at 03:10
  • followed the exemple from google gae website, solution was to replace env by an other name. – Stephane Duteriez Sep 17 '19 at 17:41
0

In my case, my pip.ini file had specified a target value: 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

mjwils
  • 456
  • 4
  • 12
-2

Use this link (Python packages not installing in virtualenv using pip).

If your shebang is ok then ensure you do not use "sudo -H" when installing to the virtual environment.

Stepan Novikov
  • 1,402
  • 12
  • 22
Chidi Nwachukwu
  • 9
  • 3