Pipenv: Die Aktualisierung der Sperre ist sehr langsam

Wir sind uns bewusst und haben viele Probleme, dieses Thema zu verfolgen. Siehe #1785 #1886 #1891 und PR #1896

npm und Garn haben den Vorteil, dass sie nicht jedes potenzielle Paket vollständig herunterladen und ausführen müssen, um ihren Abhängigkeitsgraphen zu bestimmen, da die Abhängigkeiten im Klartext angegeben werden. Python-Abhängigkeiten erfordern, dass wir die Setup-Dateien jedes Pakets vollständig herunterladen und ausführen, um sie aufzulösen und zu berechnen. Das ist nur die Realität, es ist ein bisschen langsam. Wenn Sie keine 2 Minuten warten können oder der Meinung sind, dass sich der Kompromiss nicht lohnt, können Sie immer --skip-lock passieren.

Schließen, um in den anderen Ausgaben zu verfolgen.

Das gleiche hier, ich probiere es gerade aus und die Installation von Django ist bereits nach 10 Minuten und geht

Es scheint, dass es langsam ist, wenn Sie versuchen, ein paar zu installieren, aber wenn Sie es einzeln tun, funktioniert es etwas schneller

Wenn Sie ein Pipfile bereitstellen können, das das langsame Verhalten reproduziert, wäre dies hilfreich - danke

Python-Abhängigkeiten erfordern, dass wir die Setup-Dateien jedes Pakets vollständig herunterladen und ausführen, um sie aufzulösen und zu berechnen

Ist dies immer noch der Fall, wenn das Paket sein eigenes Pipfile.lock , oder wird pipenv dies nach Möglichkeit verwenden, um Abhängigkeiten zu bestimmen?

wird pipenv das verwenden, wenn möglich, um Abhängigkeiten zu bestimmen?

Nein. Pipenv ist ein Tool zur Auflösung von Anwendungsabhängigkeiten. Wenn eine Abhängigkeit von einer anderen Anwendung als Python-Paket verwendet wird, ist sie keine Anwendung mehr. Seine Abhängigkeiten werden durch setup.py (oder setup.cfg oder was auch immer Sie zum Hochladen auf PyPI verwenden) bestimmt. Das Laden von Abhängigkeiten aus einer Sperrdatei ist ein sicherer Weg in die Abhängigkeitshölle, das werden wir wahrscheinlich nie tun.

Es ist immer noch super langsam

@iddan Danke für die Erinnerung, Captain Obvious!

Tut mir leid, als OSS-Maintainer weiß ich, wie manchmal Probleme aus Altersgründen abgewiesen werden können. Wollte nur sagen, dass selbst das Thema diskutiert wurde, es ist immer noch relevant

@techalchemy Anmerkung von --skip-lock oben ist wunderbar. Dies sollte eine leichter zugängliche oder veröffentlichte Option sein. Kann man das irgendwo als Standard setzen?

@techalchemy Was ist, wenn es mit meinem brandneuen Mac Pro 20 Minuten dauert?

@techalchemy Anmerkung von --skip-lock oben ist wunderbar. Dies sollte eine leichter zugängliche oder veröffentlichte Option sein. Kann man das irgendwo als Standard setzen?

Soweit ich weiß, besteht der überwältigende Vorteil von pipenv darin, dass Abhängigkeiten gut zusammenspielen – nicht nur für Sie, sondern für jeden, der später mit Ihrem Code zu tun hat. Das Produkt dieser Zusicherung, die Lock-Datei, braucht absolut mehr Zeit, als irgendjemand erwartet oder wünscht, _einschließlich der Entwickler_ — siehe #2200.

Ich denke, Sie können jedoch auch die Gelegenheit verstehen, die pipenv hat, um wohlmeinende Entwickler in der Python-Community insgesamt zu einem Workflow zu führen, der zukünftigen Mitwirkenden weniger Kopfzerbrechen auferlegt – die möglicherweise nur Besucher gewesen wären, wenn sie während des " herauszufinden, wie man die Entwicklungsumgebung einrichtet"; und weniger Hände, die von zukünftigen Betreuern hochgeworfen werden – die vielleicht nur Drive-by-PR-Autoren gewesen wären, hätten sie während der Phase des "ernsthaften Herumschraubens mit tiefen Projektinterna" aufgegeben.

Wenn --skip-lock zu einem permanenten Flag in einem Pipfile oder einer Einstellung in einer pipenv-Konfiguration werden würde, würde die Wahrnehmung von pipenv langsam in Richtung "besserer Pip" abgleiten und nur ein weiteres Sprungbrett am Horizont verschwinden, wenn die Community schließlich landete ein weniger kompromissloser spiritueller Nachfolger.

Es ist besser, es nur als env var oder eine andere Methode verfügbar zu lassen, deren Anwendung direkt im Bereich _"Ihre benutzerspezifische lokale Konfiguration, Ihre Schuld"_ liegt, damit pipenv die Übergangsphase der Verlangsamung der Lockfile-Generierung überwinden kann, ohne aufzugeben der wahrhaft vorteilhafte kulturelle Wandel hin zu _Explizitheit über Implizitheit_ in der Paketverwaltung.

Die unglaublich umfangreiche Standardbibliothek von Python ist ein enormer Vorteil, deren Geschichte viele Epochen von imposanter Beständigkeit durchgemacht hat. Dass die meisten Standardpakete gut zusammenspielen, ist eine enorme Leistung, die von vielen Menschen über viele Jahre hinweg bedacht werden muss. Eines Tages wird sich diese Spielbarkeit auf die meisten Python-Projekte ausdehnen, die im Web anzutreffen sind – weit, weit entfernt von der stdlib und mit viel, viel weniger PEPs (_und viel, viel weniger BDFLs, die vor Frustration räumen_). Die Auswirkungen einer solch einseitigen, butterweichen Erfahrung sind schwer zu messen, aber einige aktuelle Sprachen weigerten sich, die konzeptionelle Integrität aus Gründen der unmittelbaren Bequemlichkeit zu beeinträchtigen ... und oh, die Orte, an die sie gehen werden .

Also _ja_, das Generieren der Sperrdatei ist langsam, und _ja_, es ist frustrierend, wenn man nur pip install --save . Aber nur, weil wir seit Jahren einen Elefanten in den Schrank fegen – in dem Glauben, wir hätten kein Durcheinander von Erwartungen und Absichten durch externe Abhängigkeiten, weil _"es auf meiner Maschine gut installiert"_.

Die Generierung von Lockfiles ist _nur_ langsam, weil es explizit macht, was wir alle für selbstverständlich halten. Aber _weil_ es weh tut , werden wir die Dinge so anpassen, dass es nicht so ist. Wir haben uns den Arm gebrochen, weil wir uns selbst dazu gedrängt haben, Dinge zu tun, an die wir geglaubt haben. Sicher, wir können die Schmerzen vermeiden, indem wir diesen Arm nie wieder benutzen – oder wir können ihn während der Heilung in einen Gipsverband legen.

Ich wäre die letzte Person, die Ihnen sagen würde, dass Sie sich Pipenv heute nicht bequem machen sollen (sonst wäre ich ein beschissener Entwickler – _obwohl die Jury noch nicht fertig ist_), aber ich bitte Sie, die Frustration der Lockfile-Generierung als immer größer zu betrachten Schmerzen, während sich die Python-Community zu einem starken, gesunden Körper mit mehr voll funktionsfähigen Gliedmaßen entwickelt, als man beim Entfernen eines Gipsverbandes wirklich erwartet hätte. Wir haben es zu Python 3 geschafft. Kommen wir zum Abhängigkeitsmanagement in der stdlib.

Dies dauerte 38 Minuten auf meinem Computer, um die Sperrdatei zu erstellen. Ausführen von Windows 10 und Verwenden von Python 3.7

Nur Numpy und Kissen waren bereits installiert und es dauerte <1 Sekunden, um Numba zu installieren und 25 Minuten, um es zu sperren. Kompiliert pipenv zwangsweise jede Bibliothek auf Sperre oder wie funktioniert das?

Zu Ihrer Information wartet die dauerhafte Sprungsperre nur darauf, dass jemand den Schalter für auto_envvar_prefix umlegt, was eine Klickeinstellung ist. Ich habe mich zu 100% auf die Kernfunktionalität konzentriert, also hatte ich noch keine Gelegenheit, mir das anzuschauen, aber ich vermute, es ist nicht so schwierig

TLDR; Typischer pipenv install Aufruf: Zeit : 144,82 real 33,68 Benutzer 5,77 sys. Mit --skip-lock : Zeit : 4,54 real 5,33 Benutzer 0,87 sys.

Pandas-datareader-Installation schlägt beim ersten Versuch fehl, möglicherweise ist lock hängen geblieben. Ist dies ein Problem, das jemand mit anderen Paketen sieht?

Verwenden der Version 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Inhalt von requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Typischer pipenv install Aufruf. Zeitgesteuerte Ausführung mit time (BSD).

Ergebnisse : 144,82 real 33,68 Benutzer 5,77 sys

$ time pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Pipfile.lock (0fdb67) out of date, updating to (a65489)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (0fdb67)!
Installing dependencies from Pipfile.lock (0fdb67)…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 15/15 — 00:00:04
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
      144.82 real        33.68 user         5.77 sys

Aufruf von w\ --skip-lock

Ergebnisse : 4,54 real 5,33 Benutzer 0,87 sys

$ time pipenv install -r requirements.txt --skip-lock
Requirements file provided! Importing into Pipfile…
Installing dependencies from Pipfile…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
        4.54 real         5.33 user         0.87 sys

Ich denke, https://github.com/pandas-dev/pandas/ könnte ein Problem sein? Es ist auch ein gemeinsamer Punkt mit der Zeit für mich.

Obwohl pytest auch ein Problem sein kann:\

Es wird nicht einmal auf meinem Computer fertig:

Installing pandas…
Adding pandas to Pipfile's [packages]…
Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 109, in expect_loop
    return self.timeout()
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x00000292ADCCCDD8>
searcher: searcher_re:
    0: re.compile('\n')

@black-snow Ich würde empfehlen, es in einer anderen Shell zu versuchen. Ohne zu tief in die Dinge einzutauchen, scheint es, als würde pexpect (eine Bibliothek für die programmgesteuerte Verbindung mit interaktiven CLI-Programmen) verwendet, um zu erkennen, dass die Shell pipenv ausgeführt wird, und das könnte ins Stocken geraten. pexpect scheint für so etwas übertrieben zu sein, aber ich kenne den gesamten Kontext nicht.

@theY4Kman danke für den Rat. pipenv funktioniert auf einem anderen PC mit derselben Ubuntu- und Bash-Version einwandfrei ...

Lesen Sie dies, während Sie darauf warten, dass pipfile gesperrt wird ... :) Wäre toll, wenn es eine Lösung gäbe.

Es scheint, als ob wir eine Art API brauchen, um Python-Pakete deps zu parsen und zwischenzuspeichern und in einem maschinenfreundlichen Format zu verteilen. Wir müssen also nicht mehr ganze Pakete herunterladen und parsen.

Ich glaube, Bundler und Rubinedelsteine ​​pflegen und verwenden so etwas.

Java hat auch POM-Dateien (XML), die Paketabhängigkeiten und andere Informationen zum Paket enthalten. Sie werden getrennt von den kompilierten JARs hochgeladen.

Jeder neuere Paketmanager hat einige separate Metadateien (npm/yarn, composer, gradle/maven, cargo, ruby ​​gems/bundler, ...).

verwandtes Thema:
https://github.com/pypa/warehouse/issues/474

Sie können Abhängigkeitsinformationen von PyPi abrufen, ohne das gesamte Bundle herunterzuladen (siehe PEP 566, das PEP 426) ersetzt hat.

package_name = 'Django'
PYPI_API_URL = 'https://pypi.python.org/pypi/{package_name}/json'
package_details_url = PYPI_API_URL.format(package_name=package_name)
response = requests.get(package_details_url)
data = json.loads(response.content)
data['info'].get('requires_dist')
data['info'].get('requires')
data['info'].get('setup_requires')
data['info'].get('test_requires')
data['info'].get('install_requires')

@techalchemy hast du den Kommentar oben gesehen?

Dies geschieht ziemlich konstant, im Wesentlichen geht pipenv die Stadt, während man etwas "sperrt": Warum wird dieses Problem geschlossen?

Verstehen Sie, dass --skip-lock der richtige Weg ist, aber es ist überhaupt nicht klar, warum das "Installieren" ein paar Sekunden dauert und das "Sperren" ewig dauert: Es wäre großartig, wenn zumindest der Lock-Befehl einen Fortschritt ausgeben würde /update logs: Nach derzeitigem Stand ist nicht einmal klar, ob es für immer in einer Art while True stecken geblieben ist ...

Ich würde zumindest gerne wissen, ob ich etwas falsch mache oder nur ein "Feature" von pipenv.

In unserem Projekt ist pipenv lock so langsam. Es hat sich definitiv auf unseren normalen Gebrauch ausgewirkt. Das Hinzufügen eines neuen Pakets wird für uns jetzt zu einer echten Qual. Können wir dieses Verhalten irgendwie debuggen?

Ich versuche, PyTorch zu installieren und es hat 20 Minuten gedauert, um zu sperren, und dann wird der folgende Fehler ausgegeben

Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1992, in do_install
[pipenv.exceptions.InstallError]:       skip_lock=skip_lock,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Collecting pytorch==1.0.2 (from -r /tmp/pipenv-pb00kf8t-requirements/pipenv-vae35p2d-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ee/67/f403d4ae6e9cd74b546ee88cccdb29b8415a9c1b3d80aebeb20c9ea91d96/pytorch-1.0.2.tar.gz', 'Building wheels for collected packages: pytorch', '  Building wheel for pytorch (setup.py): started', "  Building wheel for pytorch (setup.py): finished with status 'error'", '  Running setup.py clean for pytorch', 'Failed to build pytorch', 'Installing collected packages: pytorch', '  Running setup.py install for pytorch: started', "    Running setup.py install for pytorch: finished with status 'error'"]
[pipenv.exceptions.InstallError]: ['ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' bdist_wheel -d /tmp/pip-wheel-f_h8w1pz --python-tag cp36:', '  ERROR: Traceback (most recent call last):', '    File "<string>", line 1, in <module>', '    File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 15, in <module>', '      raise Exception(message)', '  Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '  ----------------------------------------', '  ERROR: Failed building wheel for pytorch', '    ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch:', '    ERROR: Traceback (most recent call last):', '      File "<string>", line 1, in <module>', '      File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 11, in <module>', '        raise Exception(message)', '    Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '    ----------------------------------------', 'ERROR: Command "/home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch" failed with error code 1 in /tmp/pip-install-hix3yz6v/pytorch/']
ERROR: ERROR: Package installation failed...

Der Fehler ist nicht lesbar, keine Ahnung, was schief gelaufen ist. Die Installation mit pip in der Umgebung funktioniert einwandfrei! Das ist wirklich ein Showstopper. Zurück zu Requirements.txt...

Dies ist die Problemumgehung, die ich derzeit verwende:

export PIPENV_SKIP_LOCK=true

Dann wird pipenv install foo nicht gesperrt und Sie können manuell sperren, wenn Sie Zeit haben, indem Sie pipenv lock .

@awhillas Ziemlich sicher sagt die letzte Zeile alles, was Sie brauchen:

Sie haben versucht, "pytorch" zu installieren. Das für PyTorch benannte Paket ist "torch"

Das Sperren von Abhängigkeiten ist wichtig, daher glaube ich nicht, dass "Sperre überspringen" eine dauerhafte Lösung ist. Gleichzeitig kaufe ich einfach nicht ab, dass "Abhängigkeiten sperren" (was auch immer das unter der Haube bedeuten könnte) so wie es jetzt ist maximal optimiert ist und funktional viele Minuten oder Stunden in Anspruch nimmt. Tatsächlich lief meine Pipenv-Sperre mehrere Minuten lang auf einer Pipfile, die lächerliche 5 Abhängigkeiten hat, bevor sie versagte – Stack unten angehängt – und während dieser Zeit nur 10-15 % der verfügbaren CPU und ein wenig Speicher verbrauchte.

Können wir zumindest einige Gruppenanstrengungen vorbringen, um die Engpässe zu profilieren und zu bestimmen? Ich habe das Gefühl, dass da nur ein paar dumme, niedrig hängende Früchte drin sind, die nur darauf warten, diesen Prozess in eine vernünftige Laufzeit zu bringen.

pipenv version 2018.11.26

Für Pipfile:

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

[packages]

[dev-packages]
keras = "*"
tensorflow = "~=1.13"
setuptools = "*"
wheel = "*"
twine = "*"

[requires]
python_version = ">=3.6"

Pipfile.lock (63b275) out of date, updating to (5e165c)…
Locking [dev-packages] dependencies…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 109, in expect_loop
    return self.timeout()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.26', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/cli/command.py", line 254, in install
    editable_packages=state.installstate.editables,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1992, in do_install
    skip_lock=skip_lock,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1221, in do_init
    pypi_mirror=pypi_mirror,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1068, in do_lock
    lockfile=lockfile
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps
    c = resolve(cmd, sp)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 517, in resolve
    result = c.expect(u"\n", timeout=environments.PIPENV_INSTALL_TIMEOUT)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/delegator.py", line 215, in expect
    self.subprocess.expect(pattern=pattern, timeout=timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 341, in expect
    timeout, searchwindowsize, async_)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 369, in expect_list
    return exp.expect_loop(timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 119, in expect_loop
    return self.timeout(e)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

Als Ergänzung zum vorherigen Kommentar dauerte das separate Ausführen von pip lock nach dem ersten Ausführen von pip install --skip-lock ungefähr 15 Sekunden lang. Vielleicht ist der Aufruf von lock nach der Installation veraltet oder anderweitig fehlerhaft. :)

Zu Ihrer Information Ich habe festgestellt, dass Tensorflow der Schuldige der langsamen / zeitlichen Überschreitungssperre ist, wenn das Profil pipenv hilft! (Betrachte dies immer noch als Pipenv-Problem ...)

Tensorflow ist eines von vielen Paketen, die dazu führen können, dass pipenv im Grunde ein nutzloses Werkzeug wird. Ich mag jedoch den Vorschlag des Gruppenprofils. Ich denke, das ist eine ausgezeichnete Idee, um dieses Problem anzugehen. Nur um es noch einmal zu wiederholen, PEP 566 aktivierte die Aufzählung der Abhängigkeit (über pypi), ohne die gesamte Quelle zu laden, was hilfreich sein kann: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz Soweit ich das sehe, wird die meiste Zeit damit verbracht, alle Pakete der Abhängigkeiten herunterzuladen. Auch dies wurde bereits bestätigt.

So überprüfen Sie dies:

• Versuchen Sie, ein neues Pipfile erstellen und scipy (zum Beispiel) darin mit aktivierter Sperre zu installieren
• Warten Sie, bis die Sperrung abgeschlossen ist. (Dauert auf meinem Gerät ca. 5 Minuten)
• Pipfile.lock remove entfernen
• Führen Sie pipenv lock - das Sperren dauert jetzt sehr wenig Zeit (6 Sekunden auf meinem Computer), da alle Pakete bereits heruntergeladen und im Pipenv-Cache gespeichert sind, der normalerweise in ~/.cache/pipenv

Hier ist das Dockerfile, das ich verwendet habe, um dies zu testen:

FROM python:3.6
ENV WORKDIR=/work/
WORKDIR /work/
RUN python3 -m pip install --upgrade pip
RUN python3 -m pip install pipenv
RUN PIPENV_SKIP_LOCK=true pipenv install scipy
RUN date
RUN pipenv lock
RUN date
RUN rm Pipfile.lock
RUN pipenv lock
RUN date

@shtratos Ja, das macht Sinn und andere haben das in diesem

Bei einigen Bibliotheken wird dies wahrscheinlich aufgrund schlechter Qualität und schlechter Praktiken (keine Verwendung von setup.py oder Requirements.txt) funktionieren. Da jedoch einige der Haupttäter sehr beliebte Bibliotheken zu sein scheinen (tensorflow, numpy), könnte die Implementierung mit einem Fallback auf den superlangsamen Prozess ein guter Weg sein.

Können Sie mir sagen, wo ich diesen Code finden kann? Ich könnte versuchen, es in einer Gabel zu parallelisieren.

Ich denke, https://github.com/pandas-dev/pandas/ könnte ein Problem sein? Es ist auch ein gemeinsamer Punkt mit der Zeit für mich.

Obwohl pytest auch ein Problem sein kann:\

Ich glaube nicht, auf meinem Rechner funktioniert es einwandfrei, das Problem scheint allgemeiner zu sein

In meinem Fall scheint das Problem Pylint zu sein. Es bleibt immer beim Sperren hängen, wenn Sie einfach pipenv install pylint ausführen, siehe https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

Ich habe bei all meinen Projekten das gleiche Problem.
Die Ursache scheint Pylint zu sein.
Pipenv (pip) kann es erfolgreich installieren, aber das Sperren dauert ewig!
pipenv, version 2018.11.26

Minimal funktionierendes Beispiel

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

Wir sind uns bewusst und haben viele Probleme, dieses Thema zu verfolgen. Siehe #1785 #1886 #1891 und PR #1896

npm und Garn haben den Vorteil, dass sie nicht jedes potenzielle Paket vollständig herunterladen und ausführen müssen, um ihren Abhängigkeitsgraphen zu bestimmen, da die Abhängigkeiten im Klartext angegeben werden. Python-Abhängigkeiten erfordern, dass wir die Setup-Dateien jedes Pakets vollständig herunterladen und ausführen, um sie aufzulösen und zu berechnen. Das ist nur die Realität, es ist ein bisschen langsam. Wenn Sie keine 2 Minuten warten können oder der Meinung sind, dass sich der Kompromiss nicht lohnt, können Sie immer --skip-lock passieren.

Schließen, um in den anderen Ausgaben zu verfolgen.

3 von 4 anderen Problemen sind jetzt geschlossen und das verbleibende hat seit 2018 keine Aktivität mehr festgestellt. Dieses Problem besteht immer noch, also wäre es vielleicht eine gute Idee, es erneut zu öffnen?

Python-Abhängigkeiten erfordern, dass wir die Setup-Dateien jedes Pakets vollständig herunterladen und ausführen, um sie aufzulösen und zu berechnen

Ich glaube nicht, dass das für Räder immer noch gilt, was sollte jetzt die Mehrheit der Pakete sein?

Ich weiß, dass ich zumindest jedes Mal das Rad für dlib bauen muss, was schrecklich ist.

Der Prozess des Auflösens von Abhängigkeiten sollte irgendwo pro Paketversion zwischengespeichert werden, auch wenn es jedes Mal eine weitere Remote-Suche auf dem Client erfordert, um den Baum zu erhalten (das sollte nicht, Sie könnten ihn auch nachträglich lokal zwischenspeichern ). Paket-Repositorys könnten beispielsweise problemlos aufgelöste Dep-Bäume speichern. Der zusätzliche Netzwerktreffer für den zwischengespeicherten aufgelösten Dep-Baum wäre immer schneller als das Herunterladen eines gesamten Pakets und Computing.

FWIW Ich habe pipenv aus allen meinen Projekten entfernt (dies ist der eine Hauptgrund, es gibt andere).

virtualenv + pip (mit requirements.txt ) funktionieren jetzt ziemlich gut, sogar für Prod-Bereitstellungen; und auf jeden Fall setzt man heutzutage einen vollständig ausgeformten Container ein; nachdem ich mich wirklich mit pipenv beschäftigt habe, sehe ich den Sinn nicht mehr.

Bitte öffnen Sie dieses Problem erneut.
Andernfalls wird pipenv niemals das Referenz-Verpackungswerkzeug sein