Pipenv: Der Befehl „pipenv install XYZ“ hängt manchmal auf unbestimmte Zeit bei „Abhängigkeiten von [Paketen] sperren“

Nicht, dass dies auf jeden Fall passieren sollte, aber auf welcher Hardware läuft das?

@uranusjr Bitte finden Sie den beigefügten Hardware-Informationsbericht.
hardinfo_report.txt

Geschieht dies ständig? Versuchen Sie es pipenv lock —verbose —clear

@techalchemy , ich habe pipenv lock --verbose --clear laufen lassen und die Ergebnisse sind ähnlich:

> pipenv lock --verbose --clear
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…

Es blieb bei "Abhängigkeiten von [Paketen] sperren" hängen.

Haben Sie Glück, dies auf Ihrem Computer zu reproduzieren? Insbesondere bei Tensorflow passiert es mir jedes Mal.

EDIT: Ich habe das auf dem Computer eines Freundes getestet. Er führt Ubuntu 17.10 aus und hat das Problem nicht festgestellt. Beide Computer befinden sich im selben Netzwerk. Ein Unterschied zwischen seinem und meinem Computer besteht darin, dass er nur pipenv und nicht pipenv und virtualenvwrapper installiert hat. Ich werde eine virtuelle Maschine hochfahren, um zu sehen, ob diese irgendwie mit virtualenvwrapper und/oder den von mir festgelegten Umgebungsvariablen verbunden ist, die von beiden gemeinsam genutzt werden (dh $WORKON_HOME).

Ich sehe derzeit das gleiche Problem; meine Ausgabe pipenv lock --verbose --clear sieht genauso aus wie die von @MarenstainBear . Ich verwende Ubuntu und verwende pyenv, um virtualenvs zu verwalten.

hardinfo_report.txt

Wie ich sehe, haben Sie Pipenv gegen das System Python installiert. Haben Sie zufällig pyopenssl (oder etwas anderes SSL-bezogenes, ehrlich gesagt, ich kann mich nicht erinnern, es ist Teil von requests[security] ) in derselben Umgebung installiert? Es ist bekannt, dass dies die Operationen extrem langsam macht.

Ich habe requests[security] und pyopenssl in der virtuellen Umgebung installiert, nur um sicherzugehen, aber es hängt immer noch. Beim weiteren Debuggen habe ich festgestellt, dass es beim zweiten Mal in venv_resolve_deps hängt, insbesondere in Zeile 376, c = delegator.run(cmd, block=True) .

Was noch seltsamer ist, ist, dass wenn ich diesen Befehl direkt ( python resolver.py ) über die Befehlszeile ausführe, er perfekt läuft.

Ja, es scheint, als ob ich das tue, aber nur für meine Python 2, nicht für Python 3 (und meine Pipenv-Instanz wurde über die Python 2-Version von Pip installiert):

mary<strong i="6">@marvel</strong>:~$ /usr/bin/python2.7 -m pip freeze | grep -i ssl
pyOpenSSL==17.5.0
mary<strong i="7">@marvel</strong>:~$ /usr/bin/python3 -m pip freeze | grep -i ssl
mary<strong i="8">@marvel</strong>:~$ 

Ich gehe zu meinem anderen Laptop und in einige virtuelle Umgebungen, in denen ich das nicht reproduzieren kann, um zu sehen, ob sie pyOpenSSL _nicht_ haben.

BEARBEITEN: Ein paar Absätze zu einem anderen Problem gelöscht, das ich gesehen habe. Das war mein Fehler - ich war tatsächlich in einem Unterverzeichnis, habe es aber nicht bemerkt, weil ich ohne meine normale zsh-Konfiguration, die zu Testzwecken deaktiviert wurde, keinen visuellen Indikator mehr in meiner Eingabeaufforderung meines cwd hatte. Wie @uranusjr richtig feststellte, "aber Pipenv führt eine Menge Umgebungserkennung durch und funktioniert bekanntermaßen seltsam in einer falsch konfigurierten Shell." ... Ich hatte meine Shell tatsächlich vorübergehend falsch konfiguriert.

@uranusjr
BEARBEITEN 2: Ich habe dies auf einer virtuellen Maschine mit einem ziemlich ähnlichen Setup wie auf meiner Host-Maschine getestet (einschließlich der Installation von pipenv gegen eine Python 2.7.12-Umgebung mit dem pyOpenSSL-Modul), und auf dieser Maschine funktioniert alles wie erwartet perfekt. Das lässt mich bezweifeln, dass pyOpenSSL hier das Problem ist. (Ich habe festgestellt, dass die Version von pipenv auf meiner virtuellen Maschine höher ist, also denke ich, dass ich pipenv lokal aktualisieren werde, um zu sehen, ob das einen Unterschied macht.)

Pipenv-Version: '11.9.0'

Pipenv-Standort: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Python-Speicherort: '/usr/bin/python'

Andere Python-Installationen in PATH :

• 2.7 : /usr/bin/python2.7
• 2.7 : /usr/bin/python2.7
• 3.5 : /usr/bin/python3.5m

• 3.5 : /usr/bin/python3.5

• 2.7.12 : /usr/bin/python

• 2.7.12 : /usr/bin/python2
• 3.5.2 : /usr/bin/python3

PEP 508-Informationen:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-36-generic',
 'platform_system': 'Linux',
 'platform_version': '#40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

Systemumgebungsvariablen:

• XDG_GREETER_DATA_DIR
• GNOME_DESKTOP_SESSION_ID
• PYTHONDONTWRITEBYTECODE
• LESSOPEN
• XDG_SESSION_TYPE
• QT_IM_MODULE
• LOGNAME
• USER
• PROMPT_COMMAND
• HOME
• XDG_VTNR
• PATH
• PYTHONUNBUFFERED
• DISPLAY
• SSH_AGENT_PID
• LANG
• TERM
• SHELL
• XDG_SESSION_PATH
• QT_STYLE_OVERRIDE
• LANGUAGE
• SESSION_MANAGER
• SHLVL
• QT_LINUX_ACCESSIBILITY_ALWAYS_ON
• GTK_CSD
• QT_ACCESSIBILITY
• XMODIFIERS
• GIO_LAUNCHED_DESKTOP_FILE_PID
• XDG_SESSION_DESKTOP
• GIO_LAUNCHED_DESKTOP_FILE
• XDG_RUNTIME_DIR
• SSH_AUTH_SOCK
• VTE_VERSION
• GDMSESSION
• XDG_SEAT_PATH
• LESSCLOSE
• GSETTINGS_SCHEMA_DIR
• XDG_CURRENT_DESKTOP
• XDG_SESSION_ID
• DBUS_SESSION_BUS_ADDRESS
• _
• XAUTHORITY
• DESKTOP_SESSION
• XDG_CONFIG_DIRS
• GTK_MODULES
• GDM_LANG
• PANTHEON_TERMINAL_ID
• XDG_DATA_DIRS
• PWD
• PIP_PYTHON_PATH
• XDG_MENU_PREFIX
• LS_COLORS
• XDG_SEAT

Pipenv-spezifische Umgebungsvariablen:

Debug-spezifische Umgebungsvariablen:

• PATH : /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
• SHELL : /bin/bash
• LANG : en_US.UTF-8
• PWD : /home/mary

@MarenstainBear In welchem ​​Python installierst du Pipenv? Oder installieren Sie Pipenv in einem anderen Python oder in einer virtuellen Umgebung? (Nicht Ihr Projekt, sondern Pipenv selbst.)

Das Verhalten, das Sie unten erwähnt haben, ist in der Tat merkwürdig, aber Pipenv führt eine Menge Umgebungserkennung durch und ist dafür bekannt, dass es in einer falsch konfigurierten Shell seltsam funktioniert. Ich würde es nicht zu tief lesen; es erstickt wahrscheinlich an etwas anderem.

@roddds resolver.py nimmt die Abhängigkeiten, die es auflösen möchte, als Umgebungsvariable. Ohne die Einstellung $PIPENV_PACKAGES vor der Ausführung würde es nur eine leere Liste auflösen – blitzschnell, wie es sein sollte, weil es nichts aufzulösen gibt.

Versuchen Sie zuerst, PIPENV_PACKAGES einzustellen (das Format ähnelt requirements.txt ) und sehen Sie, was passiert.

+1 Ich sehe das gleiche Problem beim Versuch, numpy unter MacOS zu installieren. Bestätigt Ich sehe dieses Problem bei der Installation von boto3 nicht.

% uname -a
Darwin f45c898a1d21.ant.amazon.com 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64

@uranusjr das bekomme ich, wenn ich PIPENV_PACKAGES mit demselben Wert überprüfe, der in venv_resolve_deps gesetzt wurde:

 $ PIPENV_PACKAGES=='django -i https://pypi.python.org/simple\ngraphene -i https://pypi.python.org/simple\ngraphene-django -i https://pypi.python.org/ simple\npsycopg2 -i https://pypi.python.org/simple\npsycopg2-binary -i https://pypi.python.org/simple\nipython -i https://pypi.python.org/simple\ndjango -manifold==0.1.6 -i https://pypi.python.org/simple\nscipy -i https://pypi.python.org/simple\npython-dateutil -i https://pypi.python.org /simple\ndjango-extensions -i https://pypi.python.org/simple' python /home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv /resolver.py

 Traceback (letzter Aufruf zuletzt):
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py“, Zeile 92, in __init__
 req = REQUIREMENT.parseString(requirement_string)
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1617, in parseString
 erhöhen exkl
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1607, in parseString
 loc, tokens = self._parse( instring, 0 )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1379, in _parseNoCache
 loc,tokens = self.parseImpl( instring, preloc, doActions )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 3376, in parseImpl
 loc, exprtokens = e._parse( instring, loc, doActions )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1379, in _parseNoCache
 loc,tokens = self.parseImpl( instring, preloc, doActions )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 3698, in parseImpl
 return self.expr._parse( instring, loc, doActions, callPreParse=False )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1379, in _parseNoCache
 loc,tokens = self.parseImpl( instring, preloc, doActions )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 3359, in parseImpl
 loc, resultlist = self.exprs[0]._parse( instring, loc, doActions, callPreParse=False )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 1383, in _parseNoCache
 loc,tokens = self.parseImpl( instring, preloc, doActions )
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py“, Zeile 2670, in parseImpl
 Erhöhen Sie ParseException(instring, loc, self.errmsg, self)
 pip9._vendor.pyparsing.ParseException: Erwartetes W:(abcd...) (bei Zeichen 0), (Zeile:1, Spalte:1)

 Während der Behandlung der obigen Ausnahme ist eine weitere Ausnahme aufgetreten:

 Traceback (letzter Aufruf zuletzt):
 Datei "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", Zeile 82, in __init__
 req = Anforderung (req)
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py“, Zeile 96, in __init__
 Anforderungszeichenfolge[e.loc:e.loc + 8]))
 pip9._vendor.packaging.requirements.InvalidRequirement: Ungültige Anforderung, Analysefehler bei "'=django'"

 Während der Behandlung der obigen Ausnahme ist eine weitere Ausnahme aufgetreten:

 Traceback (letzter Aufruf zuletzt):
 Datei "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", Zeile 83, in
 hauptsächlich()
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py“, Zeile 71, in main
 clear=do_clear,
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py“, Zeile 63, in Auflösung
 ausführlich = ausführlich,
 Datei „/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py“, Zeile 426, in resolve_deps
 Vor,
 Datei „/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py“, Zeile 294, in actual_resolve_reps
 c für c in req.parse_requirements(t, session=pip_requests)
 Datei "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", Zeile 294, in
 c für c in req.parse_requirements(t, session=pip_requests)
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py“, Zeile 93, in parse_requirements
 für req in req_iter:
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py“, Zeile 158, in process_line
 isolated=isoliert, options=req_options, wheel_cache=wheel_cache
 Datei „/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py“, Zeile 235, in from_line
 wheel_cache=Rad_Cache, Einschränkung=Einschränkung)
 Datei "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", Zeile 91, in __init__
 "Ungültige Anforderung: '%s'\n%s" % (req, add_msg))
 pip9.exceptions.InstallationError: Ungültige Anforderung: '=django'
 = ist kein gültiger Operator. Meinten Sie == ?

 [[Quelle]]
 url = "https://pypi.python.org/simple"
 verify_ssl = wahr
 name = "pypi"

 [Pakete]
 django = "*"
 graphen = "*"
 graphene-django = "*"
 "psycopg2" = "*"
 "psycopg2-binary" = "*"
 ipython = "*"
 django-manifold = "==0.1.6"
 scipy = "*"
 python-dateutil = "*"
 django-extensions = "*"

 [dev-Pakete]

 [erfordert]
 python_version = "3.6"

@roddds Du hast ein überflüssiges = in der Umgebung. Es ist

$ PIPENV_PACKAGES='django -i [too long, snipped]

Aber du hattest

$ PIPENV_PACKAGES=='django ...

Das zweite = wurde danach mit django kombiniert, was zu dem Syntaxfehler führte, den Sie gesehen haben.

Ich dachte, ich sehe das gleiche Problem bei einer Neuinstallation eines Mac (macOS 10.12, Homebrew Python 3) und fand mehrere Probleme im Zusammenhang hier.

Es ist eine kräftige Maschine, ich habe einen guten Internetzugang – keine Ahnung, warum es so lange dauert, aber am Ende war das Lockfile nach etwa drei Minuten geschrieben.

Hier gilt das gleiche. Jedes Mal, wenn ich pipenv install xxx starte, dauert es sehr lange (2-3 Minuten), direkt nachdem es Locking [packages] dependencies… gedruckt hat

Das Abschließen dauert einfach lange, Leute. Aufgrund des Python-Abhängigkeitsmanagements müssen wir jedes Paket herunterladen und setup.py ausführen, um die erforderlichen Abhängigkeiten zu erhalten. Bei Bibliotheken wie tensorflow und numpy landen Sie möglicherweise bei einem sdist, was bedeutet, dass Sie aus der Quelle erstellen. Das ist langsam. Ich habe gesehen, dass es 10 Minuten dauert. Es geht schneller, wenn Sie den Cache aufheizen.

Ich werde dieses Thema vorerst schließen, bis mir jemand tatsächlich zeigen kann, dass sein Prozess hängen bleibt oder nichts tut. Wir überlegen, wie wir diesen Prozess verbessern können

Wäre es möglich, das Paket anzuzeigen, das derzeit gesperrt ist? Ich denke, das würde zumindest dazu beitragen, dass die Leute nicht denken, dass Pipenv hängt.

Wir überlegen, wie wir diesen Prozess verbessern können

Ich würde vorschlagen, eine Nachricht auszudrucken, die den Benutzer darüber informiert, dass $something ausgeführt wird, was „ein paar Minuten dauern“ kann. Im Moment sieht es so aus, als würde der Prozess hängen bleiben, was meiner Meinung nach die Leute dazu bringt, Fehlerberichte oder +1 zu diesen (Nicht-)Problemen einzureichen.

@slhck Mich würde interessieren, warum das so lange dauern muss. Welche Art von Arbeit muss pipenv in diesem Zeitraum erledigen?

@anowlcalledjosh Ich mag diesen Vorschlag und habe mich wahrscheinlich gefragt, was selbst gesperrt wurde. Ich bin mir nicht sicher, warum wir nie daran gedacht haben, es zu drucken.

@Victor-Savu wie ich schon erwähnt habe. so etwas wie numpy oder tensorflow kompilieren.

@techalchemy Mein Prozess hängt, soweit ich das beurteilen kann, tatsächlich. Ich habe es fünf Stunden lang gehen lassen, bevor ich es getötet habe. Wenn ich mir top , sehe ich keinen Hinweis darauf, dass tatsächlich etwas verarbeitet wird. Wenn ich dagegen Tensorflow in meiner virtuellen Umgebung mit Pip anstelle von Pipenv installiere, dauert es nur wenige Sekunden.

Wie Sie in dieser Aufnahme meines Terminals sehen können, hat mein System 12,25 Sekunden gebraucht, um eine neue python3 virtualenv hochzufahren und pip zu verwenden, um Tensorflow mit dem Befehl /usr/bin/time -v pipenv run pip install tensorflow zu installieren.

Wenn ich stattdessen den Befehl /usr/bin/time -v pipenv install tensorflow ausführe, scheint der Prozess auf unbestimmte Zeit bei "Locking [packages] abhängigkeiten..." zu hängen, nachdem die Installation bereits erfolgreich war.

Sie können aus diesem Bild ersehen, dass nach etwa 59 Sekunden, in denen etwas aktiv ausgeführt wurde, der Unterprozess mit Bezug auf resolver.py aufhört, aktiv Systemressourcen zu verwenden, und, soweit ich das beurteilen kann, niemals abgeschlossen wird. Als ich diesen Screenshot gemacht habe, lief der Prozess seit 16 Minuten.

@MarenstainBear Pipenv erzeugt einen Unterprozess innerhalb der virtuellen Umgebung, um das Sperren durchzuführen. Könnten Sie überprüfen, ob der Unterprozess (der virtualenv python , der pipenv/resolver.py ausführt, ausgeführt wird, wenn Pipenv hängen bleibt? Ich frage mich, ob er im Resolver hängen bleibt, nachdem der Resolver zurückkehrt oder während delegator.run …

(Noch idealer können Sie versuchen herauszufinden, ob der Resolver sein Ende erreicht)

@uranusjr Ich habe einige Schreibanweisungen in den Code resolver.py eingefügt und scheint irgendwo im pipenv.utils.resolve_deps -Aufruf an dieser Zeile zu hängen.

Mit anderen Worten, resolver.py scheint sein Ende nicht zu erreichen.

@MarenstainBear Das ist gut (?) zu hören, zumindest bedeutet es, dass es debuggbar ist. Wie weit hat es geschafft, in resolve_deps ? Es ist eine ziemlich lange Funktion…

Ja und wie lange lief es? Für mich klingt das immer noch wie das, was ich zuvor gesagt habe – das Auflösen des Abhängigkeitsgraphen, der langsam ist

@techalchemy @uranusjr Ich werde mich dieses Wochenende mit den Vorgängen in der resolve_deps-Funktion befassen. In der Zwischenzeit sind hier die Ergebnisse des Prozesses, den ich gestern gestartet habe. Nach 24 Stunden war es nicht behoben und es hat wirklich keine Systemressourcen verwendet, also denke ich, dass es nicht versucht hat, Abhängigkeiten aufzulösen, sondern einfach hängen geblieben ist. (Ich habe den Prozess beendet, um die Ausgabe des Befehls time zu sehen.)

Befehl wurde mit Nicht-Null-Status 1 beendet
Zeitgesteuerter Befehl: „pipenv install tensorflow“
Benutzerzeit (Sekunden): 13.63
Systemzeit (Sekunden): 1,99
Prozentsatz der CPU, die dieser Job erhalten hat: 0 %
Verstrichene Zeit (Wanduhr) (h:mm:ss oder m:ss): 25:45:02
Durchschnittliche freigegebene Textgröße (KB): 0
Durchschnittliche nicht freigegebene Datengröße (KB): 0
Durchschnittliche Stapelgröße (KB): 0
Durchschnittliche Gesamtgröße (KB): 0
Maximale residente Satzgröße (KB): 297772
Durchschnittliche residente Satzgröße (KB): 0
Größere (E/A-erfordernde) Seitenfehler: 0
Kleinere Seitenfehler (Rückgewinnung eines Frames): 467309
Freiwillige Kontextwechsel: 15781
Unfreiwillige Kontextwechsel: 207
Wechsel: 0
Dateisystemeingaben: 0
Dateisystemausgaben: 1654976
Gesendete Socket-Nachrichten: 0
Empfangene Socket-Nachrichten: 0
Gelieferte Signale: 0
Seitengröße (Byte): 4096
Austrittsstatus: 1

@techalchemy was bedeutet "den Cache aufheizen"?

@MarenstainBear danke, dass du das alles gemacht hast. Dein Problem ist definitiv ein Bug. Andere in dem Thread bin ich noch nicht überzeugt. Können Sie vom Master installieren und sehen, ob wir das behoben haben?

@techalchemy Ich habe vom Master bei Commit 8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d (vom Sa. 31. März 01:13:26 2018 -0400) installiert. Mein Problem wurde _nicht_ gelöst. Ich habe hier in Version 11.9.1 das gleiche Verhalten gesehen wie in 11.9.0.

Ich habe kurz versucht, dieses Problem mit strace auf andere Weise zu debuggen. Der Befehl strace pipenv install tensorflow hing bei poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) . Als ich diese Dateideskriptoren nachschlug, passierte nicht viel Interessantes, außer der Bestätigung, dass das System auf I/O wartet.

mary<strong i="10">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428937     
pipenv     8474                  mary    5r     FIFO               0,12       0t0    1428937 pipe
sh         8543                  mary    1w     FIFO               0,12       0t0    1428937 pipe
python     8544                  mary    1w     FIFO               0,12       0t0    1428937 pipe

mary<strong i="11">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428938
pipenv     8474                  mary    7r     FIFO               0,12       0t0    1428938 pipe
sh         8543                  mary    2w     FIFO               0,12       0t0    1428938 pipe
python     8544                  mary    2w     FIFO               0,12       0t0    1428938 pipe

Nebenbemerkung - Es würde wirklich helfen, wenn wir die Ausgabe irgendwie streamen könnten
Resolver, anstatt zu blockieren, bis der Resolver zurückkehrt (nur um es zu schaffen
einfacher zu verwenden, um ausführlich zu debuggen, wo ein Hängen auftritt)
Am Sonntag, 1. April 2018 um 17:21 Uhr MarenstainBear [email protected]
schrieb:

Ich habe vom Master bei Commit 8a67a21 installiert
https://github.com/pypa/pipenv/commit/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d
(vom Sa. 31. März 01:13:26 2018 -0400). Mein Problem wurde nicht gelöst. ich
sah hier in Version 11.9.1 das gleiche Verhalten wie in 11.9.0.

Ich habe kurz versucht, dieses Problem mit strace auf andere Weise zu debuggen. Der
Befehl strace pipenv install tensorflow hing at poll([{fd=5,
events=POLLIN}, {fd=7, events=POLLIN}], 2, -1). Als ich die nachgeschaut habe
Dateideskriptoren, es gab nicht viel Interessantes, außer
Bestätigung, dass das System auf E/A wartet.

mary@marvel :/proc/8471/fd

lsof -n -P | grep 1428937
pipenv 8474 Mary 5r FIFO 0,12 0t0 1428937 Rohr
sh 8543 mary 1w FIFO 0,12 0t0 1428937 rohr
Python 8544 Mary 1w FIFO 0,12 0t0 1428937 Rohr

mary@marvel :/proc/8471/fd

lsof -n -P | grep 1428938
pipenv 8474 Mary 7r FIFO 0,12 0t0 1428938 Rohr
sh 8543 mary 2w FIFO 0,12 0t0 1428938 rohr
Python 8544 Mary 2w FIFO 0,12 0t0 1428938 Rohr

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pipenv/issues/1816#issuecomment-377828171 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABhjq95pb8cZ7BbzrjPxBq3SLeirzFehks5tkW8KgaJpZM4S0kt-
.

Ich habe das gleiche Problem. In der Vergangenheit hing es auf unbestimmte Zeit, aber das letzte Mal endete es aus irgendeinem Grund mit einer Ausnahme. Vielleicht hilft das. (Version ist 11.9.0)

❯ pipenv install Pipfile.lock not found, creating… Locking [dev-packages] dependencies… Locking [packages] dependencies… y", line 63, in resolve verbose=verbose, File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 494, in resolve_deps list(resolver.resolve_hashes([result]).items())[0][1] File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in resolve_hashes return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in <dictcomp> return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in get_hashes for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in <setcomp> for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in _get_file_hash for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in <lambda> for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 324, in read flush_decoder = True File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 237, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') pip9._vendor.requests.packages.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443): Read timed out.

@MarenstainBear Danke, dass Sie sich so viel Mühe gegeben haben, dieses Problem zu beheben.

Nachdem die Installation der aktuellen Version des tensorflow-gpu-Pakets viele Male auf die gleiche Weise fehlgeschlagen ist, habe ich es geschafft, die Installation abzuschließen, indem ich es an Version 1.5 angeheftet habe

pipenv install tensorflow-gpu==1.5

Auch wenn es die Installationsfehler von NumPy und anderen Paketen nicht erklärt, könnte es etwas damit zu tun haben, dass die Tensorflow-Binärdateien seit Version 1.6 AVX-Anweisungen verwenden. In jedem Fall installiert sich Version 1.5 sehr schnell und funktioniert einwandfrei.

@paraschas Ich habe deinen Tipp ausprobiert, und leider hat es nicht funktioniert. Danke aber, dass du etwas vorgeschlagen hast! :-)

@MarenstainBear Dies könnte leicht darauf zurückzuführen sein, dass pipenv Dateideskriptoren irgendwo entlang der Kette verliert und dann auf sie wartet ... Während der Installation geben wir normalerweise eine Reihe von Unterprozessen ab, um gleichzeitige Downloads und dergleichen zu verarbeiten. Was passiert, wenn Sie pipenv install --sequential verwenden? Danke, dass Sie mit uns mithalten. Schauen Sie gerne in unserem Slack-Kanal vorbei (Link ist https://pyslackers.com/ => melden Sie sich an und treten Sie #pipenv bei), wenn Sie mehr Zeug in Echtzeit herumschleudern möchten

@techalchemy Soweit ich das beurteilen kann, verlässt es diesen Versuchsblock nie, wenn es hängt:
@ techttps://github.com/pypa/pipenv/blob/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d/pipenv/utils.py#L491 -L494

Dieser Code ruft in resolver.py zurück, also werde ich sehen, was dort drüben in der Methode resolve_hashes() passiert.

PS - Ich bin dem Slack Channel beigetreten. Danke für die Einladung!

Ich stehe hier vor dem gleichen Problem. Python 3.6.4, Pipenv 11.9.0.
Es hängt nicht, wenn ich mit --skip-lock installiere.

@techalchemy @uranusjr

Ich konnte ipdb verwenden, um mein Problem erheblich einzugrenzen ...

Aus dem ursprünglichen pypi.py-Code hier , wenn ich zwei Zeilen hinzufüge, wie unten gezeigt, dann ist mein pipenv nicht mehr defekt .

1. Die erste Zeile alt_session = PipSession() erstellt ein Vanilla-PipSession-Objekt
2. Und die zweite Zeile self.session.adapters["https://"] = alt_session.adapters["https://"] greift den https-Adapter aus dieser Vanilla-Sitzung und überschreibt den https-Adapter des PyPIRepository. Dies bedeutet, dass von pip9._vendor.cachecontrol.adapter.CacheControlAdapter statt pip9._vendor.requests.adapters.HTTPAdapter stattdessen pip9._vendor.requests.adapters.HTTPAdapter verwendet wird.

def _get_file_hash(self, location):
    h = hashlib.new(FAVORITE_HASH)
    alt_session = PipSession()
    self.session.adapters["https://"] = alt_session.adapters["https://"]
    with open_local_or_remote_file(location, self.session) as fp:
        for chunk in iter(lambda: fp.read(8096), b""):
            h.update(chunk)
    return ":".join([FAVORITE_HASH, h.hexdigest()])

Irgendwelche Ideen, warum das bei mir funktioniert und was das über die Quelle meines Fehlers bedeutet?

Meine Vermutung ist, dass es wahrscheinlich kaputt war, weil es versucht hat, zu viele Dinge gleichzeitig zu holen. Der Wechsel zu einem zwischengespeicherten Adapter reduziert die erforderlichen Anforderungen (weil sie zwischengespeichert werden) und sorgt dafür, dass es funktioniert. Dies ist fast ausschließlich eine Vermutung (ich habe mir die Pip-Interna nicht angesehen und spreche nur aufgrund meiner Erinnerung an die Pip-Quelle). Wenn dies jedoch richtig ist, wäre dies eine sehr schöne Lösung. Möchten Sie den Patch in einen Pull-Request verkleinern?

@uranusjr Es ist eigentlich umgekehrt. Der ursprüngliche Code verwendet den zwischengespeicherten Adapter - der zwischengespeicherte Adapter ist derjenige, der bei mir NICHT funktioniert. Der normale HTTP-Adapter funktioniert, wenn ich ihn stattdessen verwende.

@uranusjr @techalchemy Jetzt, wo ich darüber nachdenke, frage ich mich, ob es irgendwelche beschädigten Daten in meinem Cache gibt. Ich werde prüfen, wie ich meinen (Pip?) ​​Cache löschen kann, um zu sehen, ob das das Problem für mich löst.

Wahrscheinlich, ich weiß es nicht (pip internal ist sehr schwierig). Pips Cache ist standardmäßig bei ~/.cache/pip , aber vielleicht gibt es noch andere Caches. Ich weiß es ehrlich gesagt nicht.

@uranusjr @techalchemy @jtratner

Heilige Eimer, Batman! Es funktionierte!

mary<strong i="10">@marvel</strong>:~
> sudo rm ~/.cache/pip* -rf
[sudo] password for mary: 

mary<strong i="11">@marvel</strong>:~
> mktmpenv 
Using base prefix '/usr'
New python executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python3
Also creating executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/preactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/get_env_details
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-60224356c1829db) 
mary<strong i="12">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> pipenv install protobuf
Creating a Pipfile for this project…
Installing protobuf…
Collecting protobuf
  Downloading protobuf-3.5.2.post1-cp35-cp35m-manylinux1_x86_64.whl (6.4MB)
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf)
Collecting six>=1.9 (from protobuf)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf
Successfully installed protobuf-3.5.2.post1 six-1.11.0

Adding protobuf to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (735738)!
Installing dependencies from Pipfile.lock (735738)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 2/2 — 00:00:00
(tmp-60224356c1829db) 
mary<strong i="13">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> 

Mal sehen, ob diese Lösung für einige der anderen Personen funktioniert, die dasselbe Problem melden.
@roddds @jlhood @roveo @claytonaalves Wenn Sie immer noch in der Lage sind, pipenv zu reproduzieren, das auf unbestimmte Zeit bei "Sperren ... [Pakete] Abhängigkeiten" hängt, versuchen Sie, Ihren Pip- (und Pipenv?) Cache bei ~/.cache/.pip zu löschen, und melden Sie sich zurück, ob das das Problem mit dem Hängen von pipenv gelöst hat. :-)

Ihre Eingabeaufforderung lautet also @marvel , aber Sie zitieren Robin … hmm 😏

lol ... also das Löschen Ihres Pip-Cache hat es behoben ... das Leben ist amüsant ...

Ich stoße bei der Installation von Pendel auf das gleiche Problem mit dem neuesten Python, pip und pipenv, und leider löst das Löschen des Caches von pip und pipenv durch Ausführen von `sudo rm ~/.cache/pip* -rf' das Problem nicht.

Also besteht das Problem zumindest bei mir weiterhin.

@paraschas kannst du uns das pipfile und die Ausgabe von python -m pipenv.help geben

Der Inhalt des Pipfiles ist:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]
pandas = "*"
"h5py" = "*"
Keras = "*"
tensorflow-gpu = "==1.5"
sklearn = "*"
pendulum = "*"

[dev-packages]

[requires] = "3.6"

Und die Ausgabe von python -m pipenv.help ist angehängt:

pipenv.help.txt

Alle Ideen zur Umgehung des Problems, auch manuell, werden sehr geschätzt.

Können Sie pipenv-resolver —debug pendulum ausführen

Hier ist es, nicht sicher, warum es fehlschlägt:

pipenv-resolver_pendulum.txt

Beim Debuggen ist es hilfreich, wenn Sie den ausgeführten Befehl nicht ausschneiden, auch weil ich keine Ahnung habe, warum dies fehlschlägt. Ist Ihr Gebietsschema richtig konfiguriert usw.?

Ich habe den Befehl kopiert, den ich jetzt sehe, enthält einen Bindestrich anstelle von zwei Bindestrichen.

Ich habe jetzt pipenv-resolver --debug pendulum ausgeführt, das korrekt ausgeführt wird und die folgenden Ergebnisse liefert:
pipenv-resolver_pendulum.txt

Tut mir leid, dass ich viele Sachen auf dem Handy prüfe und es automatisch in Em-Bindestriche konvertiert. Dies deutet also auf ein Installationsproblem hin. Welche Version landet in Ihrem Lockfile? Kannst du diese Version von Pendel direkt pip install ?

Keine Sorge, ich sehe, dass Sie viel Mühe in dieses Projekt stecken.

Ich habe es geschafft, Pendel mit pipenv zu installieren, aber die Generierung der Sperrdatei zu überspringen. Nach einem Tag und einem Neustart wurde auch die Sperrdatei korrekt generiert, und die Pendelversion ist "==1.5.1".

Das Schlimme ist, dass es bisher keine Möglichkeit gibt, dieses Problem zu reproduzieren, was die Behebung erschwert, aber hoffentlich wird sich etwas ergeben.

Die nächste Version sollte dabei ein wenig helfen. Sollte in ein paar Stunden da sein.

Ich hatte das gleiche Problem bei der Installation von Pandas. Da ich Probleme mit Pandas und der neuesten Version von pip hatte, entschied ich mich für ein Downgrade von pip auf 9.0.3 und das Problem mit pipenv wurde ebenfalls gelöst.
Überprüfen Sie dieses Problem als Referenz: https://github.com/pandas-dev/pandas/issues/20666

pipenv installiere scheiße
hängt länger als 10 min

python --version
3.6.5
pip --Version
10.0.1

Katze Pipfile

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
scrapy = "*"

[dev-packages]

[requires]
python_version = "3.6"

Ich hatte das gleiche Problem. Hier hing es bei mir:

$ pipenv lock -vv
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…

$ pipenv-resolver --debug requests
DEBUG:pip9.vcs:Registered VCS backend: git
DEBUG:pip9.vcs:Registered VCS backend: hg
DEBUG:pip9.vcs:Registered VCS backend: svn
DEBUG:pip9.vcs:Registered VCS backend: bzr
DEBUG:notpip.index:2 location(s) to search for versions of requests:
DEBUG:notpip.index:* https://pypi.python.org/simple/requests/
DEBUG:notpip.index:* https://pypi.boughtbymany.com/5c0a44cd-ec93-412c-b3a9-c3dfb72c22ee/requests/
DEBUG:notpip.index:Getting page https://pypi.python.org/simple/requests/
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.python.org/simple/requests/" in the cache
DEBUG:pip9._vendor.cachecontrol.controller:Returning cached "301 Moved Permanently" response (ignoring date and etag information)
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.org/simple/requests/" in the cache
WARNING:pip9._vendor.cachecontrol.controller:Cache entry deserialization failed, entry ignored
DEBUG:pip9._vendor.urllib3.connectionpool:Starting new HTTPS connection (1): pypi.org
DEBUG:pip9._vendor.urllib3.connectionpool:https://pypi.org:443 "GET /simple/requests/ HTTP/1.1" 200 16346
DEBUG:pip9._vendor.cachecontrol.controller:Updating cache with response from "https://pypi.org/simple/requests/"
DEBUG:pip9._vendor.cachecontrol.controller:Caching due to etag

Das Problem hatte etwas damit zu tun, dass pip versuchte, etwas in seinen Cache zu schreiben. Ich konnte es lösen, indem ich meinen Pip-Cache löschte - was für Mac-Benutzer rm -rf ~/Library/Caches/pip ist.

Danke an alle Mitwirkenden an dieser Ausgabe!

Das Löschen des Caches pip hat bei mir auch funktioniert! Vielen Dank an @MarenstainBear @uranusjr @techalchemy @jtratner für deine Arbeit!

Das gleiche Zeug hier, pip env hängt an Mac OS. Ich habe versucht, nur zu Testzwecken ein einfaches pipenv install flask in einem neuen Ordner zu erstellen. Es hing, aber ich bemerkte, dass es nicht Pips Cache-Verzeichnis verwendete, sondern sein eigenes:

Building wheels for collected packages: itsdangerous, MarkupSafe
  Running setup.py bdist_wheel for itsdangerous: started
  Running setup.py bdist_wheel for itsdangerous: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/2c/4a/61/5599631c1554768c6290b08c02c72d7317910374ca602ff1e5
  Running setup.py bdist_wheel for MarkupSafe: started
  Running setup.py bdist_wheel for MarkupSafe: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/33/56/20/ebe49a5c612fffe1c5a632146b16596f9e64676768661e4e46

Also, was für mich funktionierte, war

rm -rf ~/Library/Caches/pipenv

Wirklich merkwürdiges Verhalten. Dieses Verhalten wurde nach dem Upgrade von Python von 3.6.3 auf 3.7.0 gefunden

pipenv --clear übernimmt das für Sie

Fehler: keine solche Option: --clear

Führen Sie zunächst ein Upgrade auf die neueste Version durch.

bearbeiten, es sei denn, dies ist nicht freigegeben und befindet sich nur im Master. Warten Sie in diesem Fall, bis ich wahrscheinlich diese Woche eine Veröffentlichung herausschneide, oder verwenden Sie die in Master verfügbare Version: D kann mich nicht erinnern, ob dies tatsächlich den Schnitt gemacht hat ...

@techalchemie
Es ist definitiv noch nicht veröffentlicht, da ich die neueste Version 2018.7.1 habe und ich auch keine Option --clear habe

Für dieses spezielle Problem sollte pipenv lock --clear ausreichen.

pipenv lock --clear funktioniert. Danke!

Arbeite immer noch NICHT für mich für pipenv lock --clear

macOS HighSierra 10.13.6
Python: Python 3.6.4
pipenv: Version 2018.7.1

Ich hoffe, dass dieser Locking [packages] dependencies... Hänger für immer so schnell wie möglich behoben wird

@crifan Ich habe festgestellt, dass es einen Fehler gibt, der die Arbeit von pipenv lock --clear verhindert (https://github.com/pypa/pipenv/issues/2628).

Versuchen Sie, Ihre Caches manuell zu löschen - ich verwende rm -r ~/Library/Caches/pip* .

Passiert in dieser alpinen Linux-basierten Dockerfile (Kind davon ):

FROM frolvlad/alpine-python3

RUN pip install pipenv

COPY ./app /app
COPY Pipfile /app/
WORKDIR /app

RUN pipenv install

Mit diesem Pipfile:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[dev-packages]

[packages]
numpy = "*"
pandas = "*"
tensorflow = "*"
flask = "*"

[requires]
python_version = "3.6"

~/devel/dopper:fixes: pipenv lock --clear --verbose
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

hängt für immer.

Pipfile:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
proto = {editable = true, path = "."}
halt = {editable = true, path = "/home/carlos/devel/halt"}
gcd = {editable = true, path = "/home/carlos/devel/gcd"}

[dev-packages]

[requires]
python_version = "3.6"

Sperrdateien, die nur Daten enthalten, die sich auf Ihrem lokalen Computer befinden, sind genauso wenig hilfreich wie keine Informationen bereitzustellen. Wenn Sie keine neuen Debugging-Informationen oder etwas Neues anbieten, das wir übernehmen und reproduzieren können, achten Sie bitte auf das Rauschen der Problemverfolgung.

Das sind einfache Abhängigkeitsprojekte, die ich einfach manuell installieren kann, indem ich pip install -e . auf jedem ausführe, aber das Ausführen pipenv install -e . im Hauptprojekt hängt auf unbestimmte Zeit, also habe ich dieses Problem herausgefunden und pipenv lock --clear ausprobiert --verbose -Modus hier tatsächlich ausführlich wäre.

Vielleicht könnte das etwas Licht ins Dunkel bringen:

~/devel/dopper:fixes: pipenv --rm
Removing virtualenv (/home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s)...
~/devel/dopper:fixes: rm -rf Pipfile 
~/devel/dopper:fixes: pipenv --three
Creating a virtualenv for this project...
Pipfile: /home/carlos/devel/dopper/Pipfile
Using /usr/bin/python3 (3.6.6) to create virtualenv...
⠋Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python3
Also creating executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python
Installing setuptools, pip, wheel...done.
Setting project for dopper-0v9QQl0s to /home/carlos/devel/dopper

Virtualenv location: /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s
Creating a Pipfile for this project...
~/devel/dopper:fixes: pipenv install numpy
Installing numpy...
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Für immer warten...

Angenommen, es handelt sich um ein Netzwerkproblem. Warum funktioniert das dann? :

~:: pip install --force --upgrade --user numpy
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl (13.9MB)
    100% |████████████████████████████████| 13.9MB 386kB/s 
Installing collected packages: numpy
  Found existing installation: numpy 1.15.0
    Uninstalling numpy-1.15.0:
      Successfully uninstalled numpy-1.15.0
Successfully installed numpy-1.15.0

Nach vielen Versuchen (Abhängigkeiten einzeln installieren, lokale Abhängigkeiten vermeiden, bearbeitbare Abhängigkeiten vermeiden, Installation mit Sperre überspringen und dann sperren usw.) konnte ich kein Muster finden. Manchmal funktioniert es in vernünftiger Zeit, manchmal bricht es nach ein paar Minuten mit einem Timeout-Fehler ab, manchmal hängt es "für immer" (was von meiner nachlassenden Geduld abhängt). Ich nehme an, mein Problem hängt mit den vielen Problemen zusammen, die eine Variante von "Sperren ist zu langsam" melden.

Auch hier hören Sie bitte auf, zufällige Vermutungen anzustellen und zufällige Ausschnitte Ihrer Ausgabe zu posten. Wenn Sie Hilfe bei einem bestimmten Problem benötigen, füllen Sie ein Problem mit der gesamten Problemvorlage aus. Wir gehen in dieser Ausgabe mit niemandem auf eine wilde Gänsejagd, während sie selektiv Ausgaben posten, die größtenteils nichts mit pipenv zu tun haben. Wir haben gesehen, wie der Bildschirm aussieht, wenn er hängt. Das an uns zu kleben ist nicht sinnvoll.

Ok, wenn Sie denken, dass die Installation von numpy in einer sauberen Umgebung a
Zufälliges Problem Ich weiß, dass ich bei der Verwendung von pipenv mein Risiko eingehe, danke dafür
die Köpfe hoch und ich werde meinen Mund halten.

Am Mittwoch, den 25. Juli 2018 um 18:27 Uhr schrieb Dan Ryan [email protected] :

Auch hier hören Sie bitte auf, zufällige Vermutungen anzustellen und zufällige Ausschnitte zu posten
Ihre Ausgabe. Wenn Sie Hilfe bei einem bestimmten Problem benötigen, füllen Sie ein Problem aus
mit der gesamten Ausgabevorlage. Wir gehen nicht auf eine wilde Gänsejagd mit
jeder in dieser Ausgabe, während sie selektiv die Ausgabe posten, die meistens ist
nichts mit pipenv zu tun. Wir haben gesehen, wie der Bildschirm aussieht, wenn er hängt.
Das an uns zu kleben ist nicht sinnvoll.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pipenv/issues/1816#issuecomment-407901419 , oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACtq-WfYHCgtRnbIu_yljQV7m0JvwxA7ks5uKOKqgaJpZM4S0kt-
.

@memeplex es geht nicht darum, dass es sich um ein zufälliges Problem handelt, sondern darum, dass die Ausgabe für die Fehlerbehebung nicht hilfreich ist. An keiner Stelle habe ich Ihr Problem zufällig genannt – ich habe Ihnen ausdrücklich gesagt, was Sie tun können, wenn Sie an einem produktiven Gespräch über das Problem interessiert sind, mit dem Sie konfrontiert sind, da es unmöglich ist, ein System mit ausgewählten Terminalfragmenten zu beheben oder zu diagnostizieren Ausgabe, die nur Nachrichten enthält, die wir selbst geschrieben haben, und die eigentlich keine Fehler oder eine Möglichkeit für uns enthalten, sie zu reproduzieren.

Bisher wissen wir:

1. Nichts über deine Umgebung
2. Nichts über die zusätzlichen Umstände Ihres Systems
3. Die übertriebene Behauptung, dass Sie "ewig gewartet" haben, aber ohne zusätzliche Informationen darüber, ob der Prozess etwas getan hat, ob eine Umgebung mit irgendetwas darin existierte, welche Version von pipenv Sie ausführen, ob dies mit anderen Dingen als numpy passiert, wie Sie installiert haben Python, wie Ihre Hardware ist, wie Ihre Systemkonfiguration ist, ich könnte weitermachen.

Wir selektieren eine beträchtliche Anzahl von Problemen, weshalb wir Problemvorlagen verwenden, um diese Informationen schnell zu sammeln und zu beurteilen, was passieren könnte. Wenn Leute einfach '[locking]...' einfügen und uns sagen 'das dauert ewig', fühlen wir mit Ihnen, aber es ist eine Art früher Hinweis darauf, dass Sie eigentlich nicht hier sind, um produktiv zu sein. Ich versuche, im Zweifelsfall zu entscheiden und die Leute dazu zu drängen, ein Problem mit der Problemvorlage und einem reproduzierbaren Testfall zu melden, aber wenn Sie dies nicht tun können, kann ich nur davon ausgehen, dass Ihre Absicht nicht darin bestand, Fehler zu beheben, sondern nur Sie wollte negativ sein. Das ist im Issue Tracker nicht wirklich erwünscht, es gibt viele andere Orte, an denen Sie das tun können.

Dieser Tracker wird zum Identifizieren und Lösen von Problemen mit der Codebasis verwendet, nicht zum Anhäufen, wenn Sie etwas sehen, das Sie erlebt haben. Die Regel ist im Wesentlichen, dass Sie wahrscheinlich davon absehen sollten, etwas zu posten, wenn Sie nichts beitragen können oder wollen, außer etwas zu wiederholen und uns mitzuteilen, dass wir es umgehend beheben müssen. Wir sind ehrenamtlich tätig und tun dies in unserer Freizeit; Wenn Sie zum Tracker kommen, bitten Sie uns direkt, unsere Zeit für Sie zu verwenden. Normalerweise sind wir dazu in der Lage, aber wir bitten Sie im Gegenzug, unseren Prozess zu befolgen, um uns bei der effizienten Sichtung zu unterstützen.

Ich möchte diese Diskussion wirklich nicht fortsetzen, weil die anderen Leute den Thread abonniert haben, ich werde diese beantworten und dann haben Sie das letzte Wort, wenn Sie dies wünschen. Ich habe einige anekdotische Beweise gepostet, ich habe sofort erkannt, dass es nicht mehr als das war, und versucht, die bedingtsten Aspekte zu eliminieren, indem ich die lokalen Abhängigkeiten auf andere Weise installiert und überprüft habe, ob es keine Probleme damit gibt, und schließlich alle Abhängigkeiten vollständig entfernt habe env von Grund auf neu und installiere nur numpy. Diese Schritte (Erstellen einer env und Installieren von numpy) sind reproduzierbar, es tut mir aufrichtig leid, dass ich Ihnen keine nützlicheren Informationen geben kann, da ich selbst kein Muster finden kann, wie ich bei der Auflistung meiner Versuche bemerkt habe (und ich kann es auch nicht hänge eine iso meines gesamten setups an). So schlug ich am Ende eine Beziehung mit einer Reihe allzu ähnlicher Probleme vor, die gemeldet und geschlossen wurden, indem ich erkannte, dass mein erster Eindruck falsch war. Ich verstehe, dass reproduzierbar besser ist, aber ich kann nicht einmal eine ausführliche Ausgabe posten, da der Befehl nur die minimale Ausgabe zeigt, die ich (selektiv oder zufällig oder was auch immer) gepostet habe. Am Anfang dachte ich, mein Problem könnte mit diesem Problem zusammenhängen, und nach meinen erfolglosen Versuchen, ein Muster zu finden, bin ich jetzt eher geneigt zu glauben, dass es auf der Seite "Sperren ist zu langsam" liegt. Der Grund, warum ich kein neues Thema erstellt habe, ist, dass viele von ihnen aus demselben Grund geschlossen wurden, aus dem Sie sicherlich meins geschlossen hätten, wenn ich es gepostet hätte. Nun, ich denke, das ist ein wichtiges Problem, ich kann ein beliebtes Paket nicht konsequent in einem größtenteils standardmäßigen Setup installieren, es geht nicht darum, dass die Schlangen-Emoji-Schriftart auf meinem neuen Hipster-Terminalemulator nicht funktioniert, und obwohl ich Ihre Position verstehe , ich kann das Gefühl nicht unterdrücken, dass du ein bisschen zu hart warst. Trotzdem weiß ich Ihre ausführliche Erklärung nach meinem letzten, schlecht gelaunten Kommentar sehr zu schätzen. Übrigens, die Behauptung, dass ich „ewig gewartet“ habe, abgesehen davon, dass es eine Redewendung ist, wurde tatsächlich von mir ironisch abgemildert, indem ich ewig als die Grenze meiner Geduld definierte, aber ich habe dazu beigetragen, dass es über mehrere Minuten hinausgeht ; Da wir hier über etwas sprechen, das höchstens ein paar Sekunden hätte dauern dürfen, ist die einzige Relevanz meiner Ungenauigkeit, dass Sie sie als frühes Symptom meiner schlechten Absichten interpretiert haben, die von Anfang an nicht da waren. Ich entschuldige mich bei allen anderen hier, zumindest bei allen anderen mit der Geduld, bis zu diesem Punkt zu lesen.

Wenn Sie der Meinung sind, dass Sie zu diesem Thema etwas Neues hinzuzufügen haben, erstellen Sie bitte eine neue Ausgabe und füllen Sie die Ausgabevorlage vollständig aus. Wir sind uns der Probleme und ihrer verschiedenen Erscheinungsformen bewusst und haben mehrere Korrekturen in Bearbeitung