Pipenv: 2018.11.26: pipenv gibt beim Erstellen einer virtuellen Umgebung Python-Fehler aus

Es scheint, dass /usr/local/bin/pythonz kein gültiger Pfad mehr ist.

Hmm. Sollte es jemals gewesen sein? Ich habe Pythonz noch nie direkt verwendet. Ich dachte, es sei nur eine Pipenv-Abhängigkeit, die bei der Installation von Pipenv verwaltet wurde.

Für Kicks habe ich gerade pipenv 2018.11.26 deinstalliert und neu installiert und habe immer noch das Problem.

Können Sie die Ausgabe von pipenv --support bereitstellen? Und um zu bestätigen, nein, es hätte nicht sein sollen

Oh nvm hat gerade deine Nachricht gesehen. Ich möchte nur bestätigen, dass sich irgendwo keine betrügerische Version von pipenv auf Ihrem Weg befindet. Können Sie which pipenv und python -m pipenv --version überprüfen

$ which pipenv
/usr/local/bin/pipenv

python -m pipenv --version No module named pipenv da sowohl Python 2 als auch Python 3 über Homebrew installiert sind und python Python 2.7 ausführt. Gemäß einer vorherigen Empfehlung hier habe ich pipenv unter Python 3 installiert. Also habe ich python3 und erhalten:

$ python3 -m pipenv --version
pipenv, version 2018.11.26

Vielen Dank!

Ah ok. Und ja, der Fehler macht Sinn. Ich werde es einfach stromaufwärts markieren und sicherstellen, dass es repariert wird

Gibt es ein Wort darüber, wann ein Fix dafür veröffentlicht wird? Ich habe dieses Problem, das mich daran hindert, die Pipenv-Anforderungen zu installieren. Ich habe @commandtabs Problemumgehung ohne solches Glück ausprobiert.

Ich kann nicht pipenv zur Arbeit überhaupt mit der aktuellen Version.

$ which pipenv
/Users/josh/.pyenv/shims/pipenv

$ python -m pipenv --version
pipenv, version 2018.11.26

Ich habe versucht, mit Python3.7 von Homebrew zu installieren, und das gleiche Problem.

Es scheint, dass es hier keine Dringlichkeit gibt oder dass es kein großes Problem ist. Vermisse ich etwas oder ist pipenv mit der aktuellen Version komplett kaputt ?

Die aktuelle Version scheint mir sicher abgespritzt zu sein. Eine weitere vorübergehende Problemumgehung, die ich in einer früheren Ausgabe gesehen habe, bestand darin, einen python -Pfad wie folgt einzugeben:

pipenv --three --python=`which python3`

Ich mache das vorerst mit Erfolg: Grimassen:

Diese Problemumgehung hat bei mir nicht funktioniert. Ich musste ein Downgrade auf 2018.10.13 und dann die Problemumgehung für diesen Thread verwenden :

pipenv install -d --python=$HOME/.pyenv/versions/3.7.1/bin/python

Soweit ich das beurteilen kann, ist pipenv seit Oktober komplett kaputt.

@techalchemy Irgendein Wort zu einem Upstream-Tag-Fix? Für die Erstellung von pipenv virtualenv sind weiterhin Problemumgehungen für den Aufruf erforderlich.

Danke ❤️

Dies war ein bisschen rau mit all den anderen Korrekturen, die integriert werden mussten, aber ich denke, CI wird jetzt erfolgreich sein und dies wird mit # 3330 behoben - entschuldigen Sie die Probleme

Ah ok. Und ja, der Fehler macht Sinn. Ich werde es einfach stromaufwärts markieren und sicherstellen, dass es repariert wird

Das Problem besteht weiterhin, jede Idee, wann dieses Update veröffentlicht wird.

Gleiches Problem hier.

Kann bestätigen, dass die Problemumgehung von @ command-tab weiterhin funktioniert.

Dies passiert definitiv immer noch mit Homebrew Pipenv und Python. Ein bisschen überrascht, dass es keinen Test gibt, um zu sehen, wie lange es dieses Problem schon gibt.

Ich kann auch bestätigen, dass dieses Problem weiterhin besteht, obwohl dieses GitHub-Problem geschlossen wurde.

Müssen die Betreuer ein neues Problem erstellen?

Gleiches Problem mit Ubuntu 18 LTS, das im Windows-Subsystem für Linux installiert ist.

Problemumgehung funktioniert bei mir.

@techalchemy Dieses Problem scheint immer noch zu bestehen. Können Sie es bitte entweder erneut öffnen oder klarstellen, dass eine neue Ausgabe erstellt werden soll?

Vielen Dank.

Gleiches Problem mit Ubuntu 18 LTS, das im Windows-Subsystem für Linux installiert ist.

hier gilt das gleiche

@techalchemy bitte nochmal schauen

Gleiches Problem hier auf den MacOs Mojave und Python 3.7

Ich auch:

• Catalina
• Python 3.7.

Alles funktioniert gut, wenn ich diese Zeile in meinem Pipfile auskommentiere:

[requires]

#python_version = "3.7.4"

Ich auch:

• Catalina
• Python 3.7.

Alles funktioniert gut, wenn ich diese Zeile in meinem Pipfile auskommentiere:

[requires]

#python_version = "3.7.4"

ahhhh das hat bei mir funktioniert, danke!

@JarredStanford @edsu
Dies funktionierte auch für mich bei WSL in VSCode (ich habe keine externe Shell ausprobiert, da dies für ein anderes Projekt gut funktioniert hat).

@ Befehlsregisterkarte
Das Hinzufügen von "--python = which python3 " hat ebenfalls funktioniert. Ich habe nicht versucht, "--three" hinzuzufügen, und es scheint für meinen Anwendungsfall / meine Version nicht erforderlich zu sein.

Nachdem ich beide Problemumgehungen erhalten hatte und sie zum Laufen gebracht hatte, entfernte ich sie und versuchte ein drittes Mal, um sicherzustellen, dass die Umgebung immer noch ein Problem verursachte (Erzähler: es war).

@ Techalchemy
Ich denke, dass dies in 3330 möglicherweise nicht "vollständig behoben" ist? Es könnte sich um ein tangentiales Problem handeln, das dieselben Symptome verursacht. In meinem Fall verwende ich WSL und frage mich, ob 'python3' und 'python3.exe', die sich beide in meinem WSL-Pfad befinden, verdächtig erscheinen.

Würden Sie es für das Beste halten, wenn ich eine neue Ausgabe öffne? Möchten Sie, dass ich zusätzliche Diagnosen durchführe oder etwas anderes?

Ich benutze wsl2 mit arclinux (manjaro)
Es scheint, dass pipenv die Python in Host-Env-Fenstern aufruft, um sie zu installieren
Also müssen wir definieren, wo die Python zu finden ist mit:
pipenv --python=<PATH_TO_PYTHON>
oder
pipenv --python=which python3

funktioniert bei mir.

Kann bestätigen, dass dies unter WSL mit Ubuntu 18.04 LTS geschieht. Es scheint, als würde pipenv nach einem Python-Interpreter suchen, anstatt den zu verwenden, unter dem er ausgeführt wird, und dabei PATH in umgekehrter Reihenfolge durchlaufen. Ich habe mehrere Python-Umgebungen installiert, und wenn ich eine manuell aus PATH entferne, findet pipenv eine andere und beschwert sich stattdessen über diese.

Ich sehe das gleiche Problem unter WSL mit Ubuntu 18.04 LTS. pipenv install --python $(which python3) funktioniert, aber wenn ich anschließend pipenv shell mache, kann es die Abhängigkeiten nicht finden, die es hätte herunterladen sollen.

Auch ich bin betroffen, mit WSL 1 und Ubuntu 18.04. Problemumgehung --python $(which python) funktioniert.

Der Grund für den letzten Teil der Ausnahme, dh dieses Bit:

  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/utils.py", line 68, in get_python_version
    combine_stderr=False, write_to_stdout=False)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 314, in run
    write_to_stdout=True
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 162, in _create_subprocess
    sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))
TypeError: write() takes exactly one argument (3 given)

... liegt daran, dass der Aufruf zum Drucken eines Fehlers bei der Behandlung der ersten Ausnahme einen Fehler enthält. Dieser Fehler wurde anscheinend bereits im Januar 2019 im Master behoben - https://github.com/pypa/pipenv/commit/574fe7308d9ac81d64da954722f35c9eee0dd467#diff -a59595db75020aeb9f688d6a0b4818e6L162. Aber da die neueste Version von pipenv 2018.11.26 ist, stelle ich mir vor, dass die meisten keine feste Version haben.

Man kann es manuell patchen. Öffnen Sie /usr/local/lib/<your-python-version>/site-packages/pipenv/vendor/vistir/misc.py , navigieren Sie zu Zeile 162 und ändern Sie dies:

sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))

... dazu:

sys.stderr.write(f"Error {exc} while executing command " + " ".join(cmd._parts))

Sie erhalten jetzt einen genaueren Ausnahmebericht. In meinem Fall besteht das Problem darin, dass WSL Linux-basiertes pipenv Windows-basierte Python-Installationen erkennt und Probleme beim Ausführen hat, was offensichtlich ist:

Error [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe' while executing command /mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe -c import sys; print(['Traceback (most recent call last):\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/contextmanagers.py", line 150, in spinner\n    yield _spinner\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 314, in run\n    write_to_stdout=True\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 160, in _create_subprocess\n    combine_stderr=combine_stderr)\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 134, in _spawn_subprocess\n    return subprocess.Popen(cmd, **options)\n', '  File "/usr/lib/python3.6/subprocess.py", line 729, in __init__\n    restore_signals, start_new_session)\n', '  File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child\n    raise child_exception_type(errno_num, err_msg, err_filename)\n', "OSError: [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe'\n"]

Für WSL-Benutzer kann das Problem meines Erachtens behoben werden, indem sichergestellt wird, dass alle Anforderungen an Ihre Python-Version in Pipfile genau mit einer Linux-basierten Python-Installation übereinstimmen, z

[requires]
python_version = "3.6.8"  # Make sure this exactly matches an installed version, or remove it.

Hoffe das hilft.

Ich bin mir nicht sicher, wie viel dies hilft, aber das Löschen des Pipfiles, das Ausführen von pipenv lock und das anschließende Einfügen des Inhalts des alten Pipfiles in das Ausführen von pipenv install funktioniert dauerhaft für mich.