das ist ein debian-Problem

noch ein Hinweis - das Ersetzen des System-Pip durch Pip ist immer ein Akt des System-Vandalismus, bei dem derjenige, der ihn verursacht, für den Fallout verantwortlich ist

Ich würde vorschlagen, dass Sie auf eine geeignete paketierte Kopie von pip 10 von Debian warten sollten - wie @RonnyPfannschmidt sagt, sollten Sie pip nicht verwenden, um Ihre Systempakete zu aktualisieren ...

Sieht so aus, als ob das Debian-pip3-Skript die Interna von pip verwendet, also liegt es definitiv an ihnen, einen pip10-kompatiblen Fix zu bekommen (und ich würde voll und ganz erwarten, dass sie mit der Veröffentlichung ihres pip10-Pakets warten, bis sie das sortiert haben).

noch ein Hinweis - das Ersetzen des System-Pip durch Pip ist immer ein Akt des System-Vandalismus, bei dem derjenige, der ihn verursacht, für den Fallout verantwortlich ist

Überzeugen Sie die Debian/Ubuntu-Leute, keinen Anbieter zu machen und dann die Hälfte ihrer Pakete verrotten zu lassen, und das wäre ein gültiges Argument.

Sie können virtualenv oder venv verwenden, um sich von der System-Pip-Installation zu isolieren.

Sie sollten die vom Paketmanager verwalteten Dateien nicht ändern (hier die System-Pip-Installation) -- ich denke, sie erwarten nicht, dass Benutzer Dinge ändern -- es wird wahrscheinlich von Debian nicht unterstützt. Es wird zwangsläufig zu solchen Problemen führen.

Gleiches Problem auch bei Fedora.

Vielleicht sollte es einen "Beta"-Kanal oder einen ähnlichen Mechanismus geben, damit die Leute vor der Veröffentlichung mehr Tests durchführen können, anstatt einfach eine kaputte Version auf pypi zu werfen und alle Builds explodieren zu lassen.

@fake-name Es wurden zwei Vorabversionen erstellt:

• 10.0.0b1 wurde am 31. März veröffentlicht
• 10.0.0b2 wurde am 2. April veröffentlicht

@fake-name zusätzlich ist der allgemeine Vorschlag für die Verwendung in allen Distributionen - Verwenden Sie eine virtuelle Umgebung, zerstören Sie das System nicht, und das funktioniert - die Leute folgen einfach der Schriftart und fragen sich dann, wann das Zeug kaputt geht und geben Pip die Schuld

es gab viele manuelle und automatisierte Tests mit virtualenvs, die funktionieren

auch in einem virtualenv sollte es zumindest keinen von debian erstellten pip3-Befehl geben - also was zum Teufel redest du in Bezug auf diesen Bruch in virtualenvs - bitte geben Sie genügend Daten an, um ihn tatsächlich zu überprüfen, anstatt über Brüche zu jammern, ohne die Daten bereitzustellen, die für die Überprüfung erforderlich sind

pip wird ehrenamtlich betrieben, kein Unternehmen mit Dutzenden von Mitarbeitern

~Gelöscht~. verwechselte dies mit https://github.com/pypa/pip/issues/5220

Ich bin ein Derp.

Danke, hatte nicht gemerkt, dass das Ersetzen des System-Pip eine schlechte Idee war, aber es macht Sinn. Es wäre jedoch eine gute UX, wenn pip in diesem Fall nicht über ein Upgrade nörgeln würde. Wird das möglich sein? Ich schätze, viele Leute (einschließlich mir) würden einfach tun, was "das Ding" von ihnen verlangt.

@fake-name danke fürs Nachfassen - es kommt überraschend häufig vor, dass das Detailproblem nicht übereinstimmt, wenn eine Hauptversion vielfältige Auswirkungen hat und ein Teil davon versucht, Ihnen den Tag zu ruinieren

es wäre eine gute UX, wenn pip in diesem Fall nicht über ein Upgrade nörgeln würde

Distributionsanbieter könnten sicherlich pip patchen, um diese Warnung zusammen mit den anderen Patches, die sie erstellen, zu entfernen (oder besser durch eine ähnliche Überprüfung der Systempakete zu ersetzen). Ich bin mir nicht sicher, wie base pip erkennen könnte, dass es von einer systempaketierten Installation ohne Mitwirkung der Distribution ausgeführt wird, aber wenn es eine Möglichkeit gibt, dies zu tun, könnten wir dies in Betracht ziehen (aber seien Sie sich bewusst, dass wir meiner Erfahrung nach als viel negatives Feedback, wenn wir solche Heuristiken falsch machen, wie wir es tun, wenn wir überhaupt keine Heuristiken einbeziehen...)

Ziehen Sie immer "python3 -m pip" gegenüber pip3" oder noch besser "/usr/bin/env python3 -m pip" vor, es ist sicherer und ermöglicht es, dieses Problem mit pip10 zu vermeiden

Wir haben dieses Problem durch Clear Hash in bash gelöst:

$ hash -d pip

Oder in Bindestrich (sch):

$ hash -r pip

Dieses Problem tritt auch beim Erstellen von Docker-Images auf.

@RonnyPfannschmidt sagt: "Das Ersetzen des System-Pip durch Pip ist immer ein Akt des System-Vandalismus, bei dem derjenige, der ihn zufügt, für den Fallout verantwortlich ist", der 6 Daumen hoch hat. Ich finde dies ein besonders stumpfer Kommentar, da ich dies von pip selbst angewiesen habe:

_Sie verwenden pip-Version 8.1.1, Version 10.0.0 ist jedoch verfügbar.
Sie sollten ein Upgrade über den Befehl 'pip install --upgrade pip' in Betracht ziehen._

Wenn dieser Kommentar eine gewisse Gültigkeit hat, sollten die Ersteller von pip diese Nachricht entfernen, und ich würde @RonnyPfannschmidt ermutigen, ein entsprechendes Problem Standpunkt zu vertreten.

@qacollective - Ich denke, das Argument hier ist, dass die Distributionen Pip genommen, modifiziert und in ihre Repositories neu verpackt haben. Daher ist es nicht wirklich Pypis Schuld, dass die Nachricht immer noch da ist.

Das meiste davon liegt daran, dass eine Reihe von Distributionen wirklich sehr hart versuchen, alles in ihre eigenen Paket-Repositorys umzupacken. Meistens verrotten die Dinge dann.

Ich persönlich wünschte, zumindest für Python unter Ubuntu, sie würden es beenden. Die Version von praktisch jedem Python-Paket in apt reicht von wirklich sehr alt bis versteinert. Apt ist für Python im Grunde genommen nutzlos, IMHO.

FWIW, ich neige dazu, die beste Option zu finden, den Distro-Pip gar nicht erst zu installieren, sondern ihn manuell über get-pip.py installieren. Auf diese Weise haben Sie keine Probleme damit, dass der Plattformpaket-Manager nur einige der Python-Pakete kennt.

Verwenden Sie immer --user, um zu vermeiden, dass Ihr System beendet wird

/usr/bin/env python3 -m pip intall --user --upgrade pip

Sollte die meisten Fehlerfälle behandeln und dazu führen, dass die richtige Version von pip in ˜/.local/bin installiert wird.

Ich kann bestätigen, dass die Lösung von

Ein bisschen Hintergrund: Nach dem Upgrade (pip install -U pip) auf ein Vanilla Ubuntu 16.04 (AWS AMI) kommt man zu folgender Situation:
$PATH=..:/usr/local/ bin:... :/usr/ bin:...
/usr/bin/pip ist immer noch die alte/'oem'-Version (kaputt)
/usr/local/bin/pip ist das neue v10-Skript (funktioniert gut, wenn es direkt aufgerufen wird)

Obwohl die richtige Pip-Version der defekten im PATH vorangeht, erinnert sich die Bash immer noch an die alte. Wenn Sie sie also einfach als 'pip' aufrufen, wird die alte, defekte Version ausgeführt. hash-d pip oder hash -r löst das Problem.

Zunächst einige Anmerkungen zu dem, was hier auf Debian/Ubuntu (und wahrscheinlich noch ein paar weiteren Linux-Distributionen) passiert ist:

• pip unterstützt nicht die Verwendung seiner Interna durch den Import. Mehr dazu in der Dokumentation hier .
• Debian (daher Ubuntu) unterstützt nicht das Ändern ihrer vom Paketmanager verwalteten Dateien mit etwas, das nicht ihr Paketmanager ist.

Dieses Problem wird dadurch verursacht, dass beide in gewisser Weise verletzt werden.

• Debian verwendet die internen Methoden von pip (die aufgrund einer Reorganisation der internen Methoden von pip nicht mehr funktionieren). Debian geht hier davon aus, dass die Pip-Version in ihren Repositorys diejenige ist, die installiert werden würde.
• Das Ausführen von pip install --upgrade pip als root ohne andere Parameter modifiziert Dateien, die von apt verwaltet werden sollen, was das Skript von Debian bricht.

Einige allgemeine Tipps zu Linux:

• Es ist eine gute Angewohnheit, --user außerhalb eines Venvs zu verwenden.

  pip install --upgrade --user pip
  

• Führen Sie nie pip mit sudo aus, es sei denn, Sie wissen, was Sie tun.

Was ist die Problemumgehung?

Die Lösung von @standag ist nützlich, wenn dies durch das Caching von ausführbaren Dateien durch die Bash verursacht wird.

hash -r pip # or hash -d pip

Wenn Sie die Installation von pip durch den Paketmanager Ihres Betriebssystems geändert haben (z. B. mit sudo pip ) und python -m pip noch funktioniert, können Sie die installierte Version von pip deinstallieren und die installierte Version des Paketmanagers neu installieren .

python -m pip uninstall pip  # this might need sudo
sudo apt install --reinstall python-pip

Wenn Sie nicht unter Debian/Ubuntu sind _und_ pip für Sie pleite ist, versuchen Sie Folgendes auszuführen:

python -m pip install --force-reinstall pip

Wenn die oben genannten Schritte Ihre Probleme nicht lösen, reichen Sie bitte ein neues Problem ein.

[bearbeitet von @pradyunsg : Machen Sie es relevanter, um alle mit ähnlichen Problemen mit diesem Kommentar zu verlinken; Aktualisieren Sie den Vorschlag, um die Problemumgehung durch Deinstallation/Neuinstallation einzuschließen]

Wie wäre es mit einer Lösung außerhalb von Docker? Es ist in meinem regulären System kaputt und der Hash-Befehl hat Pip nicht erkannt.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

Ich habe pip3, Version 9.0.1 in einem virtualenv aus einem Projekt installiert gefunden und in mein /usr/bin kopiert und es funktioniert wieder. Hier ist der Inhalt der ausführbaren pip3-Datei für diejenigen, die es auch selbst reparieren möchten.

# -*- coding: utf-8 -*-
import re
import sys

from pip import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

Ich bin mir sicher, dass Sie das nur in einer Datei namens pip3 speichern müssen, sie ausführbar machen, indem Sie sudo chmod +x ./pip3 ausführen, sudo apt ausführen, python3-pip entfernen und es dann in das bin-Verzeichnis kopieren, indem Sie sudo ausführen cp ./pip3 /usr/bin.
Hier ist die Rohdatei für diejenigen, die sie nur herunterladen und verschieben möchten.
pip3.zip

Für mich geht das:
curl https://bootstrap.pypa.io/get-pip.py | sudo python

Es tut mir leid, aber ich möchte darauf hinweisen, dass das Ausführen von Python-Code curl'd von einer Website mit Root-Zugriff einfach erschreckend unsicher ist.

Einverstanden, und ich sollte darauf hinweisen, dass dies keine offizielle Pip-Empfehlung ist. Wie bereits mehrfach erwähnt, sollten Sie Ihren Systempaketmanager verwenden, um Ihre System-Pip-Installation zu aktualisieren oder anderweitig zu verwalten, nicht get-pip oder sogar pip selbst über sudo.

In diesem Fall funktioniert die Version aus dem Systempaketmanager nicht. Auch
nach dem spülen und neu installieren.

Am Do, 19. April 2018, 01:53 Uhr schrieb Paul Moore [email protected] :

Einverstanden, und ich sollte darauf hinweisen, dass dies kein offizieller Pip ist
Empfehlung. Wie bereits mehrfach erwähnt, sollten Sie verwenden
Ihren Systempaketmanager, um Ihr System-Pip zu aktualisieren oder anderweitig zu verwalten
Installation, nicht get-pip oder sogar selbst per sudo pip.

—
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/5221#issuecomment-382660881 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

Wenn die Neuinstallation des Systempakets immer noch nicht funktioniert, überprüfen Sie, ob Sie pip10 irgendwo in /usr/local/ haben und löschen Sie den gesamten Ordner.

Das Ersetzen des von /usr/bin hat bei mir funktioniert, obwohl ich DENKE, dass es so ist
diejenige, die der Systempaketmanager installiert hat.

[ @pradyunsg ausgeschnittener E-Mail-Inhalt]

@ThinkDigitalRepair Hilft Folgendes?

In anderen Fällen möchten Sie --user wenn Sie Pakete installieren/aktualisieren. TBH, unter Linux ist es eine gute Angewohnheit, --user .

pip install --upgrade --user pip

In Ordnung. Danke. Ich habe es nach einem Jupyter Notebook-Tutorial von ihrem vermasselt
Site, die Sie auffordert, Pip direkt zu aktualisieren. Kopieren und Einfügen ohne
das Wissen um die Konsequenzen schlägt wieder zu. :(

[ @pradyunsg ausgeschnittener E-Mail-Inhalt]

@ThinkDigitalRepair pip 10 wird hoffentlich die Dinge verbessern - es werden bessere Fehlermeldungen anstelle eines langen PermissionError gedruckt, wenn dies passiert.

Schließe dieses Problem jetzt, da hier von Pip's Ende nichts umsetzbar ist.

Jeder, der nach Möglichkeiten zur Behebung/Umgehung dieses Problems sucht, sollte einen Blick auf https://github.com/pypa/pip/issues/5221#issuecomment -382069604 werfen.

@pradyunsg In vielen Fällen pip install --upgrade pip : Danach wird der Befehl pip abgebrochen und die Lösungen aus dem Kommentar werden ihn nicht beheben. Und das sollten sie nicht!

Wenn ein System pip 9 mit einem vom Benutzer installierten pip 10 installiert ist, versucht das System-Pip-Skript, main() vom Benutzer pip 10 mit einem falschen Importpfad zu importieren. Hash -r oder -d wird dies nicht beheben, da der pip-Befehl standardmäßig weiterhin das System pip ausführt. Und auch das Upgrade von Benutzer-Pip wird auch nicht behoben, da System-Pip immer noch 9 ist, Benutzer-Pip immer noch 10 ist, sodass der Import weiterhin fehlschlägt.

Die Lösung für diese Fälle muss darin bestehen, einen der beiden Pips zu deinstallieren.

• python -m pip uninstall pip --user , behält den System-Pip, der älter ist

oder

• sudo apt remove python-pip und behalten Sie das vom Benutzer installierte pip, das nicht zugänglich ist, indem Sie standardmäßig pip im Terminal ausführen. Sie müssen es entweder mit python -m pip ausführen oder die Pfade zu Ihrer PATH env var usw. hinzufügen.

All dies gilt für beide, Pip unter Python 2 und 3.

Auf allen meinen Ubuntu-Systemen (16.04, 17.10. 18.04) habe ich das System pip auf die alte Version und der Benutzer ist mit pip 10 und ich sehe nie Ihren Importfehler.
Sind Sie sicher, dass Sie kein beschädigtes System-Pip haben?

@gsemet Sie haben wahrscheinlich ~/.local/bin zu Ihrer PATH- Env-Var hinzugefügt (oder möglicherweise eine andere, intelligentere Shell als die Standard-Bash verwendet). Wenn Sie also pip ausführen, wird das vom Benutzer installierte pip 10-Skript verwendet. und nicht das vom System installierte pip 9-Skript. In Ubuntu ist dies standardmäßig nicht so. Es kann gemacht werden, sicher, und ich wünschte, es wäre standardmäßig so. Aber standardmäßig ruft der Befehl pip das auf dem System installierte pip auf, selbst wenn ein Benutzer eines installiert hat.

Wie man dies unter einer neuen Ubuntu 17.10-Installation reproduziert, einschließlich des Beweises, dass die Befehle in Kommentar 5221 es nicht beheben, und was ich vorgeschlagen habe, behebt es.

Installation beider Pips (System und Benutzer), die den Pip-Befehl unterbricht:

vfisa<strong i="7">@vilos</strong>:~$ sudo apt install python-pip
(...)

vfisa<strong i="8">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

vfisa<strong i="9">@vilos</strong>:~$ which pip
/usr/bin/pip

vfisa<strong i="10">@vilos</strong>:~$ pip install pip --upgrade --user
Collecting pip
  Downloading https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 631kB/s 
Installing collected packages: pip
Successfully installed pip-10.0.1

vfisa<strong i="11">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="12">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

vfisa<strong i="13">@vilos</strong>:~$ which pip
/usr/bin/pip

Wie Sie sehen, verweist der Befehl pip standardmäßig auf den System-Pip, nicht auf den vom Benutzer installierten.

Befehle aus dem referenzierten Kommentar, Beweis dafür, dass sie das Problem nicht beheben:

vfisa<strong i="19">@vilos</strong>:~$ hash -r

vfisa<strong i="20">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="21">@vilos</strong>:~$ hash -d
hits    command
   1    /usr/bin/pip

vfisa<strong i="22">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="23">@vilos</strong>:~$ python -m pip install pip --force-reinstall --user
Collecting pip
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 10.0.1
    Uninstalling pip-10.0.1:
      Successfully uninstalled pip-10.0.1
Successfully installed pip-10.0.1

vfisa<strong i="24">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="25">@vilos</strong>:~$ which pip
/usr/bin/pip

Wie Sie sehen, wird das Problem bestehen bleiben, solange beide Pips installiert sind und der Befehl pip auf den System-Pip verweist (Standardverhalten in Ubuntu).

Fixoption 1:

System pip entfernen, Benutzer pip beibehalten, auf den standardmäßig nicht über den Befehl pip zugegriffen werden kann (Sie müssen also python -m pip ).

vfisa<strong i="34">@vilos</strong>:~$ sudo apt remove python-pip
(...)

vfisa<strong i="35">@vilos</strong>:~$ pip
bash: /usr/bin/pip: No such file or directory

vfisa<strong i="36">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

Sie könnten ~/.local/bin zu Ihrer PATH env var hinzufügen, um den Befehl pip mit dem Benutzer pip verwenden zu können.

Fixoption 2:

Entfernen Sie den Benutzer pip, behalten Sie den System-Pip bei, der älter ist, aber standardmäßig einen funktionierenden pip Befehl im Pfad enthält.

vfisa<strong i="45">@vilos</strong>:~$ python -m pip uninstall pip
Uninstalling pip-10.0.1:
  Would remove:
    /home/vfisa/.local/bin/pip
    /home/vfisa/.local/bin/pip2
    /home/vfisa/.local/bin/pip2.7
    /home/vfisa/.local/lib/python2.7/site-packages/pip-10.0.1.dist-info/*
    /home/vfisa/.local/lib/python2.7/site-packages/pip/*
Proceed (y/n)? y
  Successfully uninstalled pip-10.0.1
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

vfisa<strong i="46">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

@fisadev Sicher, das ist erforderlich, um das vom Benutzer installierbare Paket 'pip install --user' zu unterstützen. Aber ich denke, es sollte den Benutzern gesagt werden "Wenn Sie das Update auf pip 10 erzwingen möchten, bevor das debian/ubuntu-Paket aktualisiert wird, müssen Sie pip install --user --upgrade pip und sicherstellen, dass $HOME/.local/bin in Ihrem Weg ist Es ist ganz einfach.

@gsemet Ich stimme zu, Benutzer sollten über die

@fisadev Vielen Dank. Fix Option1 hilft wirklich.

@RonnyPfannschmidt

Das Ersetzen des System-Pip durch Pip ist immer ein Akt des System-Vandalismus, bei dem derjenige, der ihn verursacht, für den Fallout verantwortlich ist

ist ein Kommentar des geistigen Vandalismus. Als ob die Person, die das (naive) Upgrade durchführt, absichtlich darauf aus ist, ihre eigene Installation zu beschädigen ... Wenn dies der Fall wäre, sollte pip selbst den Benutzer nicht dazu auffordern, jedes Mal von 9.0.1 auf 10.0.1 zu aktualisieren einzelner Pip-Befehl ausgeführt. Ich selbst bin dieser Empfehlung gefolgt und bin in diesem Schlamassel gelandet.

Glücklicherweise:
sudo python -m pip install pip==9.0.1
war ein einfaches Mittel.

Dem Opfer die Schuld zu geben, ist jedoch keine Antwort.

Hey @rod-app!

Wenn dies der Fall wäre, sollte pip selbst den Benutzer nicht dazu auffordern, mit jedem einzelnen ausgeführten pip-Befehl von 9.0.1 auf 10.0.1 zu aktualisieren.

Wir haben dies bemerkt und mit Betriebssystemanbietern zusammengearbeitet, um dies in zukünftigen Versionen von pip zu vermeiden. -- #5346.

Um das Problem zu lösen, habe ich ausgeführt...

sudo geany -i /usr/bin/pip

...und das von Debian bereitgestellte /usr/bin/pip bearbeitet, um es zu ersetzen durch ...

#!/bin/sh
# GENERATED BY CEFN
python -m pip "$@"

und das Äquivalent für /usr/bin/pip3 (beachten Sie, dass dies stattdessen python3 aufruft).

#!/bin/sh
# GENERATED BY CEFN
python3 -m pip "$@"

...was trotz der in meinen Site-Paketen installierten Version 10 die volle Funktionalität von pip zurückbringt. Ich denke, dies wird genau so lange dauern, wie Debian braucht, um es zu reparieren (oder es erneut zu brechen), indem es ein aktualisiertes python-pip-Paket sendet. Warum sie das Paket main nicht verwendet haben, weiß ich nicht.

Offizielle Version

Die unten gezeigte Version von pip, die in .local/bin/pip installiert ist, ist etwas schicker und enthält einige Ersetzungen, um die Erweiterungen -script, .py, .pyw und .exe aus übergebenen Argumenten zu entfernen, aber ich weiß nicht, was das bewirkt oder warum ich es brauche, also habe ich es der Einfachheit halber wie oben belassen.

#!/usr/bin/python

# -*- coding: utf-8 -*-
import re
import sys

from pip._internal import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

Ich habe eine unabhängige Ursache für dieses Pip v10-Problem gefunden. Beim Upgrade von pip mit einem sehr alten System pip (v1.5.6 auf Debian Jessie, dh oldstable), für das --system die Standardeinstellung ist, habe ich festgestellt, dass falsche Skripte installiert wurden, zB /usr/local/bin/pip mit from pip import main -- die ich beim Durchsehen der Dateien gefunden habe. Ich gehe davon aus, dass dies daran liegt, dass das ältere pip (oder möglicherweise die verwendeten Installationspakete) die .whl-Datei falsch installiert.

python -m pip install --force-reinstall pip behoben.

5599 bietet Informationen und einen zentralen Ort, um Hilfe bei der Lösung dieses Problems für Endbenutzer zu erhalten.

Der Kommentarbereich dieser Ausgabe steht Benutzern offen, um spezifische Probleme und Lösungen zu diskutieren. :)