Contourner l'invite de confirmation pour la désinstallation du pip
J'essaie de désinstaller tous les packages Django de mon environnement superutilisateur pour m'assurer que toutes les dépendances de mes applications Web sont installées sur virtualenv.
Sudo su
Sudo pip freeze | grep -E '^Django-' | xargs pip -q uninstall
Mais pip veut confirmer chaque désinstallation de paquet, et il ne semble pas y avoir d’option -y pour pip. Existe-t-il un meilleur moyen de désinstaller un lot de modules python? Est-ce que rm -rf .../site-packages/ est une bonne façon de faire? Existe-t-il une alternative à easy_install?
Sinon, serait-il préférable de forcer pip à installer toutes les dépendances sur virtualenv plutôt que de compter sur les modules python du système pour répondre à ces dépendances, par exemple. pip --upgrade install, mais oblige même les versions également anciennes à être installées à remplacer tous les modules système. J'ai essayé d'activer virtualenv, puis pip install --upgrade -r requirements.txt et cela semble installer les dépendances, même celles existant dans mon chemin système, mais je ne peux pas être sûr que ce soit parce que mes modules système étaient anciens. Et man pip ne semble pas garantir ce comportement (c'est-à-dire installer la version identique d'un package existant dans les packages de site système).
à partir de la version pip 7.1.2, vous pouvez exécuter pip uninstall -y <python package>
Pip n'inclut PAS l'option --yes (à partir de pip version 1.3.1).
Contournement: pipe oui à elle!
$ Sudo ls # enter pw so not prompted again
$ /usr/bin/yes | Sudo pip uninstall pymongo
Si vous voulez désinstaller tous les paquets de requirements.txt,
pip uninstall -y -r requirements.txt
Lakshman Prasad avait raison, pip --upgrade et/ou virtualenv --no-site-packages est la voie à suivre. La désinstallation des modules python à l’échelle du système est une mauvaise chose.
L'option --upgrade de pip installe les modules requis dans l'environnement virtuel, même s'ils existent déjà dans l'environnement système, et même si la version requise ou la dernière version disponible est identique à la version du système.
pip --upgrade install
De plus, l'utilisation de l'option --no-site-packages lors de la création de l'environnement virtuel garantit que les dépendances manquantes ne peuvent éventuellement pas être masquées par la présence de modules manquants dans le chemin système. Cela permet d’exposer des problèmes lors de la migration d’un module d’un package à un autre, par exemple. pinax.apps.groups -> Django-groups, en particulier lorsque le problème concerne les instructions load templatetags dans Django qui recherchent dans tous les modules disponibles les répertoires templatetags et les définitions de balises qu’ils contiennent.
Sinon, serait-il préférable de forcer pip à installer toutes les dépendances sur virtualenv plutôt que de compter sur les modules python du système pour répondre à ces dépendances,
Oui. Ne jouez pas trop avec les paquets installés dans le système intégré. Beaucoup de paquets système, en particulier sous OS X (même les versions debian et dérivée) en dépendent trop.
pip --upgrade installe, mais oblige, même les versions les plus anciennes, à remplacer tous les modules du système.
Cela ne devrait pas être un gros problème si quelques paquets supplémentaires sont déjà installés dans le paquet venv qui sont déjà présents dans le paquet système, en particulier s'ils ont une version différente. C’est l’intérêt de virtualenv.
J'ai essayé d'activer virtualenv, puis d'installer pip --upgrade -r Requirements.txt, ce qui semble installer les dépendances, même celles existant dans mon chemin système, mais je ne peux pas être sûr que ce soit parce que mes modules système étaient anciens. Et man pip ne semble pas garantir ce comportement (c’est-à-dire installer la même version d’un paquet qui existe déjà dans les paquets-site du système).
Non, les packages déjà présents dans l'installation principale ne sont pas installés à moins que vous n'ayez utilisé l'indicateur --no-site-packages pour le créer, ou que les versions requises et actuelles soient différentes.
pip install -U xxxx
peut contourner confirmer