Voir #4805 et #3389 pour l'historique. Fondamentalement, pip ne peut pas désinstaller correctement les packages installés par distutils "purs", car distutils n'enregistre pas suffisamment de métadonnées pour que nous puissions le faire. Nous avons précédemment supprimé les métadonnées d'installation, de sorte qu'il semble que nous ayons fait l'installation, mais nous avons dû laisser des fichiers derrière nous. Cela pose des problèmes. Depuis le pip 8, nous avons essayé d'arrêter de faire cela, car c'est une cause de problèmes, mais notre tentative initiale a été annulée car elle affectait trop de personnes à l'époque. Avec le pip 10, nous avons finalement arrêté d'essayer de désinstaller les packages distutils, et maintenant nous signalons le problème à l'utilisateur comme vous le voyez ici.

Fondamentalement, si vous (ou une infrastructure que vous utilisez) avez installé un paquet à l'aide de distutils, vous devez le gérer (et en particulier) le désinstaller "à l'aide de distutils". Malheureusement, distutils n'inclut pas de commande de désinstallation, donc "désinstaller à l'aide de distutils" signifie supprimer manuellement le package.

@pfmoore Merci pour la réponse rapide !

C'est plutôt gênant car la plupart des packages sont installés en tant que dépendances et nous ne les gérons pas nous-mêmes. Automatiser la suppression sera intéressant.

Je vois qu'il y a du mouvement pour mettre à niveau uniquement les packages, sans les désinstaller au préalable. Ce serait formidable si cela arrivait finalement.

On pourrait clore ce dossier puisqu'il est largement discuté ailleurs. Merci!

Essayez de supprimer manuellement le package de "site-packages". Cela fonctionne parfaitement !

Je semble contourner ce problème en fournissant la version de pip avec la commande
pip install -I==9.0.3 -r requirements.txt

J'ai utilisé les étapes suivantes et résolu ce problème

1. Version réduite :
   pip install --upgrade --force-reinstall pip==9.0.3
2. J'ai essayé de réinstaller le package :
   pip install xxx --disable-pip-version-check
3. Enfin, récupérez la dernière version de pip :
   pip install --upgrade pip

Cela semble résoudre le problème pour moi : https://github.com/blockstack/blockstack-core/issues/504

Dans le cas d'origine ci-dessus, ce serait :

pip install docker-py --ignore-installed PyYAML

Je ne sais pas qui tu es, mais je t'aime.

Alors @pfmoore, que recommanderiez-vous à une équipe qui automatise ses installations de pip ? Nous configurons notre serveur à l'aide de terraform, nous appelons donc automatiquement pip install pour smart-open et boto3, puis nous avons numpy, scipy, boto, sklearn et datadog dans un requirements.txt. Nous obtenons l'erreur distutils pour urllib3 pour plusieurs installations (car smart-open l'a installé). Les installations fonctionnent lorsque j'utilise --ignore-installed urllib3 , mais existe-t-il une manière plus appropriée de procéder ?

De plus, y a-t-il une chance que distutils ajoute une fonctionnalité de désinstallation ou plus de métadonnées ? En avez-vous parlé à cette équipe ?

@ruby-is-pretty-cool Je n'ai pas vraiment d'opinion là-dessus. Vous dites de urllib3 "parce que smart-open l'a installé" mais je ne vois rien dans smart-open qui déclare une dépendance sur urllib3, donc je ne sais pas ce que vous entendez par là. Si smart-open installe urllib3 d'une manière qui déclenche ce problème, cela ressemble à un problème smart-open.

De plus, y a-t-il une chance que distutils ajoute une fonctionnalité de désinstallation ou plus de métadonnées ? En avez-vous parlé à cette équipe ?

Pas que je sache, et non, nous ne leur en avons pas parlé. Je doute qu'ils le fassent, car distutils n'implémente pas vraiment de nouvelles fonctionnalités ces jours-ci (mais n'hésitez pas à demander si vous le souhaitez). La documentation officielle de l'empaquetage ne recommande de toute façon pas d'utiliser directement distutils, donc si des projets le font, c'est vraiment à eux de gérer les implications.

Je viens d'essayer d'installer smart-open. Cela dépend des requêtes, qui à leur tour dépendent de urllib3. Cela est installé correctement par pip lorsque je fais l'installation dans un virtualenv. Faites-vous cette installation dans un environnement système ? Dans quel cas, voyez-vous (et essayez-vous de mettre à niveau) le système installé urllib3 ? Si tel est le cas, le conseil normal "ne pas utiliser pip sur les packages système" s'applique - utilisez un virtualenv ou si vous devez installer dans votre environnement système, utilisez des packages de distribution.

Je suis assez nouveau dans l'empaquetage Python, mais j'ai le sentiment qu'un package virtualenv ou distro résoudra notre problème - je devrai les examiner davantage. Merci de votre aide!

C'est insensé. Les installations sont brisées à cause de certaines croyances religieuses. si une entrée setup.py d'un package touche urllib3, alors il n'y a aucun moyen de lui dire de l'ignorer. Dans notre cas, nous devons mettre à niveau urllib3 car dans Ubuntu 14, la version installée de pip (v1.5.x) refuse d'installer des packages à partir d'URL https.

Le fait est que personne ne mettrait à niveau les packages "système" s'ils n'arrêtaient pas de fonctionner. Dans le projet du noyau Linux, ce comportement "casse l'espace utilisateur" et Torvalds n'y réagit pas bien. C'est incroyable que les gens python le prennent si naturellement bien.

Au moins, vous devriez avertir les gens dans les messages pip avec quelque chose comme "cette version de pip refusera de fonctionner si cela signifie mettre à niveau les packages système, faites ceci et cela. Utilisez la version 9.x de pip si vous travaillez avec d'anciens installateurs ou d'anciens systèmes." ou similaire.

Ok, je ne faisais pas attention car le mien est toujours arrosé, mais mon point est plus simple.
La seule raison de la mise à niveau agressive de l'espace utilisateur était la suivante : ATT&T et berkley cherchaient toujours à savoir qui avait construit la poubelle, par exemple... et comme cela est également arrivé récemment, ils expliquent pourquoi nous faisons cette merde en premier lieu; pour l'amour du CHRIST, c'est d'avoir les choix ET de coopérer. Je ne sais toujours pas pourquoi slackeware et le chemin *bsd sont entrés dans les profondeurs, mais de toute façon, même dans deux camps, l'un conduira l'autre, je m'ennuierais du noyau, je reviens à 2.x, 16+ écrans, (Je n'ai pas encore trouvé le pilote promix dans le menu, mais je m'éloigne, et maintenant de retour dans mon emploi du temps régulier, WTF ne pouvons-nous pas obtenir un .app donc cette merde fonctionne jour. (de foutre bien sûr.)

Je suis d'accord avec @pabloa - Cela dure depuis toujours, une installation vanille de CentOS 7 ne peut pas installer docker-compose cause de cela.

Et oui, @JohnBDonner , ce petit drapeau vient de me faire gagner BEAUCOUP de temps. MERCI

Erreur initiale

"Impossible de désinstaller 'pywin32'. Il s'agit d'un projet installé par distutils et nous ne pouvons donc pas déterminer avec précision quels fichiers lui appartiennent, ce qui ne conduirait qu'à une désinstallation partielle"

Comment puis-je y arriver?

J'ai pywin32==221 installé sur ma machine, et maintenant j'essaye de désinstaller une version de mise à niveau de celui-ci (pywin==224), j'ai gagné un lien vers son ".whl" et je suis confronté à des défis pour les installer car j'ai reçu l'erreur suivante "Impossible de désinstaller 'pywin32'. Il s'agit d'un projet installé par distutils et nous ne pouvons donc pas déterminer avec précision quels fichiers lui appartiennent, ce qui ne conduirait qu'à une désinstallation partielle." . Je suis sur Windows 10 64 bits, en utilisant py3.4 32 bits.

Raison pour laquelle je fais ça ?

est parce qu'il semble que "win32.client" sur ma machine n'ait que le fichier python "optimize" ".pyo file extension". J'ai découvert cela lorsque je reçois une erreur de compilation disant que je n'ai pas de module "Dispatch" disponible pour "from win32com.client import Dispatch". Merci si quelqu'un peut m'aider à ce sujet.

ESPÈCE DE FOU??

Non, mais merci pour l'abus aléatoire. C'est tellement gratifiant de faire ça pendant mon temps libre :sourire:

Il n'était pas destiné à résoudre le problème. Il était destiné à expliquer pourquoi les choses sont comme elles sont et pourquoi pip ne peut pas résoudre le problème. Ce n'est pas parce que les gens sont tristes de la situation que ça change.

Est-il possible de changer le package d'installation utilisé par disyutils de telle sorte que
il inclut les métadonnées requises ?
Le jeu. 22 novembre 2018 à 12:56 Paul Moore [email protected]
a écrit:

Il n'était pas destiné à résoudre le problème. Il s'agissait d'expliquer pourquoi
les choses sont comme elles sont, et pourquoi pip ne peut pas résoudre le problème. Seulement
parce que les gens sont tristes de la situation n'y change rien.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441095536 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADrjCZvIpDr4X1sxcSZe3rRH7MBnn7Tsks5uxuVagaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

Je ne sais pas, je ne travaille pas sur distutils. Mais même si c'était le cas, pourquoi les gens utiliseraient-ils des distutils de nos jours de toute façon ? Ce fil concerne les packages qui ont déjà été installés à l'aide de distutils. La solution pour ceux-ci a déjà été

@AddoSolutions le changement même que vous demandez s'appelle setuptools

Donc la raison pour laquelle je suis sur ce fil est parce que je travaille souvent avec de la vanille
CentOS 7 box et installez spécifiquement docker compose dessus. CentOS
est livré avec pip et le problème est que j'obtiens ces erreurs comme décrit
dessus.

Personnellement, je ne suis pas vraiment un utilisateur de Python, j'utilise juste docker compose et
navette dessus. Personnellement, je n'ai aucune idée de la différence entre setuptools
et distutils, je suppose que le python CentOS est essentiellement installé
utiliser yum lors de l'installation?

Deux choses avec cela : le package yum peut-il être mis à jour de manière à inclure
les bonnes métadonnées ? Alternativement, après avoir obtenu cette erreur, pourrait
le message donne plus d'informations utiles sur ce qu'il faut faire ? Comme au lieu du
message relativement cryptique sur distutils (encore une fois pour les personnes comme moi utilisant
pip je ne sais même pas ce que c'est) pourrait-il dire quelque chose comme "le chemin
que pip a été installé n'est pas recommandé. Nous vous recommandons de désinstaller par
faire x puis réinstaller à l'aide de x". j'ai l'impression que ce serait
réduire considérablement le nombre de personnes ayant des problèmes avec cela.

Les pensées?

Remarque : je réalise pleinement que je pourrais creuser la différence, et je le ferai probablement,
mais demander cela pour les futurs utilisateurs et c'est aussi une action de grâce et je veux
Turquie :)
Le jeu. 22 novembre 2018 à 13:19 Ronny Pfannschmidt [email protected]
a écrit:

@AddoSolutions https://github.com/AddoSolutions le changement même que vous demandez
car est appelé setuptools

-
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441099032 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADrjCTBfoKjBuYdceDeBM0bunByQ2bxJks5uxuq2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

par rapport aux mises à jour du package yum - c'est à peu près le travail de la distribution - et cela ne l'a pas fait, mais les packages eux-mêmes non plus dans certains cas

en ce qui concerne les distributions d'entreprise - les choses sont si douloureusement obsolètes - réglez-les avec votre fournisseur - les amonts open source n'ont aucun pouvoir sur cela et ne devraient jamais avoir à supporter le fardeau de l'assistance pour votre choix dans les distributions d'entreprise - alors allez voir votre fournisseur

Je t'ai eu. Donc, le paquet pip dans ce cas serait maintenu par le CentOS
groupe, PAS par le groupe pip ?
Le jeu. 22 novembre 2018 à 17:38 Ronny Pfannschmidt [email protected]
a écrit:

wrt les mises à jour du paquet yum - c'est à peu près le travail du
distribution - et il ne l'a pas fait, mais les packages non plus
eux-mêmes dans certains cas

quand il s'agit de distributions d'entreprise - les choses sont si douloureusement obsolètes -
régler le problème avec votre fournisseur - les amonts open source n'ont aucun pouvoir sur
cela et ne devrait jamais avoir à supporter le fardeau de soutien pour votre choix dans
distributions d'entreprise - alors allez chez votre fournisseur

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pip/issues/5247#issuecomment-441129627 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADrjCZAQ-ZBmpkm7izyKkE0WymSoT6M1ks5uxyd2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

@AddoSolutions le problème n'est pas pip, mais d'autres packages - pip a simplement arrêté les prétentions et abandonné le support pour de très mauvaises choses, et maintenant les choses s'effondrent sur de mauvais acteurs comme les distributions d'entreprise - vous devez donc trier le package en termes d'entreprise distributions et avec votre fournisseur

juste un FYI - on vous demandera probablement d'utiliser le pip du système (géré par le fournisseur) et non une dernière version aléatoire

Je recevais cette erreur pour wxPython

Impossible de désinstaller 'wxPython'. Il s'agit d'un projet installé par distutils et nous ne pouvons donc pas déterminer avec précision quels fichiers lui appartiennent, ce qui ne conduirait qu'à une désinstallation partielle.

Il n'était pas situé dans sitepackages mais plutôt dans distpackages (ce qui est logique), mais cela n'a pas semblé correct de supprimer le fichier du dossier.

Il s'avère que je l'avais installé via apt , donc en faisant apt remove --autoremove python-wxgtk3.0 j'ai supprimé le package de mon système.

Ce "pas notre problème, quelqu'un d'autre le résout" est à prévoir de la part de pip. Le logiciel ne prétend même pas gérer les conflits de paquets. J'ai reçu ce message dans le cadre d'un déploiement ansible de conteneurs sur de nombreux systèmes.

Merci pour ceux d'entre vous qui ont fourni des solutions de contournement. J'ai modifié la commande - "pip install docker" avant "pip install --upgrade pip" - fonctionnait cette fois. Espérons que cela ne causera pas de problèmes (tels que la corruption de données) à l'avenir.

Ma lecture de ceci est que nous devrions utiliser des environnements virtuels pour nous protéger de la bizarrerie dans nos environnements... cependant, j'ai pu surmonter cela pour l'instant en ajoutant le drapeau --user :

pip3 install -r requirements.txt --user

https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption -user

Vous pouvez également essayer de travailler avec la version exacte de la dépendance transitoire qui a été installée par votre environnement / distutils car elle pourrait être compatible. Dans mon exemple, Pipenv résoudra la dépendance transitoire PyYAML de awscli==1.15.85 et apache-airflow==1.10.1 à 3.13, mais le système a déjà 3.11 installé. En regardant les dépendances déclarées sur ma machine de développement local, 3.11 conviendrait aux deux :

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.13]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.13]

Un simple pipenv install PyYAML==3.11 épinglera PyYAML à 3.11 et rendra les deux packages heureux :

$ pipenv install PyYAML==3.11
Installing PyYAML==3.11…
...
Locking [packages] dependencies…
✔ Success!

$ pipenv graph | egrep 'airflow|awscli|PyYAML'
apache-airflow==1.10.1
    - PyYAML [required: >=3.0, installed: 3.11]
awscli==1.15.85
  - PyYAML [required: >=3.10,<=3.13, installed: 3.11]

Mon Pipfile / Pipfile.lock s'installe ensuite proprement sur Ubuntu 14.04LTS en utilisant pipenv install --deploy --system .

J'ai également vérifié et PyYAML==3.11 est installé via python3-yaml 3.11-3build1 et il s'agit d'une dépendance directe de cloud-init 18.4-0ubuntu1~16.04.2, que nous utilisons largement lorsque nous exécutons sur EC2. 18.04 LTS et 18.10 sont livrés avec PyYAML 3.12, seul 19.04 sera livré avec PyYAML , qui se trouve être la dernière version à ce jour.

Cela étant dit, évitez à tout prix les dépendances du système et les problèmes environnementaux. Utilisez pipenv et/ou virtualenv .

J'ai utilisé les étapes suivantes et résolu ce problème:

1. Version réduite,
   pip install --upgrade --force-reinstall pip==9.0.3
2. J'ai essayé de réinstaller le paquet
   pip install xxx --disable-pip-version-check
3. Enfin, récupérez la dernière version pour pip
   pip install --upgrade pip

Cela a bien fonctionné pour moi. Mais la mise à niveau de pip après cela pose-t-elle des problèmes aux packages installés ?

@s-eswar Jusqu'à présent, nous n'avons pas trouvé de problèmes concernant le package, mais peut-être une situation dans laquelle si vous utilisez la version élevée du package d'installation pip, utilisez la réinstallation ou la vérification de la version inférieure peut survenir un problème de dépendance. Je suggère que toujours utiliser la version inférieure. Par exemple, pépin 9.0.3.

@s-eswar Jusqu'à présent, nous n'avons pas trouvé de problème pour les packages, mais peut-être une situation dans laquelle si vous utilisez la version élevée du package d'installation pip et utilisez la version inférieure, réinstallez ou vérifiez peut-être un problème de dépendance. Je suggère que toujours utiliser la version inférieure. Par exemple, pépin 9.0.3.

@wangxf1987 mais pour l'utilisation de bibliothèques ML avec la même configuration, n'obtenons-nous pas d'erreurs concernant la mise à niveau/l'utilisation d'une version inférieure.

@s-eswar Je ne suis pas sûr que les bibliothèques ML fonctionnent sous une version inférieure. J'utilise pip=9.0.3 avec la dernière version de Kubernetes. Il convient de vérifier le fichier d'exigences si vous avez besoin de la dernière version du pip ou de tester dans le dev env.

Depuis le pip 8, nous avons essayé d'arrêter de faire cela, car c'est une cause de problèmes, mais notre tentative initiale a été annulée car elle affectait trop de personnes à l'époque. Avec le pip 10, nous avons finalement arrêté d'essayer de désinstaller les packages distutils, et maintenant nous signalons le problème à l'utilisateur comme vous le voyez ici.

Je crois que la partie « nous signalons maintenant le problème à l'utilisateur » s'appelle « pousser votre dette technologique sur quelqu'un d'autre ». Je tiens à remercier tout le monde de m'avoir amené dans le fiasco. Surtout que je ne suis pas un développeur Python et que je n'ai aucune idée de comment y remédier. J'arrive à des heures de wates sur ce problème maintenant. Hourra !

Supprimer le package Dist et exécuter

sudo rm -rf /usr/lib/python3/dist-packages/yaml

sudo rm -rf /usr/lib/python3/dist-packages/PyYAML-*

La suppression du dossier de distutils fonctionne

en passant à une version plus récente, cela devrait résoudre les problèmes, mais pip introduit des problèmes, quelle ironie.

La solution est de le désinstaller manuellement, alors allez dans.../anaconda3/lib/python3.*/site-packages/ et supprimez tous les fichiers et dossiers du package

@ramonamis sudo pip install --ignore-installed PyYAML

Cela l'a mis à niveau avec succès pour moi.

Cela a également fonctionné pour imutils:

pip install --upgrade imutils --ignore-installed imutils

J'ai utilisé les étapes suivantes et résolu ce problème

1. Version réduite :
   pip install --upgrade --force-reinstall pip==9.0.3
2. J'ai essayé de réinstaller le package :
   pip install xxx --disable-pip-version-check
3. Enfin, récupérez la dernière version de pip :
   pip install --upgrade pip

ça marche pour moi Merci !

J'ai utilisé les étapes suivantes et résolu ce problème

1. Reduced version:
   `pip install --upgrade --force-reinstall pip==9.0.3`

2. Tried to re-install package:
   `pip install xxx --disable-pip-version-check`

3. At last, recover the latest version for pip:
   `pip install --upgrade pip`

c'est une mauvaise solution. Je ne peux rien faire maintenant.

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-pip : Depends: python-pip-whl (= 9.0.1-2.3~ubuntu1) but 9.0.1-2.3~ubuntu1.18.04.1 is to be installed
               Recommends: python3-dev (>= 3.2) but it is not going to be installed
               Recommends: python3-setuptools but it is not going to be installed
               Recommends: python3-wheel but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Success

Je verrouille ce fil maintenant. Le commentaire initial de @pfmoore couvre tout ici. Le reste de ce fil a divulgué des demandes de support ou des abus directs dirigés contre les responsables.