Hier ist die Ausgabe von pip3:

werner in ~ at octopus23
➜ pip3 install pipenv
Collecting pipenv
  Using cached https://files.pythonhosted.org/packages/2c/01/37a5867a47d52856b077d0faa561b791cb6e6e3e9410837b6d62f569c1e6/pipenv-11.10.1-py3-none-any.whl
Collecting virtualenv (from pipenv)
  Using cached https://files.pythonhosted.org/packages/ed/ea/e20b5cbebf45d3096e8138ab74eda139595d827677f38e9dd543e6015bdf/virtualenv-15.2.0-py2.py3-none-any.whl
Collecting pip>=9.0.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Collecting setuptools>=36.2.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/8c/10/79282747f9169f21c053c562a0baa21815a8c7879be97abd930dbcf862e8/setuptools-39.1.0-py2.py3-none-any.whl
Collecting virtualenv-clone>=0.2.5 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/6d/c2/dccb5ccf599e0c5d1eea6acbd058af7a71384f9740179db67a9182a24798/virtualenv_clone-0.3.0-py2.py3-none-any.whl
Collecting certifi (from pipenv)
  Using cached https://files.pythonhosted.org/packages/7c/e6/92ad559b7192d846975fc916b65f667c7b8c3a32bea7372340bfe9a15fa5/certifi-2018.4.16-py2.py3-none-any.whl
Installing collected packages: virtualenv, pip, setuptools, virtualenv-clone, certifi, pipenv
Successfully installed certifi-2018.4.16 pip-10.0.1 pipenv-11.10.1 setuptools-39.1.0 virtualenv-15.2.0 virtualenv-clone-0.3.0

Ich vermute, dass dies wahrscheinlich eine Folge davon ist, dass Pipenv von Pip abhängt, aber ich bin mir nicht sicher, ob Pipenv dafür verantwortlich sein sollte. Vielleicht sollte Debian das tun, weil sie es waren, die die Python-Pip-Kopplung gebrochen haben. Pipenv ist sicherlich auch nicht das einzige Paket, das von Pip abhängt, aber ich bin mir nicht sicher, was hier die beste Vorgehensweise ist.

@ncoghlan könnten Sie einen Einblick in dieses Thema geben? Speziell

1. Sollte ein Paket von pip abhängen?
2. Wenn 1. ja, sollte es für diese Art von Konflikt mit dem Systempaketmanager verantwortlich sein?
3. Wenn 2. ja, wie?
4. Wenn 2. nein, wer sollte verantwortlich sein? Soll der Benutzer stattdessen angewiesen werden, eine Problemumgehung zu verwenden?

Auf jeden Fall sollten Sie wahrscheinlich sowieso nie etwas unter Ubuntu sudo pip install tun. Sie sollten stattdessen einen der folgenden Schritte ausführen

• Verwenden Sie APT ganz nach unten
• pip install --user
• Ein benutzerdefinierter Manager wie pipsi

Oder noch besser, vermeiden Sie System-Python ganz und verwenden Sie stattdessen pyenv oder andere Python-Laufzeitmanager.

Kratzen Sie die. Vermeiden Sie Python von APT, Punkt.

Sie sollten wahrscheinlich sowieso nie sudo pip etwas auf Ubuntu installieren

Habe ich eigentlich nie gemacht. Ich bin mir der Probleme bei der Verwendung von sudo pip unter Ubuntu bewusst, daher verwende ich wann immer möglich apt oder bleibe bei --user .

Ah ich sehe das Problem jetzt. Benutzermodule haben Vorrang vor Systemmodulen, aber /usr/bin ist vor $HOME/.local/bin in PATH . /usr/bin/python versucht, die System-Pip-Installation (die immer noch 9.x ist) zu importieren, hat aber die Benutzerinstallation (die 10.x) gefunden. Was für ein Chaos.

2095 ist dasselbe, aber ich möchte dies offen halten, weil ich denke, dass es eine robustere Lösung geben sollte, als davon abhängig zu sein, dass der Benutzer ein freundliches PATH .

Es ist ziemlich stabil, wenn der Benutzer Folgendes hat:

• ˜/.local/bin am Anfang von PATH des Benutzers. Sollte bei Ubuntu Standard sein, seit 16.10 . Es ist eine gute Praxis, es zu haben, da es ein pip install --user Verhalten ermöglicht, das ein absolut gültiger Anwendungsfall ist
• Benutzer sollten immer pip install --user . Das Herumspielen mit dem Pip des Systems ist in jeder Distribution wirklich schlecht, selbst die seltsamen Ordner "dist-packages/site-packages" in Debian schützen nicht vor Fehlern von Benutzern.

Wir haben dieses Verhalten bei allen unseren Ubuntu-Benutzerinstallationen sichergestellt (Organisation von mehr als 1000 Installationen verschiedener Ubuntu-Versionen), und der Übergang zu pip10 funktionierte wie ein Zauber.

Obwohl ich zustimme, dass Python und sein Ökosystem kompliziert sind und dass es besser wäre, wenn die Leute ihre Pfade nicht richtig konfigurieren müssten, um die Suchreihenfolge richtig zu machen, ist dies leider nur eine Tatsache, wie die Installation derzeit in Paketmanagern funktioniert und es ist nicht gerade ein Pipenv-Problem an sich. Ich glaube nicht, dass wir viel tun können, um es unabhängig anzugehen, es ist eher ein Problem, das auf den Python-Mailinglisten angesprochen werden muss

Ah, jetzt verstehe ich das Problem, danke. Hätte nie gedacht, dass der Pfad dies beeinflussen könnte, weshalb ich nicht darauf gekommen bin, ihn in die Problembeschreibung aufzunehmen. Tut mir leid und danke für deine Hilfe.

Was es für mich behoben hat, war das Hinzufügen

export PATH="${HOME}/.local/bin:$PATH"

zum Profil.

Bearbeiten: Stellen Sie sicher, dass Sie hash -r ausführen oder eine neue Shell eingeben, damit diese Änderung wirksam wird.

Ich glaube nicht, dass wir viel tun können, um es unabhängig anzugehen

Vielleicht gibt es noch detailliertere Installationsanweisungen oder Vorbehalte? Ich bin nicht allzu erfahren mit der Funktionsweise von Pip, habe aber möglicherweise einen Hinweis zu Pfadproblemen gelesen. Aber ich vermute, dass das Ökosystem der verschiedenen Paketmanager und Distributionen für eine einfache Regel zu komplex ist…

@slhck es ist eigentlich so frustrierend, dass es vor ein paar Tagen diese xkcd speziell über Python-Umgebungen und Sudo- und Paketmanager-Installationen gab

Hier ist eine schöne Schritt-für-Schritt-Anleitung, die ich erfolgreich unter Ubuntu 18.04 verwendet habe:
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

Es gibt auch https://github.com/pypa/python-packaging-user-guide/issues/396 , in dem die Frage erörtert wird, ob wir möglicherweise eine Checkliste oder ein Skript zur Fehlerbehebung erstellen können, um den Leuten zu helfen, sie zu identifizieren und lösen potenzielle Probleme in ihrer Umgebung. Ich werde dort eine Notiz über die Möglichkeit von PATH / sys.path Bestellkonflikten machen.

Danke, @slhck . Ihr Export-Workaround hat mir die meiste Zeit gespart; Ich habe es zu /etc/profile hinzugefügt.

Es ist wirklich dumm, dass wir 2 Ebenen der Softwarepaketierung unter Linux haben. Schlimmer noch, mit der neuesten Version des *buntus sind beide Geschmacksrichtungen einer von ihnen (pip/pip3) kaputt.

Ich habe es auf Launchpad geschrieben: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1772746

@texadactyl Debian hat diese Richtlinie (ich vergesse, was sie ist), dass pip nicht standardmäßig installiert werden sollte, und sie haben sich mit vielen früheren Beschwerden daran gehalten. Die Tradition liegt tief, tief in den Debian-Wurzeln. Ich würde mich freuen, wenn sie das noch einmal überdenken könnten, aber ich bezweifle sehr, dass sie es tun würden.

Ich hatte das gleiche Problem unter Ubuntu 18 und Python 3.6

Unten sind die Schritte, die ich befolgt habe:

1) Zuerst erhielt ich den Fehler:

Traceback (letzter Anruf zuletzt):
Datei "/usr/bin/pip", Zeile 9, in
von pip import main
ImportError: Name main kann nicht importiert werden

2) Ich habe die Datei /user/bin/pip geändert in:

Importsystem
from pip._internal import main als _main
if __name__ == '__main__':
sys.exit(main())

3) Dann fing es an, mir diesen Fehler zu geben:

Traceback (letzter Anruf zuletzt):
Datei "/usr/bin/pip3", Zeile 11, in
sys.exit(main())
NameError: Name 'main' ist nicht definiert

4) Ich habe /usr/bin/pip3 geändert zu:

Importsystem
from pip._internal import main als _main
if __name__ == '__main__':
sys.exit(_main())

5) Dann bekam ich den Fehler:

Traceback (letzter Anruf zuletzt):
Datei "/usr/bin/pip3", Zeile 11, in
sys.exit(main())
NameError: Name 'main' ist nicht definiert

6) Ich habe main() in _main() umbenannt und voila .. es hat funktioniert !!! :) :)

Obwohl das das Problem für Sie vielleicht gelöst hat, ist dies ein ziemlich schlechter Rat. Sie sollten Systemdateien nicht manuell ändern. Eine Lösung finden Sie in meinem früheren Kommentar.

Bearbeiten: Die Lösung von @slhck hat es gelöst. Du musst ~/.local/bin in deinem Weg haben

Bekomme das gleiche Problem unter Ubuntu 16.04.

$ sudo apt install python3-pip
$ pip3 --version
pip 8.1.1 from /usr/lib/python3/dist-packages (python 3.5)
$ python3 -m pip install --user pipenv
$ pip3 --version
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

# revert back and fix pip
$ sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

Ich möchte nur hinzufügen, dass ich auch über dieses Problem gestolpert bin. Ich hatte bereits ~/.local/bin als erstes auf meinem Weg. Das Problem ist, wie Bash Befehle hasht. Die Lösung für dieses Problem wurde hier gefunden: https://github.com/pypa/pip/issues/5221#issuecomment -381568428

@thernstig Ja, das ist richtig – ich habe meiner obigen Lösung den erforderlichen hash -r Befehl hinzugefügt, den ich vergessen habe, explizit zu erwähnen.

@slhck Kein Problem, freut mich, dass ich helfen konnte

Ich habe festgestellt, dass das Problem geschlossen ist, aber ich poste in der Hoffnung, dass dies dazu beitragen kann, Änderungen an PATH zu vermeiden. Ich bin heute beim Einrichten eines neuen Ubuntu 18.04-Computers darauf gestoßen und konnte es ohne PATH-Änderungen beheben, obwohl ich neu gestartet habe (ich bin mir ziemlich sicher, dass das Abmelden / Anmelden funktioniert, aber nicht überprüft wurde).

Nach der Installation von pip3 über python3-pip und pipenv mit pip3 install --user pipenv erhielt ich den Betreff-Fehler. Ich wollte gerade den Workaround von @slhck verwenden, als mir in ~/.profile Folgendes aufgefallen ist ( vorrat , ich habe keine Änderungen):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Neugierig startete ich neu und tatsächlich wurde das Problem gelöst, da mein .local/bin jetzt am Anfang meines PATHs stand und pip3 wieder funktionierte.

@jlitzingerdev Ich bin mir ziemlich sicher, dass der Pfad der Standard ist, es ist nur so, dass ich für mein System, da ich eine andere Shell und ein anderes Profil verwendet habe, es entfernt oder von Grund auf neu erstellt habe, daher meine „Abhilfe“, die nicht notwendig gewesen wäre an erster Stelle. Schön, dass du es herausgefunden hast.

@slhck Ist es, aber es ist möglicherweise nicht in PATH bei der ersten Anmeldung, da ~/.local/bin möglicherweise nicht existiert, oder dies war mein spezifischer Fall.

Was müssen wir tun?

Ich möchte mich nur für die Aufnahme von Wiederherstellungsbefehlen bedanken. Ich hatte Probleme, Pip wieder zum Laufen zu bringen.

Ich möchte pipenv unter Ubuntu 18.04 installieren. Wenn ich dies tue, bricht es pip / pip3.

Erwartetes Ergebnis

Installierte und funktionierende Version von pipenv.

Tatsächliche Ergebnis

pip / pip3 sind kaputt, je nachdem ob ich pipenv aber pip oder pip3 installieren wollte.

➜ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Schritte zum Replizieren

1. Set up Ubuntu 18.04

2. Run `pip install pipenv` or `pip3 install pipenv`

3. Run `pip` or `pip3` – the error is printed, and pip / pip3 do not work anymore.

Um das Problem zu beheben, muss ich Folgendes ausführen:

sudo python -m pip uninstall pip && sudo apt install python-pip --reinstall
sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

Aber ich kann pipenv nicht mit pip installieren. Die Installation über apt funktioniert nicht, da kein PPA verfügbar ist.

ich habe 3 pip in meinem ubuntu 18 pip, pip3 und pip3.6 pip ist für 2,7 pip3 ist für 3,5 und pip3.6 für 3,6, wobei pip jetzt den Dateispeicherort in .local/bin anzeigt. Ich habe die Datei pip und pip3 von hier entfernt. Welche pip3 zeigt mir nun die /usr/bin/pip3. Führen Sie den Befehl sudo nano /usr/bin/pip3 aus und ändern Sie die erste Zeile für den Interpreter als !#/usr/bin/python3 in #/usr/bin/python3.5. funktioniert bei mir. alle meine Pips funktionieren. ich hoffe das hilft

ich habe 3 pip in meinem ubuntu 18 pip, pip3 und pip3.6 pip ist für 2,7 pip3 ist für 3,5 und pip3.6 für 3,6, wobei pip jetzt den Dateispeicherort in .local/bin anzeigt. Ich habe die Datei pip und pip3 von hier entfernt. Welche pip3 zeigt mir nun die /usr/bin/pip3. Führen Sie den Befehl sudo nano /usr/bin/pip3 aus und ändern Sie die erste Zeile für den Interpreter als !#/usr/bin/python3 in #/usr/bin/python3.5. funktioniert bei mir. alle meine Pips funktionieren. ich hoffe das hilft

All diese Schritte werden wirklich nicht empfohlen. Sie sollten Dateien in /usr/bin nicht manuell bearbeiten. Versuchen Sie stattdessen, pip wie oben erwähnt zu deinstallieren und über apt neu zu installieren. Dadurch sollten Sie die richtigen Systeminstallationen erhalten. Wenn Sie dann Probleme mit pipenv , öffnen Sie bitte ein neues Problem und beschreiben Sie Ihr Problem, anstatt solche Problemumgehungen zu versuchen.

eine Neuinstallation über apt wie oben erwähnt ändert nichts, da die gleiche Ausgabe generiert wird. Es gibt einfach an, dass der Name main nicht importiert werden kann, und beim Importieren von pip in einem Python-Interpreter wird es als Modul importiert, was bedeutet, dass der Name main in dem Modul, in dem er gesucht wird, nicht verfügbar ist. Jetzt habe ich oben nicht vorgeschlagen, blind zu bearbeiten. Als Software-Enthusiast, als ich auf ubuntu14 war, habe ich die pip-Datei überprüft und sie hat den gleichen Code wie der in ubuntu18 pip3. also was hat sich geändert. Die mitgelieferte Python-Version hat dies getan.

Weil pip für Python3.5 und 2.7 nur main im pip-Modul definiert hat.
Und Python3.6 hat es in pip._internal . definiert

Jetzt lösen die beiden obigen Aussagen das Problem aller

das Problem liegt im verwendeten Interpreter selbst

Python3; aber auf welches Python bezieht es sich?
Entwickler, die nur Python 2.7 hatten und auf Ubuntu18 umgestellt haben, werden wahrscheinlich Python 3 als Python3.6 verwenden

aber was ist mit denen, die python3.4 pr 3.5 installiert hatten. Zuerst referenziert python3 auf python3.5 und jetzt nach dem Upgrade wird es auf python3.6 verweisen

Die Art und Weise, wie es von Debian gehandhabt wurde, hat es also gebrochen

die bloße Angabe des richtigen Dolmetschers löst das Problem
dass beide Fehler haben

von pip import main
und
from pip._internal import main als _main

Vielen Dank
ps
An dieser Stelle muss ich sagen , dass Vorlesungen auf anderen Plattformen nicht in Ordnung sein werden , aber auf Github , wo andere leidenschaftliche Entwickler kommen , um ihre Probleme zu lösen ; Besonders wenn sie versuchen, viele Befehle auszuführen oder einige Konfigurationsdateien zu bearbeiten, um es zum Laufen zu bringen, muss ich sagen, sei nicht so schlau, dass du anfängst, solche Leute zu entmutigen.

HINWEIS: Die neuen Versionen werden nicht funktionieren, wenn sie den Code nicht ändern. Sie werden Problemumgehungen hinzufügen, damit es für alle funktioniert, die es deinstallieren und installieren

Ich hoffe an dieser Stelle wirst du es bekommen. Ruhe und stör mich nicht wieder

@r-tron18 Es tut mir leid, dass Sie sich von dem, was als konstruktiver Vorschlag gemeint war, belehrt fühlen – Sie sollten keine Systemdatei ändern. Aus dem kleinen Kontext, den Sie in Ihrem ursprünglichen Beitrag gegeben haben, war es unmöglich zu sagen, ob Sie ein erfahrener Benutzer sind, der weiß, was er tut, oder einfach nur Problemumgehungen anwendet, die er woanders gefunden hat. Ich verbringe viel Zeit mit verschiedenen Fehlerbehebungs- und Q&A-Websites, und ich denke, Sie stimmen zu, dass wir Benutzer nicht ermutigen sollten, zufällige Fixes auszuprobieren oder sudo -eine vom System gelieferte Datei zu bearbeiten, was oft zu mehr führt Fehler und Verwirrung. Das ist eher ein allgemeines Thema.

Ich bin immer noch nicht überzeugt, dass das, was Sie vorschlagen, eine zuverlässige Lösung ist. Und: Wir können eine zivile Diskussion über die Vorzüge dieser Lösung führen – GitHub ist ein Ort, an dem ich das zum Ausdruck bringen darf.

Der Grund ist: Wenn Sie den Shebang von /usr/bin/pip3 in #!/usr/bin/python3.5 ändern, werden Sie nur bei dieser Version stecken bleiben. Es sollte #!/usr/bin/python3 lauten, und das sollte ein symbolischer Link zu /usr/bin/python3.6 (oder was auch immer auf Ihrem System aktuell ist). Jedes Python-Upgrade wird diese Datei wahrscheinlich sowieso ändern.

Du sagst:

aber was ist mit denen, die python3.4 pr 3.5 installiert hatten. Zuerst referenziert python3 auf python3.5 und jetzt nach dem Upgrade wird es auf python3.6 verweisen
Die Art und Weise, wie es von Debian gehandhabt wurde, hat es also gebrochen

Wollen Sie damit sagen, dass nach einem Upgrade von Python 3.5 auf Python 3.6 der Symlink python3 nicht aktualisiert wurde? Wenn es sich bei dem, was Sie beobachten, tatsächlich um einen Fehler bei Debian oder Ubuntu handelt, bei dem ein Python-Upgrade nicht die richtigen Symlinks gesetzt hat, dann sollte dieser Fehler wahrscheinlich vom Upstream behoben werden, nicht wahr?

Ich habe festgestellt, dass das Problem geschlossen ist, aber ich poste in der Hoffnung, dass dies dazu beitragen kann, Änderungen an PATH zu vermeiden. Ich bin heute beim Einrichten eines neuen Ubuntu 18.04-Computers darauf gestoßen und konnte es ohne PATH-Änderungen beheben, obwohl ich neu gestartet habe (ich bin mir ziemlich sicher, dass das Abmelden / Anmelden funktioniert, aber nicht überprüft wurde).

Nach der Installation von pip3 über python3-pip und pipenv mit pip3 install --user pipenv erhielt ich den Betreff-Fehler. Ich wollte gerade den Workaround von @slhck verwenden, als mir in ~/.profile Folgendes aufgefallen ist ( vorrat , ich habe keine Änderungen):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Neugierig startete ich neu und tatsächlich wurde das Problem gelöst, da mein .local/bin jetzt am Anfang meines PATHs stand und pip3 wieder funktionierte.

Bei mir funktioniert es, nach dem Neustart funktioniert alles einwandfrei. (nach der Installation: "pip3 install --user pipenv" starten Sie Ihr System neu und es wird funktionieren.