Bypass confirmation prompt for pip uninstall

I'm trying to uninstall all django packages in my superuser environment to e开发者_Go百科nsure that all my webapp dependencies are installed to my virtualenv.

sudo su
sudo pip freeze | grep -E '^django-' | xargs pip -q uninstall

But pip wants to confirm every package uninstall, and there doesn't seem to be a -y option for pip. Is there a better way to uninstall a batch of python modules? Is rm -rf .../site-packages/ a proper way to go? Is there an easy_install alternative?

Alternatively, would it be better to force pip to install all dependencies to the virtualenv rather than relying on the system python modules to meet those dependencies, e.g. pip --upgrade install, but forcing even equally old versions to be installed to override any system modules. I tried activating my virtualenv and then pip install --upgrade -r requirements.txt and that does seem to install the dependencies, even those existing in my system path, but I can't be sure if that's because my system modules were old. And man pip doesn't seem to guarantee this behavior (i.e. installing the same version of a package that already exists in the system site-packages).

starting with pip version 7.1.2 you can run pip uninstall -y <python package(s)>

pip uninstall -y package1 package2 package3

or from file

pip uninstall -y -r requirements.txt

Pip does NOT include a --yes option (as of pip version 1.3.1).

WORKAROUND: pipe yes to it!

$ sudo ls  # enter pw so not prompted again
$ /usr/bin/yes | sudo pip uninstall pymongo

If you want to uninstall every package from requirements.txt,

pip uninstall -y -r requirements.txt

on www.saturncloud.io, Jupiter notebooks one can use like this:

!yes | pip uninstall tensorflow
!yes | pip uninstall gast
!yes | pip uninstall tensorflow-probability

Alternatively, would it be better to force pip to install all dependencies to the virtualenv rather than relying on the system python modules to meet those dependencies,

Yes. Don't mess too much with the inbuilt system installed packages. Many of the system packages, particularly in OS X (even the debian and the derived varieties) depend too much on them.

pip --upgrade install, but forcing even equally old versions to be installed to override any system modules.

It should not be a big deal if there are a few more packages installed within the venv that are already there in the system package, particularly if they are of different version. Thats the whole point of virtualenv.

I tried activating my virtualenv and then pip install --upgrade -r requirements.txt and that does seem to install the dependencies, even those existing in my system path, but I can't be sure if that's because my system modules were old. And man pip doesn't seem to guarantee this behavior (i.e. installing the same version of a package that already exists in the system site-packages).

No, it doesn't install the packages already there in the main installation unless you have used the --no-site-packages flag to create it, or the required and present versions are different..

Lakshman Prasad was right, pip --upgrade and/or virtualenv --no-site-packages is the way to go. Uninstalling the system-wide python modules is bad.

The --upgrade option to pip does install required modules in the virtual env, even if they already exist in the system environment, and even if the required version or latest available version is the same as the system version.

pip --upgrade install

And, using the --no-site-packages option when creating the virtual environment ensures that missing dependencies can't possibly be masked by the presence of missing modules in the system path. This helps expose problems during migration of a module from one package to another, e.g. pinax.apps.groups -> django-groups, especially when the problem is with load templatetags statements in django which search all available modules for templatetags directories and the tag definitions within.

pip install -U xxxx 

can bypass confirm