I am trying to create a virtualenv and install packages from requirements.txt that I have with the project.

When I create the environment, I check that the python and pip indeed come from that enviroment. Namely, when I run:

source ./virtualenv/bin/activate

which pip

which python

I get results that point to the binaries located inside the virtualenv directory

I then proceed to install the packages: pip install -r requirements.txt

For awhile, it was giving me trouble about the pkg-resources=0.0.0 line within the requirements.txt. As it turned, that line is input into this file because of a bug in Ubuntu. As you can probably surmise, I had created this file on an Ubuntu machine.

Once I strike the line out, the installation proceeds.

However, when I run pip list after the installation, the list contains only

pip (8.1.1) pkg-resources (0.0.0) setuptools (20.7.0)

What is more, if I deactivate the virtualenv and run pip list globally, I see that all of the dependencies were installed globally.

There are two questions here. One - that is most obious - why does it happen? The second one is how could I clean up my global packages and uninstall the pollutants which now reside there?


Yet another bizarre behavior consists of the following. When I try to run sudo pip uninstall -r requirements.txt from within the virtualenv with hopes of reversing the global installation, I get the following error:

Cannot uninstall requirement aldryn-apphooks-config, not installed

That is, it appears that when I try to uninstall, pip tries to look for packages inside the virtualenv.

On the other hand, when I deactivate the virtualenv, I can successfully uninstall the packages from the global installation using the same command.

Somehow, there is a difference in how the pip install command works on Ubuntu when compared to the pip uninstall command. They "look" for packages in different places.

  • I had the exact same issue. I deactivated virtualenv switched to root and activated the virtualenv again. The problem was gone after that. – bro-grammer Sep 22 '17 at 10:42
  • That solution may not be an option if you are working on AWS. – MadPhysicist Sep 22 '17 at 12:59
  • I was working on an azure instance, they allow to switch user to root in there console. Don't know much about AWS. Basically what i suspect is that whatever user you are using should have write access(or maybe write+execute access) – bro-grammer Sep 22 '17 at 14:09
  • My suspicion was slightly different. I suspected that the Ubuntu repository packages for Python somehow had this bug in them. The problem fixed itself after some updates and server re-creation. – MadPhysicist Sep 22 '17 at 15:28
  • Glad that you solved it! – bro-grammer Sep 22 '17 at 16:36

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.