Siehe #4805 und #3389 für die Geschichte. Grundsätzlich kann pip Pakete, die von "reinen" Distutils installiert wurden, nicht richtig deinstallieren, da Distutils nicht genügend Metadaten aufzeichnet, um dies zu tun. Wir haben zuvor die Installationsmetadaten entfernt, sodass es aussieht, als hätten wir die Installation durchgeführt, aber wir mussten Dateien zurücklassen. Das verursacht Probleme. Seit Pip 8 haben wir versucht, damit aufzuhören, weil es Probleme verursacht, aber unser erster Versuch wurde rückgängig gemacht, weil zu dieser Zeit zu viele Leute davon betroffen waren. Mit pip 10 haben wir endlich aufgehört zu versuchen, distutils-Pakete zu deinstallieren, und melden das Problem jetzt dem Benutzer, wie Sie hier sehen.

Grundsätzlich, wenn Sie (oder eine von Ihnen verwendete Infrastruktur) ein Paket mit distutils installiert haben, müssen Sie es verwalten (und insbesondere) "mit distutils" deinstallieren. Leider enthält distutils keinen Deinstallationsbefehl, daher bedeutet "Deinstallieren mit distutils" das manuelle Entfernen des Pakets.

@pfmoore Danke für die schnelle Antwort!

Dies ist ziemlich unpraktisch, da die meisten Pakete als Abhängigkeiten installiert werden und wir es nicht selbst verwalten. Interessant wird es, die Entfernung zu automatisieren.

Ich sehe, dass es einige Bewegungen gibt, nur Pakete zu aktualisieren, ohne sie zuerst zu deinstallieren. Es wäre toll, wenn dies irgendwann passieren würde.

Wir könnten dieses Thema schließen, da es an anderer Stelle ausführlich diskutiert wird. Vielen Dank!

Versuchen Sie, das Paket manuell aus "site-packages" zu entfernen. Das funktioniert perfekt!

Ich scheine dieses Problem zu umgehen, indem ich die Version von pip mit dem Befehl bereitstelle
pip install -I==9.0.3 -r Requirements.txt

Ich habe die folgenden Schritte verwendet und dieses Problem gelöst

1. Reduzierte Version:
   pip install --upgrade --force-reinstall pip==9.0.3
2. Versucht, das Paket neu zu installieren:
   pip install xxx --disable-pip-version-check
3. Stellen Sie endlich die neueste Version für pip wieder her:
   pip install --upgrade pip

Dies scheint das Problem für mich zu beheben: https://github.com/blockstack/blockstack-core/issues/504

Im obigen Originalfall wäre das:

pip install docker-py --ignore-installed PyYAML

Weiß nicht wer du bist, aber ich liebe dich.

Also @pfmoore, was würden Sie einem Team empfehlen, das seine Pip-Installationen automatisiert? Wir richten unseren Server mit terraform ein, rufen also automatisch pip install für smart-open und boto3 auf und haben dann numpy, scipy, boto, sklearn und datadog in einer Requirements.txt. Wir erhalten den distutils-Fehler für urllib3 für mehrere Installationen (weil Smart-Open es installiert hat). Die Installationen funktionieren, wenn ich --ignore-installed urllib3 , aber gibt es einen besseren Weg, dies zu tun?

Besteht außerdem die Möglichkeit, dass distutils eine Deinstallationsfunktion oder weitere Metadaten hinzufügt? Habt ihr mit diesem Team darüber gesprochen?

@ruby-is-pretty-cool Ich habe keine wirkliche Meinung dazu. Sie sagen von urllib3, "weil Smart-Open es installiert hat", aber ich sehe in Smart-Open nichts, das eine Abhängigkeit von urllib3 deklariert, also weiß ich nicht, was Sie damit meinen. Wenn Smart-Open urllib3 auf eine Weise installiert, die dieses Problem auslöst, klingt das nach einem Smart-Open-Problem.

Besteht außerdem die Möglichkeit, dass distutils eine Deinstallationsfunktion oder weitere Metadaten hinzufügt? Habt ihr mit diesem Team darüber gesprochen?

Nicht, dass ich wüsste, und nein, wir haben nicht mit ihnen darüber gesprochen. Ich bezweifle, dass sie es tun würden, da distutils heutzutage keine wirklich neuen Funktionen implementiert (aber fragen Sie gerne, wenn Sie möchten). Die offizielle Paketdokumentation empfiehlt ohnehin nicht, distutils direkt zu verwenden. Wenn Projekte dies tun, liegt es wirklich an ihnen, die Auswirkungen zu verwalten.

Ich habe gerade versucht, Smart-Open zu installieren. Es hängt von Anfragen ab, die wiederum von urllib3 abhängen. Das wird von pip richtig installiert, wenn ich die Installation in einer virtuellen Umgebung mache. Führen Sie diese Installation in einer Systemumgebung durch? In welchem ​​Fall sehen Sie (und versuchen, ein Upgrade durchzuführen) das auf dem System installierte urllib3? Wenn dies der Fall ist, gilt der normale Rat "Verwenden Sie kein Pip auf Systempaketen" - verwenden Sie eine virtuelle Umgebung oder verwenden Sie Distributionspakete, wenn Sie eine Installation in Ihrer Systemumgebung durchführen müssen.

Ich bin ziemlich neu in der Python-Verpackung, aber ich habe das Gefühl, dass entweder ein Virtualenv- oder Distributionspaket unser Problem beheben wird - ich muss sie mir genauer ansehen. Danke für deine Hilfe!

Das ist verrückt. Installationen werden wegen irgendeines religionsähnlichen Glaubens kaputt gemacht. Wenn ein setup.py-Eintrag eines Pakets urllib3 berührt, gibt es keine Möglichkeit, es zu ignorieren. In unserem Fall müssen wir urllib3 aktualisieren, da in Ubuntu 14 die installierte Version von pip (v1.5.x) sich weigert, Pakete von https-URLs zu installieren.

Der Punkt ist, dass niemand "System"-Pakete aktualisieren würde, wenn sie nicht aufhören würden zu arbeiten. In einem Linux-Kernelprojekt "bricht dieses Verhalten den Userspace" und Torvalds reagiert nicht gut darauf. Es ist unglaublich, dass Python-Leute es so natürlich nehmen.

Zumindest sollten Sie die Leute in pip-Nachrichten warnen mit etwas wie "diese Version von pip wird nicht funktionieren, wenn es bedeutet, Systempakete zu aktualisieren, tun Sie dies und tun Sie das. Verwenden Sie pip-Version 9.x, wenn Sie mit alten Installern oder alten" arbeiten Systeme." oder ähnliches.

Ok, ich habe nicht aufgepasst, da meiner immer noch abgespritzt ist, aber mein Punkt ist einfacher.
Der ganze Grund für das aggressive Upgrade des Userlands war: ATT&T und Berkley waren immer noch daran interessiert, wer den Mülleimer gebaut hat, persay... Und wenn Sie die Scheiße bekommen, um auf aha1542 zu installieren, könnten Sie einen Joilet wegwerfen, der aufgrund der Lizenzierung dosiert wurde; und da dies auch vor kurzem zur Sprache kam, begründen sie, warum wir diesen Scheiß überhaupt machen; um CHRISTUS willen, die Wahl zu haben UND zu kooperieren. Ich bin immer noch irgendwie verblüfft, warum Slackeware und der *bsd-Pfad ins Deepend gegangen sind, aber trotzdem, auch in zwei Lagern, 1 wird das andere fahren, ich würde mich vom Kernel langweilen, gehe zurück zu 2.x, 16+ Bildschirme, (Ich muss den Promix-Treiber noch im Menü wiederfinden, aber ich schweife ab und jetzt zurück in meinem regulären Zeitplan, WTF können wir keine .app bekommen, damit diese Scheiße funktioniert.

Ich stimme @pabloa zu - Das geht jetzt schon ewig so, eine Vanilla-Installation von CentOS 7 kann docker-compose deswegen nicht installieren.

Und ja, @JohnBDonner , diese kleine Flagge hat mir gerade viel Zeit gespart. DANKE SCHÖN

Anfangsfehler

"'pywin32' kann nicht deinstalliert werden. Es ist ein von Distutils installiertes Projekt und daher können wir nicht genau bestimmen, welche Dateien dazu gehören, was zu einer nur teilweisen Deinstallation führen würde."

Wie komme ich dort hin?

Ich habe pywin32==221 auf meinem Computer installiert und versuche jetzt, eine Upgrade-Version davon zu deinstallieren (pywin==224), ich habe einen Link zu seiner ".whl" und stehe vor Herausforderungen, sie zu installieren da ich die folgende Fehlermeldung erhalten habe: "Pywin32 kann nicht deinstalliert werden. Es ist ein von Distutils installiertes Projekt und daher können wir nicht genau feststellen, welche Dateien dazu gehören, was zu einer nur teilweisen Deinstallation führen würde"." . Ich verwende Windows 10 64bit und verwende py3.4 32bit.

Grund, warum ich das tue?

liegt daran, dass "win32.client" auf meinem Computer nur die Python-Datei "Optimieren" ".pyo-Dateierweiterung" hat. Ich habe dies herausgefunden, als ich einen Kompilierungsfehler erhalte, der besagt, dass ich kein "Dispatch" -Modul für "from win32com.client import Dispatch" verfügbar habe. Wäre dankbar, wenn mir jemand dabei helfen könnte.

BIST DU SAUER, BRUDER??

Nein, aber danke für den zufälligen Missbrauch. Das macht es in meiner Freizeit so lohnend :smile:

Es war nicht beabsichtigt, das Problem zu lösen. Es sollte erklären, warum die Dinge so sind, wie sie sind und warum pip das Problem nicht lösen kann. Nur weil die Leute traurig über die Situation sind, ändert das nichts.

Ist es möglich, das von disyutils verwendete Installationspaket so zu ändern, dass
es die erforderlichen Metadaten enthält?
Am Do, 22. November 2018 um 12:56 Uhr Paul Moore [email protected]
schrieb:

Es war nicht beabsichtigt, das Problem zu lösen. Es sollte erklären warum
die dinge sind wie sie sind und warum pip das problem nicht lösen kann. Gerade
weil die Leute traurig über die Situation sind, ändert das nichts.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/5247#issuecomment-441095536 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADrjCZvIpDr4X1sxcSZe3rRH7MBnn7Tsks5uxuVagaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

Ich weiß nicht, ich arbeite nicht an Distutils. Aber selbst wenn es so wäre, warum würden die Leute heutzutage überhaupt Distutils verwenden? In diesem Thread geht es um Pakete, die bereits mit distutils installiert wurden. Die Lösung für diese wurde bereits früher in diesem Thread erwähnt .

@AddoSolutions genau die Änderung, die Sie verlangen, heißt setuptools

Der Grund, warum ich in diesem Thread bin, ist, dass ich oft mit Vanille arbeite
CentOS 7-Boxen und installieren Sie speziell Docker Compose darauf. CentOS
kommt auf Lager mit Pip und das Problem ist, dass ich diese Fehler wie beschrieben bekomme
Oben.

Ich persönlich bin kein großer Python-Benutzer, ich benutze nur Docker Compose und
shuttle drauf. Ich persönlich habe keine Ahnung vom Unterschied zwischen Setuptools
und distutils, ich vermute, dass die CentOS-Python grundsätzlich installiert ist
Yum bei der Installation verwenden?

Zwei Dinge damit: Kann das Yum-Paket so aktualisiert werden, dass es enthält?
die richtigen Metadaten? Alternativ könnte, wenn dieser Fehler auftritt,
Gibt die Nachricht weitere hilfreiche Informationen darüber, was zu tun ist? Like statt der
relativ kryptische Nachricht über Distutils (wieder für Leute wie mich, die verwenden
pip, ich weiß nicht einmal, was das ist) könnte es so etwas sagen wie "der Weg"
dass pip installiert wurde, wird nicht empfohlen. Wir empfehlen die Deinstallation von
x ausführen und dann mit x neu installieren“. Ich habe das Gefühl, das würde
die Zahl der Menschen mit Problemen damit deutlich reduzieren.

Die Gedanken?

Hinweis: Mir ist klar, dass ich den Unterschied untersuchen könnte und wahrscheinlich werde,
Aber ich frage dies für zukünftige Benutzer und es ist auch Danksagung und ich möchte
Truthahn :)
Am Do, 22. November 2018 um 13:19 Uhr Ronny Pfannschmidt [email protected]
schrieb:

@AddoSolutions https://github.com/AddoSolutions genau die Änderung, die Sie verlangen
für heißt setuptools

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/5247#issuecomment-441099032 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADrjCTBfoKjBuYdceDeBM0bunByQ2bxJks5uxuq2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

bezüglich der Updates des yum-Pakets - das ist so ziemlich die Aufgabe der Distribution - und sie hat es nicht getan, aber in einigen Fällen auch nicht die Pakete selbst

Wenn es um Enterprise-Distributionen geht - die Dinge sind so schmerzlich veraltet - klären Sie es mit Ihrem Anbieter - Open-Source-Upstreams haben keine Macht darüber und sollten niemals die Supportlast für Ihre Wahl in Enterprise-Distributionen tragen müssen - also gehen Sie zu Ihrem Anbieter

Erwischt. Das Pip-Paket würde in diesem Fall also vom CentOS verwaltet
Gruppe, NICHT von der Pip-Gruppe?
Am Do, 22. November 2018 um 17:38 Uhr Ronny Pfannschmidt [email protected]
schrieb:

bezüglich der Updates des Yum-Pakets - das ist so ziemlich die Aufgabe der
Distribution - und es hat es nicht getan, aber die Pakete auch nicht
sich in einigen Fällen

wenn es um Enterprise-Distributionen geht - die Dinge sind so schmerzlich veraltet -
Klären Sie es mit Ihrem Anbieter ab - Open-Source-Upstreams haben keine Macht darüber
das und sollten niemals die Unterstützungslast für Ihre Wahl tragen müssen in
Unternehmensdistributionen - gehen Sie also zu Ihrem Anbieter

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/5247#issuecomment-441129627 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADrjCZAQ-ZBmpkm7izyKkE0WymSoT6M1ks5uxyd2gaJpZM4TWMU4
.

>

Nick Artman
+1 (330) 558-1230

@AddoSolutions das Problem dort ist nicht pip, sondern andere Pakete - pip hat einfach aufgehört, sich zu verstellen und die Unterstützung für wirklich schlechte Dinge eingestellt, und jetzt fällt das Zeug auf schlechte Akteure wie Enterprise-Distributionen auseinander - also müssen Sie das Paket in Bezug auf das Unternehmen sortieren Distributionen und bei Ihrem Anbieter

nur ein FYI - Ihnen wird wahrscheinlich gesagt, dass Sie pip vom System verwenden sollen (vom Anbieter verwaltet) und nicht eine zufällige neueste Version

Ich habe diesen Fehler für wxPython

'wxPython' kann nicht deinstalliert werden. Es ist ein von Distutils installiertes Projekt und daher können wir nicht genau bestimmen, welche Dateien dazu gehören, was zu einer nur teilweisen Deinstallation führen würde.

Es befand sich nicht in sitepackages sondern eher in distpackages (was Sinn macht), aber es fühlte sich nicht richtig an, die Datei aus dem Ordner zu löschen.

Es stellte sich heraus, dass ich es über apt installiert hatte, wodurch apt remove --autoremove python-wxgtk3.0 das Paket von meinem System entfernte.

Dieses "nicht unser Problem, jemand anderes löst es" ist von pip zu erwarten. Die Software gibt nicht einmal vor, Paketkonflikte zu verwalten. Ich habe diese Nachricht als Teil einer ansiblen Bereitstellung von Containern auf vielen Systemen erhalten.

Vielen Dank für diejenigen von Ihnen, die Problemumgehungen bereitgestellt haben. Ich habe die Reihenfolge geändert - "pip install docker" vor "pip install --upgrade pip" - hat diesmal funktioniert. Hoffentlich wird dies in Zukunft keine Probleme (wie Datenbeschädigung) verursachen.

Ich lese dies so, dass wir virtuelle Umgebungen verwenden sollten, um uns vor Seltsamkeiten in unseren Umgebungen zu schützen ... aber ich konnte dies vorerst überwinden, indem ich das --user Flag hinzufügte:

pip3 install -r requirements.txt --user

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

Sie können auch versuchen, mit der genauen Version der vorübergehenden Abhängigkeit zu arbeiten, die von Ihrer Umgebung / distutils installiert wurde, da diese kompatibel sein könnte. In meinem Beispiel löst Pipenv die vorübergehende Abhängigkeit von PyYAML von awscli==1.15.85 und apache-airflow==1.10.1 auf 3.13 auf, aber das System hat bereits 3.11 installiert. Wenn man sich die deklarierten Abhängigkeiten auf meinem lokalen Entwicklungscomputer ansieht, wäre 3.11 für beide in Ordnung:

$ 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]

Ein einfaches pipenv install PyYAML==3.11 pinnt PyYAML auf 3.11 und macht beide Pakete glücklich:

$ 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]

My Pipfile / Pipfile.lock installiert sich anschließend sauber unter Ubuntu 14.04LTS mit pipenv install --deploy --system .

Ich habe auch überprüft und PyYAML==3.11 wird über python3-yaml 3.11-3build1 installiert und ist eine direkte Abhängigkeit von cloud-init 18.4-0ubuntu1~16.04.2, die wir ausgiebig verwenden, wenn wir auf EC2 laufen. Sowohl 18.04 LTS als auch 18.10 kommen mit PyYAML 3.12, nur 19.04 wird mit PyYAML kommen , was zufällig die aktuellste Version ist.

Vermeiden Sie jedoch unbedingt Systemabhängigkeiten und Umweltprobleme. Verwenden Sie pipenv und/oder virtualenv .

Ich habe folgende Schritte verwendet und dieses Problem gelöst:

1. Reduzierte Version,
   pip install --upgrade --force-reinstall pip==9.0.3
2. Versucht, das Paket neu zu installieren
   pip install xxx --disable-pip-version-check
3. Stellen Sie endlich die neueste Version für pip wieder her
   pip install --upgrade pip

Das hat bei mir gut funktioniert. Aber gibt es nach dem Upgrade von pip Probleme mit den installierten Paketen??

@s-eswar Bisher haben wir keine Probleme mit dem Paket gefunden, aber möglicherweise kann eine Situation auftreten, in der bei Verwendung der höheren Version des Pip-Installationspakets die niedrigere Version erneut installiert oder überprüft wird, kann ein Abhängigkeitsproblem auftreten. Ich schlage vor, dass Sie immer eine niedrigere Version verwenden. Zum Beispiel pip 9.0.3.

@s-eswar Bisher haben wir kein Problem mit Paketen gefunden, aber vielleicht kann es zu Abhängigkeitsproblemen kommen, wenn die hohe Version des Pip-Installationspakets verwendet und die niedrigere Version erneut installiert oder überprüft wird. Ich schlage vor, dass Sie immer eine niedrigere Version verwenden. Zum Beispiel pip 9.0.3.

@wangxf1987, aber bei der Verwendung von ML-Bibliotheken mit derselben Konfiguration erhalten wir keine Fehler bezüglich der Aktualisierung / Verwendung einer niedrigeren Version.

@s-eswar Ich bin mir nicht sicher, ob ML-Bibliotheken unter einer niedrigeren Version funktionieren. Wenn ich pip=9.0.3 verwende, funktioniert das mit der neuesten Version des Kubernetes. Es sollte in der Anforderungsdatei überprüft werden, ob Sie die neueste Version des Pip benötigen oder in der Entwicklungsumgebung testen.

Seit Pip 8 haben wir versucht, damit aufzuhören, weil es Probleme verursacht, aber unser erster Versuch wurde rückgängig gemacht, weil zu dieser Zeit zu viele Leute davon betroffen waren. Mit pip 10 haben wir endlich aufgehört zu versuchen, distutils-Pakete zu deinstallieren, und melden das Problem jetzt dem Benutzer, wie Sie hier sehen.

Ich glaube, der Teil "jetzt melden wir das Problem dem Benutzer" heißt "Ihre technologischen Schulden auf jemand anderen abwälzen". Ich möchte allen danken, die mich in das Fiasko gebracht haben. Zumal ich kein Python-Entwickler bin und keine Ahnung habe, wie ich das beheben kann. Ich komme jetzt stundenlang mit diesem Problem zurecht. Hurra!

Dist-Paket entfernen und ausführen

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

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

Das Entfernen des Ordners aus distutils funktioniert

Durch ein Upgrade auf eine neuere Version sollte es die Probleme lösen, aber Pip führt zu Problemen, was für eine Ironie.

Die Lösung besteht darin, es manuell zu deinstallieren, also gehen Sie zu .../anaconda3/lib/python3.*/site-packages/ und löschen Sie alle Dateien und Ordner des Pakets

@ramonamis sudo pip install --ignore-installed PyYAML

Dies hat es erfolgreich für mich aktualisiert.

Dies funktionierte auch für Imutils:

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

Ich habe die folgenden Schritte verwendet und dieses Problem gelöst

1. Reduzierte Version:
   pip install --upgrade --force-reinstall pip==9.0.3
2. Versucht, das Paket neu zu installieren:
   pip install xxx --disable-pip-version-check
3. Stellen Sie endlich die neueste Version für pip wieder her:
   pip install --upgrade pip

bei mir funktioniert es， Danke!

Ich habe die folgenden Schritte verwendet und dieses Problem gelöst

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`

das ist eine schlechte lösung. Ich kann jetzt nichts tun.

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

Ich schließe diesen Thread jetzt. Der erste Kommentar von