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.
