Bestätigungsaufforderung für Pip-Deinstallation umgehen

Ich versuche, alle Django-Pakete in meiner Superuser-Umgebung zu deinstallieren, um sicherzustellen, dass alle meine Webanwendungsabhängigkeiten auf meiner virtuellen Umgebung installiert sind.

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

Pip möchte jedoch bestätigen, dass jedes Paket deinstalliert wird, und es scheint keine -yOption für pip zu geben. Gibt es eine bessere Möglichkeit, einen Stapel von Python-Modulen zu deinstallieren? Ist rm -rf .../site-packages/ein richtiger Weg zu gehen? Gibt es eine easy_install-Alternative?

Alternativ wäre es besser, pip zu zwingen, alle Abhängigkeiten auf der virtuellen Umgebung zu installieren, als sich auf die System-Python-Module zu verlassen, um diese Abhängigkeiten zu erfüllen, z. B. pip --upgrade installselbst gleich alte Versionen zu installieren, um alle Systemmodule zu überschreiben. Ich habe versucht, meine virtuelle Umgebung zu aktivieren, pip install --upgrade -r requirements.txtund das scheint die Abhängigkeiten zu installieren, auch die in meinem Systempfad vorhandenen, aber ich kann nicht sicher sein, ob dies daran liegt, dass meine Systemmodule alt waren. Und man pipscheint dieses Verhalten nicht zu garantieren (dh die gleiche Version eines Pakets zu installieren, die bereits in den System-Site-Paketen vorhanden ist).

Ab Pip Version 7.1.2 können Sie ausführen pip uninstall -y <python package(s)>

pip uninstall -y package1 package2 package3

oder aus Datei

pip uninstall -y -r requirements.txt

Pip enthält KEINE Option --yes (ab Pip Version 1.3.1).

Umgehung: Pipe ja dazu!

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

Wenn Sie jedes Paket von deinstallieren möchten requirements.txt,

pip uninstall -y -r requirements.txt

Alternativ wäre es besser, pip zu zwingen, alle Abhängigkeiten auf der virtuellen Umgebung zu installieren, als sich auf die System-Python-Module zu verlassen, um diese Abhängigkeiten zu erfüllen.

Ja. Verwirren Sie sich nicht zu sehr mit den im eingebauten System installierten Paketen. Viele der Systempakete, insbesondere in OS X (sogar die Debian- und die abgeleiteten Sorten), hängen zu stark von ihnen ab.

pip --upgrade install, zwingt aber auch gleich alte Versionen zur Installation, um alle Systemmodule zu überschreiben.

Es sollte keine große Sache sein, wenn einige weitere Pakete im venv installiert sind, die bereits im Systempaket enthalten sind, insbesondere wenn sie eine andere Version haben. Das ist der springende Punkt bei virtualenv.

Ich habe versucht, meine virtuelle Umgebung zu aktivieren und dann --upgrade -r require.txt zu installieren, und das scheint die Abhängigkeiten zu installieren, auch die in meinem Systempfad vorhandenen, aber ich kann nicht sicher sein, ob dies daran liegt, dass meine Systemmodule alt waren. Und man pip scheint dieses Verhalten nicht zu garantieren (dh die gleiche Version eines Pakets zu installieren, die bereits in den System-Site-Paketen vorhanden ist).

Nein, die bereits in der Hauptinstallation vorhandenen Pakete werden nur installiert, wenn Sie das --no-site-packagesFlag zum Erstellen verwendet haben oder die erforderlichen und aktuellen Versionen unterschiedlich sind.

Lakshman Prasad hatte Recht pip --upgradeund / oder virtualenv --no-site-packagesist der richtige Weg. Die Deinstallation der systemweiten Python-Module ist fehlerhaft.

Die --upgradeOption zum Pip installiert die erforderlichen Module in der virtuellen Umgebung, selbst wenn sie bereits in der Systemumgebung vorhanden sind und selbst wenn die erforderliche Version oder die letzte verfügbare Version mit der Systemversion identisch ist.

pip --upgrade install

Durch die Verwendung der Option --no-site-packages beim Erstellen der virtuellen Umgebung wird sichergestellt, dass fehlende Abhängigkeiten möglicherweise nicht durch das Vorhandensein fehlender Module im Systempfad maskiert werden können. Dies hilft dabei, Probleme während der Migration eines Moduls von einem Paket in ein anderes aufzudecken, z. B. pinax.apps.groups -> django-groups, insbesondere wenn das Problem darin besteht, templatetags-Anweisungen in django zu laden, die alle verfügbaren Module nach templatetags-Verzeichnissen und den Tag-Definitionen durchsuchen innerhalb.

pip install -U xxxx 

kann bestätigen umgehen