<p>pipenv install ist sehr langsam</p>

Hey nochmal @Diggsey , das liegt an der Art, wie wir gerade Änderungen schreiben. Ich habe diese Änderungen bereit zum Zusammenführen, aber sie brechen für die projects.py API ab, also werden wir bis zur nächsten Hauptversion warten. Hoffentlich haben wir das in den nächsten Wochen fertig. Ich lasse dies offen, um das Problem vorerst zu verfolgen.

Auf der PyCon sind wir gemeinsam darauf gesprintet. Bald geht es schneller.

Im Moment ist es für mich nicht langsam, es ist eiskalt...

Ein pipenv install my_package oder ein einfaches pipenv install gibt mir nach 20 Minuten keine Ausgabe.

EDIT: Bestätigung, nach ein paar Stunden immer noch nichts. Ist es das gleiche Problem? Normalerweise war es langsam, aber es endete nach 5 bis 10 Minuten.

Hey @NicolasWebDev , welche Version von pipenv verwendest du? Haben Sie delegator.py separat auf Ihrem System installiert? Wenn ja, um welche Version handelt es sich? Dies war ein Problem, das in v3.6.0 hätte behoben werden sollen.

Wenn alles oben auf dem neuesten Stand ist, könnten Sie bitte den Inhalt Ihres Pipfiles zur Verfügung stellen? Danke!

Hallo @nateprewitt , du

Entschuldigung für den Lärm, ich vergesse immer, dass über pip installierte Pakete nicht automatisch aktualisiert werden.
Danke!

Schön, dass du die Dinge gelöst hast @NicolasWebDev! Wir arbeiten daran, dies zu beschleunigen, hoffentlich wird #373 in der nächsten Version einen Schritt näher kommen.

@Diggsey @NicolasWebDev , ich habe gerade 4.1.2 veröffentlicht, in dem diese Geschwindigkeitsverbesserungen hinzugefügt werden sollten. Hier gibt es noch einiges zu tun, aber dies wird zumindest die anfängliche Bootstrap-Zeit für pipenv beschleunigen.

@nateprewitt Danke für das Update, pipenv scheint mir jetzt schneller zu sein, aber es dauert immer noch einige Minuten, um pipenv lock auszuführen, auch wenn sich nichts geändert hat - es wartet immer noch in Locking [packages] dependencies... auf die riesigen Großteil dieser Zeit.

@Diggsey , die

@nateprewitt Wir könnten einige davon entfernen, aber die meisten sind direkte Abhängigkeiten - warum muss es jedes Mal alle Abhängigkeiten herunterladen, wenn es die Sperrdatei generiert?

Wir müssen alles bestimmen, was es als Abhängigkeiten installiert. Um dies zu erreichen, laden wir jedes Paket herunter und bestimmen, wie eine Installation zur Sperrzeit aussieht. Dies ermöglicht es uns, alles in der Pipfile.lock entsprechend anzuheften. Ohne Download gibt es keine zuverlässige Möglichkeit, Unterabhängigkeiten zu überprüfen und Bereichsabhängigkeitsdeklarationen aufzulösen.

Wäre es möglich, die heruntergeladenen Pakete zwischenzuspeichern, da die meisten Pakete im Laufe der Zeit gleich bleiben werden?

@Diggsey möchte das für uns untersuchen?

Dies mag eine dumme Frage sein, aber führt Pip nicht bereits Paket-Caching durch ?

Ich habe den Eindruck, dass es so ist.

Kann pipenv das Pip-Cache-System verwenden oder muss es von Grund auf neu implementiert werden?

Pipenv führt nur pip aus, daher sollte der Cache automatisch verwendet werden.

Fest! Schloss ist jetzt bösartig schnell.

Oh danke. Ich glaube, das war das einzige, was mich davon abhielt, alle bei der Arbeit zu drängeln.

Wow, schön, das war buchstäblich mehr als eine 100-fache Beschleunigung für mich und es kam auch zu einem Abhängigkeitskonflikt, den die vorherige Version nicht auffing!

Nützlich wäre ein verbose Flag für pipenv lock - ich konnte den Abhängigkeitskonflikt nur diagnostizieren, indem ich piptools/logging.py bearbeitete, um die ausführliche Protokollierung zu aktivieren, aber sobald ich dies tat, gab es ein sehr klarer Hinweis darauf, was vor sich ging.

Ich vermisse wahrscheinlich etwas :) Wo ist es behoben? Die neueste Version ist 4 Tage her, also habe ich die neueste Version von master installiert. pipenv install ist jedoch immer noch langsam.

Ich habe es versucht:

• installiere pipenv die schicke Art ⚡️ 🍰 ⚡️
• Verwenden Sie sowohl die neueste veröffentlichte Version von pipenv als auch die neueste Version von master
• Einzelpaket installieren

Mit der neuesten stabilen Version (5.3.5.) dauert es 3:40, um ein Paket zu installieren:

∙ time pipenv install --dev raven
Installing raven...
Collecting raven
  Using cached raven-6.1.0-py2.py3-none-any.whl
Collecting contextlib2 (from raven)
  Using cached contextlib2-0.5.5-py2.py3-none-any.whl
Installing collected packages: contextlib2, raven
Successfully installed contextlib2-0.5.5 raven-6.1.0

Adding raven to Pipfile's [dev-packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install --dev raven  10,11s user 2,77s system 5% cpu 3:40,04 total

Bei Verwendung der Version von master hängt es immer noch (ein Paket, +10 Minuten)

EDIT: Es ist gerade fertig geworden:

pipenv install graphene_django  8,03s user 1,28s system 1% cpu 11:23,11 total

Irgendwelche Ideen? Vielen Dank!

Manchmal dauert die Installation von Abhängigkeiten eine Weile, insbesondere wenn sie Zusammenstellungen haben. Möchten Sie Ihre Pipfile teilen?

Ich verstehe, dass es manchmal eine Weile dauert, aber es war von Anfang an langsam. Nur neugierig, ob es ein Problem an meiner Seite ist.

Hier ist mein Pipfile:

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

[dev-packages]
pytest = "*"
pytest-django = "*"
pytest-testmon = "*"
pytest-watch = "*"
django-debug-toolbar = "*"
raven = "*"

[packages]
dj-database-url = "*"
Django = "*"
djangorestframework = "*"
gunicorn = "*"
newrelic = "*"
psycopg2 = "*"
requests = "*"
whitenoise = "*"
graphene-django = "*"

psycopg2 kann eine Weile dauern, da es möglicherweise aus dem Quellcode kompiliert wird. Alles andere sollte nett und schnell sein. Versuchen Sie, es zu entfernen und sehen Sie, wie viel sich Ihre Geschwindigkeit erhöht.

$ pipenv install raven hat bei mir nur 1s gedauert.

$pipenv install raven hat bei mir nur 1s gedauert.

Das würde ich erwarten! Kann ich die ausführliche Ausgabe irgendwie aktivieren?

Ich habe versucht, psycopg2 entfernen, aber es hat keine großen Auswirkungen. Das Ausführen von pipenv install raven hängt für eine Weile.

Ich habe:

• Python 3.6.2
• macOS 10.12.6

Ich sehe keinen Grund, warum Rabe nicht sofort sein sollte.

Mache $ pip install raven innerhalb von $ pipenv shell und sag mir, ob es dort auch langsam ist.

Alles, was pipenv tut, ist pip auszuführen, also ist das effektiv der "ausführliche Modus".

Das ist sofort:

∙ time pip install raven                                                                                                                                 19:38  tricoder<strong i="6">@issac</strong>
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)
noglob pip install raven  0,54s user 0,15s system 76% cpu 0,900 total

Das Ausführen von pipenv dauert etwa 2-3 Minuten (innerhalb/außerhalb von pipenv shell ).

∙ time pipenv install raven                                                                                                                              19:39  tricoder<strong i="12">@issac</strong>
Installing raven...
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)

Adding raven to Pipfile's [packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install raven  4,49s user 0,46s system 2% cpu 3:21,17 total

@Diggsey können Sie eine neue Ausgabe zu --verbose eröffnen und ein Beispiel dafür geben, wie es aussehen soll?

@tricoder42 ist der langsame Teil der Sperrschritt oder der Installationsschritt? Das Sperren wurde in den neuesten Versionen erheblich verbessert.

```Schale
$ time pipenv install raven
Rabe installieren...
Sammeln von Raben
Verwenden des zwischengespeicherten Raben-6.1.0-py2.py3-none-any.whl
Voraussetzung bereits erfüllt: contextlib2 in /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (von raven)
Gesammelte Pakete installieren: Rabe
Raven-6.1.0 erfolgreich installiert

Rabe wird zu Pipfiles [Paketen] hinzugefügt...
Abhängigkeiten von [dev-packages] sperren...
Abhängigkeiten von [Paketen] sperren...
Aktualisiertes Pipefile.lock!
9.30 real 5.49 Benutzer 0.42 sys

Es ist wie 50:50 beim Installieren:Sperren

@tricoder42 und du verwendest das neueste?

Lassen Sie mich mit Ihrem genauen Pipfile replizieren.

Ich denke schon:

∙ pipenv --version                                                                                                                                       19:42  tricoder<strong i="6">@issac</strong>
pipenv, version 5.3.5

∙ pipsi upgrade git+https://github.com/kennethreitz/pipenv.git#egg=pipenv                                                                                19:45  tricoder<strong i="9">@issac</strong>
Collecting pipenv from git+https://github.com/kennethreitz/pipenv.git#egg=pipenv
  Cloning https://github.com/kennethreitz/pipenv.git to /private/var/folders/g9/1wbckv154mbby3tm411z_m340000gn/T/pip-build-se4ao5/pipenv
...
Installing collected packages: pipenv
  Found existing installation: pipenv 5.3.5
    Uninstalling pipenv-5.3.5:
      Successfully uninstalled pipenv-5.3.5
  Running setup.py install for pipenv ... done
Successfully installed pipenv-5.3.5

```Schale
$ time pipenv install
Kein Paket bereitgestellt, alle Abhängigkeiten werden installiert.
Pipfile gefunden unter /Users/kennethreitz/pipenv/testapp/Pipfile. Wenn man bedenkt, dass dies das Projektheim ist.
Pipfile.lock nicht gefunden, wird erstellt...
Abhängigkeiten von [dev-packages] sperren...
Abhängigkeiten von [Paketen] sperren...
Aktualisiertes Pipefile.lock!
Abhängigkeiten von Pipefile.lock installieren...
[================================] 22/22 - 00:00:37
58,94 real 40,51 Benutzer 8,62 sys

Es tut es sogar, wenn ich das erste Paket in frische neue pipenv installiere. Ich werde versuchen, pipenv --three anstelle von pipenv --python python3.6 zu erstellen

@tricoder42 möchten Sie in etwa einer Stunde in einen Google-Hangout einsteigen?

Oder wir können die Bildschirmfreigabe von Apple verwenden, wenn Sie Messages.app verwenden.

Füge mich hinzu! Ich bin [email protected].

Ich bin im Begriff, einem Meeting beizutreten, bin aber danach verfügbar.

Cool! Ich werde versuchen, alles von Grund auf zu bereinigen und neu zu installieren, und wir werden sehen. Ich bin in einer Stunde verfügbar

Super – dann finden wir das heraus. Füge mich auf Messages.app hinzu :)

Wenn jemand ein extrem langsames Locking Verhalten mit v11.9.0 erlebt, habe ich festgestellt, dass ein Downgrade auf v9.0.0 eine Installation von 5m30s auf 1m36s dauert.

@ryantuck Ich würde empfehlen, wenn Sie eine alte Version an 9.0.3 pinnen möchten, aber Sie verlieren eine erhebliche Menge an zusätzlicher Sicherheit für die Geschwindigkeit, können Sie genauso gut --skip-lock bei verwenden dieser Punkt

--skip-lock Dinge definitiv beschleunigt. Ich bin diesen Weg gegangen, weil pipenv install --system --python=3.6 nicht wirklich auf dem richtigen System-Python installiert wurde, und ich ging davon aus, dass ich die Pipfile.lock generieren musste, bevor ich die Systeminstallation versuchte. Es hat immer noch nicht funktioniert, also habe ich wieder das normale alte pip , werde aber diesen Thread kommentieren, wenn ich jemals Fortschritte in dieser Richtung mache.

—system und —python sich gegenseitig aus — letztere Option benötigt immer eine virtuelle Umgebung

Ja, bei mir dauert das Sperren auch etwas. v11.10.0. Ubuntu auf WSL.

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

[packages]
babel = "==2.5.3"
"boto3" = "==1.7.3"
colorama = "==0.3.9"
coreapi = "==2.3.3"
dj-database-url = "==0.5.0"
djangorestframework = "==3.7.7"
django-axes = "==4.0.2"
django-clever-selects = "==0.8.2"
django-crispy-forms = "==1.7.2"
django-choices = "==1.6.0"
django-extra-views = "==0.10.0"
django-filter = "==1.1.0"
django-hijack = "==2.1.7"
django-hijack-admin = "==2.1.7"
django-js-reverse = "==0.8.1"
django-model-utils = "==3.1.1"
django-phonenumber-field = "==2.0.0"
django-polymorphic = "==2.0.2"
django-redis-cache = "==1.7.1"
django-role-permissions = "==2.2.0"
"django-s3direct" = "==1.0.4"
django-static-precompiler = {extras = ["libsass"], version = "==1.8.2"}
django-storages = "==1.6.6"
"django-tables2" = "==1.21.2"
django-webpack-loader = "==0.6.0"
django-widget-tweaks = "==1.4.2"
facebookads = "==2.11.4"
googleads = "==11.0.1"
markdown = "==2.6.11"
phonenumbers = "==8.9.3"
pillow = "==5.1.0"
"psycopg2-binary" = "==2.7.4"
pygments = "==2.2.0"
pyssim = "==0.4"
python-dotenv = "==0.8.2"
pytz = "==2018.4"
raven = "==6.6.0"
sendgrid-django = "==4.2.0"
slacker = "==0.9.65"
termcolor = "==1.1.0"
tqdm = "==4.21.0"
twitter-ads = "==3.0.0"
brotlipy = "==0.7.0"
waitress = "==1.1.0"
whitenoise = "==3.3.1"
Django = "==2.0.4"

[dev-packages]
coverage = "==4.5.1"
selenium = "==3.11.0"
tblib = "==1.3.2"
"flake8" = "==3.5.0"
django-debug-toolbar = "==1.9.1"
django-extensions = "==2.0.6"

[requires]
python_version = "3.6"

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

real    8m1.993s
user    5m32.406s
sys     7m15.203s

Beim zweiten oder dritten Mal sollte es etwas schneller sein, weil
zwischenspeichern. Sehen Sie eine Verbesserung?
Am Do, Apr 12, 2018 at 10:23 AM Alexander Kavanaugh <
[email protected]> schrieb:

Ja, bei mir dauert das Sperren auch etwas. v11.10.0. Ubuntu auf WSL.

[[source]]url = " https://pypi.python.org/simple "verify_ssl = truename = "pypi"
[packages]babel = "==2.5.3""boto3" = "==1.7.3"colorama = "==0.3.9"coreapi = "==2.3.3"dj-database-url = "== 0.5.0"djangorestframework = "==3.7.7"django-axes = "==4.0.2"django-clever-selects = "==0.8.2"django-crispy-forms = "==1.7.2" django-choices = "==1.6.0"django-extra-views = "==0.10.0"django-filter = "==1.1.0"django-hijack = "==2.1.7"django-hijack- admin = "==2.1.7"django-js-reverse = "==0.8.1"django-model-utils = "==3.1.1"django-phonenumber-field = "==2.0.0"django- polymorph = "==2.0.2"django-redis-cache = "==1.7.1"django-role-permissions = "==2.2.0""django-s3direct" = "==1.0.4"django- static-precompiler = {extras = ["libsass"], version = "==1.8.2"}django-storages = "==1.6.6""django-tables2" = "==1.21.2"django-webpack -loader = "==0.6.0"django-widget-tweaks = "==1.4.2"facebookads = "==2.11.4"googleads = "==11.0.1"markdown = "==2.6.11" phonenumbers = "==8.9.3"pillow = "==5.1.0""psycopg2-binary" = "==2.7.4"pygments = "==2.2.0"pyssim = "==0.4"python-dotenv = "==0.8.2"pytz = "==2018.4"Rabe = "==6.6.0"sendgrid-django = "==4.2.0"slacker = "==0.9.65"termcolor = "==1.1.0"tqdm = "==4.21.0"twitter-ads = "==3.0.0"brotlipy = "==0.7.0"kellnerin = "==1.1.0"whitenoise = "==3.3.1"Django = "==2.0.4"
[dev-packages]coverage = "==4.5.1"selenium = "==3.11.0"tblib = "==1.3.2""flake8" = "==3.5.0"django-debug-toolbar = " ==1.9.1"django-Erweiterungen = "==2.0.6"
[erfordert]python_version = "3.6"

Pipfile.lock nicht gefunden, wird erstellt…
Abhängigkeiten von [dev-packages] sperren…
Abhängigkeiten von [Paketen] sperren…
Pipfile.lock aktualisiert (7a535c)!
Abhängigkeiten von Pipfile.lock (7a535c) installieren…
▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

echte 8m1.993s
Benutzer 5m32.406s
sys 7m15.203s

—
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/356#issuecomment-380882203 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

Ich hatte die Pakete schon vorher installiert; Ich habe gerade die Sperrdatei entfernt und die Installation erneut ausgeführt. Ich werde es noch einmal tun, um einen weiteren Datenpunkt zu bekommen

@jtratner Woah. Super interessant... was bewirkt, dass das Caching erst nach dem dritten+ Mal einsetzt?

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
An error occurred while installing coreapi==2.3.3! Will try again.
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:58
Installing initially–failed dependencies…
Success installing coreapi==2.3.3!▉▉▉ 0/1 — 00:00:00
  ☤  ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 1/1 — 00:00:01

real    2m50.218s
user    2m19.438s
sys     5m44.797s

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:55

real    2m32.042s
user    2m6.516s
sys     5m10.219s

@kavdev @jtratner hat eine Funktion eingeführt, um auch die Hashes zwischenzuspeichern, was eine beträchtliche Verbesserung

Hier bin ich... 15 Minuten später

@giantas nicht hilfreich. Bitte geben Sie pipfile, Ausgabe und Dauer bei der pip-Installation an. Auch ob Sie einzelne Pakete machen können.

Es dauert ziemlich viel, um auf meinem Gerät zu laufen. macOS 10.13.4, pipenv, Version 11.10.0

Der Download läuft fast sofort, aber dann bleibt er bei Locking [packages] dependencies… . Hier dauert eine halbe Minute für zwei Abhängigkeiten und dann 6 Minuten für weitere 3 Abhängigkeiten. Wenn ich alle Abhängigkeiten meines Projekts darauf werfe, hängt es einfach auf unbestimmte Zeit beim Sperrschritt

pablo<strong i="8">@batman</strong> scanr (develop) $ time pipenv install flask flask_pymongo
Installing flask…
Looking in indexes: https://pypi.python.org/simple
Collecting flask
  Using cached https://files.pythonhosted.org/packages/77/32/e3597cb19ffffe724ad4bf0beca4153419918e7fa4ba6a34b04ee4da3371/Flask-0.12.2-py2.py3-none-any.whl
Collecting Werkzeug>=0.7 (from flask)
  Using cached https://files.pythonhosted.org/packages/20/c4/12e3e56473e52375aa29c4764e70d1b8f3efa6682bef8d0aae04fe335243/Werkzeug-0.14.1-py2.py3-none-any.whl
Collecting itsdangerous>=0.21 (from flask)
Collecting Jinja2>=2.4 (from flask)
  Using cached https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl
Collecting click>=2.0 (from flask)
  Using cached https://files.pythonhosted.org/packages/34/c1/8806f99713ddb993c5366c362b2f908f18269f8d792aff1abfd700775a77/click-6.7-py2.py3-none-any.whl
Collecting MarkupSafe>=0.23 (from Jinja2>=2.4->flask)
Installing collected packages: Werkzeug, itsdangerous, MarkupSafe, Jinja2, click, flask
Successfully installed Jinja2-2.10 MarkupSafe-1.0 Werkzeug-0.14.1 click-6.7 flask-0.12.2 itsdangerous-0.24

Adding flask to Pipfile's [packages]…
Installing flask_pymongo…
Looking in indexes: https://pypi.python.org/simple
Collecting flask_pymongo
  Using cached https://files.pythonhosted.org/packages/fa/71/ab920741dedd605ef4adbd57d0c7d9f43a6b6fe4068604fffbc6f64b2c9c/Flask_PyMongo-0.5.1-py3-none-any.whl
Requirement already satisfied: Flask>=0.8 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from flask_pymongo) (0.12.2)
Collecting PyMongo>=2.5 (from flask_pymongo)
  Using cached https://files.pythonhosted.org/packages/5c/7f/1f7240883ec3fa768d7e066c9cbd42ceb42d699ba1a0fb9d231c098a542d/pymongo-3.6.1-cp36-cp36m-macosx_10_6_intel.whl
Requirement already satisfied: click>=2.0 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (6.7)
Requirement already satisfied: itsdangerous>=0.21 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.24)
Requirement already satisfied: Werkzeug>=0.7 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.14.1)
Requirement already satisfied: Jinja2>=2.4 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (2.10)
Requirement already satisfied: MarkupSafe>=0.23 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Jinja2>=2.4->Flask>=0.8->flask_pymongo) (1.0)
Installing collected packages: PyMongo, flask-pymongo
Successfully installed PyMongo-3.6.1 flask-pymongo-0.5.1

Adding flask_pymongo to Pipfile's [packages]…
Pipfile.lock (c202d3) out of date, updating to (3068be)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (3068be)!
Installing dependencies from Pipfile.lock (3068be)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 32/32 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    0m37.816s
user    0m34.556s
sys 0m4.517s

pablo<strong i="5">@batman</strong> scanr (develop) $ time pipenv install gunicorn h5py joblib
Installing gunicorn…
Looking in indexes: https://pypi.python.org/simple
Collecting gunicorn
  Using cached https://files.pythonhosted.org/packages/64/32/becbd4089a4c06f0f9f538a76e9fe0b19a08f010bcb47dcdbfbc640cdf7d/gunicorn-19.7.1-py2.py3-none-any.whl
Installing collected packages: gunicorn
Successfully installed gunicorn-19.7.1

Adding gunicorn to Pipfile's [packages]…
Installing h5py…
Looking in indexes: https://pypi.python.org/simple
Collecting h5py
  Using cached https://files.pythonhosted.org/packages/69/d5/dff2a8f7658fd87ab3330a0ab47e4363681d8bdf734a495add65a347f5e3/h5py-2.7.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Requirement already satisfied: six in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from h5py) (1.11.0)
Collecting numpy>=1.7 (from h5py)
  Using cached https://files.pythonhosted.org/packages/a0/df/fa637677800e6702a57ef09e1d62e42aec3f598fb235f897155d146f2f59/numpy-1.14.2-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy, h5py
Successfully installed h5py-2.7.1 numpy-1.14.2

Adding h5py to Pipfile's [packages]…
Installing joblib…
Looking in indexes: https://pypi.python.org/simple
Collecting joblib
  Using cached https://files.pythonhosted.org/packages/4f/51/870b2ec270fc29c5d89f85353da420606a9cb39fba4747127e7c7d7eb25d/joblib-0.11-py2.py3-none-any.whl
Installing collected packages: joblib
Successfully installed joblib-0.11

Adding joblib to Pipfile's [packages]…
Pipfile.lock (0d514f) out of date, updating to (a4d15f)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (a4d15f)!
Installing dependencies from Pipfile.lock (a4d15f)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 36/36 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    6m31.572s
user    1m1.986s
sys 0m11.047s

@pablote heiliger Mist, der langsam ist! Beachten Sie, dass dies teilweise auf die Installation von numpy zurückzuführen ist, die wir wahrscheinlich von der Quelle zur Sperre kompilieren oder etwas Dummes. würde helfen, wenn wir hier nützliche Ausgaben bereitstellen

Kann ich etwas dagegen tun? oder habe ich einfach Pech bei der Verwendung von pipenv und habe diese langsamen Lock-Dateizeiten? Ich denke, ich könnte --skip-lock, aber irgendwie wollte ich diese Funktion

@pablote können Sie überprüfen, ob Sie den gleichen Sperrvorgang erneut ausführen, ist er immer noch langsam?

Wenn ich es erneut ausführe, wird es fast sofort beendet, also ist es wohl nur das erste Mal, dass eine neue Abhängigkeit hinzugefügt wird.

es werden die Hashes also tatsächlich lokal zwischengespeichert, also ist es, aus welchem ​​Grund auch immer, der Hash-Generierungsprozess hier unglaublich langsam ...

Lassen Sie mich wissen, wenn ich Informationen zur Diagnose bereitstellen kann. Im Moment gehe ich einfach zurück zu pip + virtualenv + pip-tools :/

@pablote Sobald Sie die Hashes einmal haben, wird das erneute Sperren nicht mehr so ​​​​langsam sein

Bitte geben Sie eine nützliche Ausgabe an. Ich habe gerade meine Pipenv von 9.1.0 auf 11.10.0 aktualisiert, um den Fehler des ungültigen Markers beim Paketsperrschritt zu beheben, z. und matplotlib drin und bei meinem letzten Versuch, pipenv install zu verwenden, um die Sperrdatei zum Laufen zu bringen, sitze ich seit mehr als 10 Minuten in locking [packages] dependencies… .

Da es keine Ausgabe gibt, kann ich nicht sagen, ob tatsächlich etwas läuft (wie das Erstellen von Numpy aus der Quelle) oder ob es nur hängt. Das Beste, was ich tun kann, ist, auf top zu blinzeln und zu dem Schluss zu kommen, dass es vielleicht etwas tut, weil ein Python-Prozess herumzuhängen scheint ... aber ich muss diese virtuelle Umgebung löschen und neu anfangen, wenn etwas bewegt sich nicht bald.

Ich freue mich, bei Bedarf zu einigen Arbeiten dazu beizutragen.

Bitte geben Sie eine nützliche Ausgabe an. Ich habe gerade meine Pipenv von 9.1.0 auf 11.10.0 aktualisiert, um den Fehler des ungültigen Markers beim Paketsperrschritt zu beheben, z. und matplotlib drin und bei meinem letzten Versuch, pipenv install zu verwenden, um die Sperrdatei zum Laufen zu bringen, sitze ich seit mehr als 10 Minuten im Sperren von [Paketen]-Abhängigkeiten.

Völlig verständliche Beschwerde und ich habe im Hinterkopf darüber nachgedacht, wie wir dem Benutzer nützlicheres Feedback geben können (weil ich zustimme, dass es ein bisschen verwirrend ist, dass es keine Ausgabe hat). Ich würde nach 15 Minuten aufgeben. Wie @techalchemy darauf hingewiesen hat, sollte Ihr Cache jedes Mal ein wenig mehr

Eine Frage: Verwenden Sie öffentliches PyPI?

@jtratner ja, mit öffentlichem PyPi --- und ich habe schließlich aufgegeben, die Virtualenv verworfen und eine neue erstellt; Ich habe es geschafft, eine Sperrdatei zu erstellen, indem ich meine Abhängigkeiten nacheinander installiert habe. (Interessanterweise war matplotlib die langsamste – sogar noch schlimmer als numpy!)

Vielleicht hilft eine Nachricht wie This may take a long time die Leute zu beruhigen, bis eine klarere Lösung gefunden wird.

15 Minuten sind immer noch wahnsinnig lang, ich bezweifle, dass ich mich hinsetzen und darauf warten würde. @paultopia Sie können pipenv lock —verbose für mehr Ausgabe ausführen

Es hat das allgemeine Gefühl, langsamer zu sein, als es sein sollte, aber vielleicht unterschätze ich das Problem. Wenn ich mir die laufenden Prozesse auf meinem Computer ansehe, kann ich sehen, dass Python die ganze Zeit läuft, während pipenv läuft, und es geht nie über ~15%. Es sollte wahrscheinlich mehr davon verwenden, wenn es CPU-intensive Arbeit wie Hashing-Dateien verrichtet . Außerdem habe ich andere Paketmanager verwendet, die Abhängigkeiten hashen, wie z. B. Garn, und sie sind ziemlich schnell.

Wir müssen herausfinden, was es tut...

Ich habe ein Github-Projekt erstellt, das bei der Verwendung von Sperren Langsamkeit zeigt. Bitte schauen Sie auf https://github.com/AndreasPresthammer/slow-pipenv . Ich bin mir aber nicht 100% sicher, ob das das gleiche Problem ist. Ziehen Sie das Repository herunter, führen Sie das slow.sh-Skript aus und beobachten Sie den Unterschied in der Ausführungszeit.

@AndreasPresthammer , Ihr Skript ist also nur das Timing einer nicht zwischengespeicherten Sperre im Vergleich zur Installation mit Sperre. Wir wissen, dass es die Verriegelung ist, aber das ist langsam. Im Fall von numpy liegt es wahrscheinlich daran, dass es in der Vergangenheit sdists zur Auflösung verwenden musste, was eine Kompilierung bedeutete. Wir können jetzt Räder benutzen. Das kann die Sache beschleunigen

Dies ist definitiv immer noch ein Problem (5+ Minuten), mit den neuesten Versionen von Python3.6, pip und pipenv und der Installation eines einfachen Pakets wie torch . Ich denke nicht, dass dieses Problem als geschlossen gekennzeichnet werden sollte.

Für alle, die das Schließen dieses Problems kommentieren möchten: Geben Sie die Ausgabe von pipenv lock --verbose . Wir wissen, dass die Auflösung von Paketen langsam ist, die aus dem Quellcode kompiliert werden und deren Erstellung unter normalen Bedingungen lange dauert. Wir benötigen Protokolle, um Einblick in die Ursache zu erhalten, wenn dies langsamer als normal ist.

Ich verwende Docker auch für meine Entwicklungs- und Produktionsumgebung und denke, dass sich die Installation in Docker im Vergleich zur Installation auf dem Host langsam anfühlt. Vielleicht ist es nur die Kombination aller Pakete, aber ich würde gerne Feedback von Leuten hören, die erfahrener sind als ich.

Hier ist das Protokoll von pipenv lock --verbose , einschließlich der Pipfile und Pipfile.lock :

https://gist.github.com/mimischi/6270b7ece566cc571b427baaf1c331d4

@mimischi Die Auflösungsergebnisse werden im Host zwischengespeichert, aber Docker kann nicht darauf zugreifen. Es ist langsam, weil es die gesamte Auflösung von Grund auf neu erstellen muss. Es wäre hilfreich, wenn Sie das Cache-Verzeichnis des Hosts in Docker einhängen. Es gibt einen Kommentar in einem Problem, in dem der Pfad erwähnt wird, den Sie mounten sollten. Ich habe jetzt nicht die Zeit, es nachzuschlagen, aber Sie können versuchen, es zu finden. (Und tragen Sie es bitte zur FAQ-Seite des

FWIW, das Sperren meiner Dev-Box dauert jetzt weniger als 30 Sekunden. Viel besser als zuvor – schätzen Sie es.

Hallo, habe das gleiche Problem.
hier ist die ausführliche

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

                          ROUND 1                           
Current constraints:
  pylint

Finding the best candidates:
  found candidate pylint==1.9.1 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six

New dependencies found in this round:
  adding ['astroid', '<2.0,>=1.6', '[]']
  adding ['isort', '>=4.2.5', '[]']
  adding ['mccabe', '', '[]']
  adding ['six', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  mccabe
  pylint
  six

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  isort==4.3.4              requires -
  mccabe==0.6.1             requires -
  six==1.11.0               requires -

New dependencies found in this round:
  adding ['lazy-object-proxy', '', '[]']
  adding ['wrapt', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  lazy-object-proxy
  mccabe
  pylint
  six
  wrapt

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate lazy-object-proxy==1.3.1 (constraint was <any>)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)
  found candidate wrapt==1.10.11 (constraint was <any>)

Finding secondary dependencies:
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  wrapt==1.10.11            requires -
  lazy-object-proxy==1.3.1  requires -
  six==1.11.0               requires -
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  mccabe==0.6.1             requires -
  isort==4.3.4              requires -
------------------------------------------------------------
Result of round 3: stable, done

Locking [packages] dependencies…

Hier ist das pipenv --version : pipenv, Version 2018.05.18

Ich weiß auch nicht, warum dies geschieht, es tritt kein bestimmter Grund / Fehler auf.
In meinem Fall, wenn ich pipenv lock mache, beginnt es, aber es endet nie, soweit ich weiß. Ich warte nun seit 2 Stunden immer noch kein Zeichen der Fertigstellung. Und hat mir zweimal ReadTimeoutError gegeben. Dies ist das dritte Mal, dass ich dies tue.
Verwenden von Python 3.6.4

Jede Hilfe wäre eine große Hilfe, da der Fälligkeitstermin meines Projekts näher rückt.

Stimmen Sie auch dafür, dass dieses Thema wieder geöffnet wird. Es ist noch lange nicht gelöst .... dauert zwischen 10 und 20 Minuten, um mein Projekt in einem Docker-Container zu sperren. Es verwendet auch eine wahnsinnige Menge an Speicher - so dass ich die Zuweisung an Docker erhöhen musste, um zu verhindern, dass der Prozess beendet wird.

Bitte geben Sie Pipfilesmand-Beispieldetails zu Ihren Umgebungen an, wenn Sie Hilfe bei Problemen mit der Auflösungsgeschwindigkeit benötigen. Wir schneiden diese Woche eine Veröffentlichung und haben keine Zeit, einzelne Kommentare zu geschlossenen Threads zu verfolgen, können aber mit Pipfiles testen, wenn Sie eine bereitstellen

@jkp Erlauben Sie mir, Ihnen zu versichern, dass jeder einzelne Kernentwickler dieses Projekts (nicht dass wir viele von uns sind) sich dieses Problems sehr wohl bewusst ist und sich darüber genauso beunruhigt wie Sie, wenn nicht sogar noch mehr. Dies ist jedoch keineswegs ein einfaches Problem, und wir haben bereits alles daran gesetzt, es so nutzbar wie möglich zu machen, ohne alles in Python-Packaging zerlegen zu müssen. Wir haben derzeit auch viel auf dem Teller und müssen uns auch auf diese anderen Themen konzentrieren. Die unvermeidliche Entscheidung, die ich treffen muss, ist daher, Probleme zu priorisieren, von denen wir tatsächlich wissen, wie sie zu lösen sind, und erst dann über unsere nächsten Schritte nachzudenken, wenn diese erledigt sind, um die Wirkung unserer Bemühungen zu maximieren.

Nun, ich erkenne voll und ganz an, dass Ihre Priorität von unserer abweichen kann. Dieses Leistungsproblem kann das größte Einzelproblem in Ihrem Arbeitsablauf sein, und Sie möchten es als das Wichtigste in diesem Projekt darstellen. Bitte bedenken Sie jedoch, dass Sie nicht der einzige Benutzer dieses Tools sind, und wir müssen den Bedarf aller, sogar den unserer eigenen , vor Ihren priorisieren. Ich erkenne das an. Ich fordere daher jeden auf, der die Situation teilt, sich zu diesem Thema zu äußern und zu versuchen, einen Weg zu finden, es zu lösen. Sobald wir wissen, was wir wirklich tun sollen, können wir es tun.

Das Problem wird geschlossen gehalten, weil wir nicht wissen, was wir tun können, und würde nur als Rauschen in der Problemverfolgung dienen, wenn wir versuchen, es zu verwalten. Zumindest in unserem Workflow hat es keinen Sinn, ein Problem zu haben, an dem niemand arbeiten kann.

Schätzen Sie Ihren Workflow. Wenn Sie also Probleme so verwalten, ist das in Ordnung. Ich werde versuchen, alle Informationen hinzuzufügen, die mir helfen, das Problem aufzuspüren.

Ich habe einige Fehler behoben, indem ich mitmproxy zwischen pipenv und dem Netz installiert habe, um die gestellten Anforderungen zu verfolgen. Ich habe ein paar interessante Dinge gefunden.

1. Wir verwenden einen privaten pypi Index, der json-api noch nicht unterstützt. Dies verlangsamt die Dinge erheblich, da es so aussieht, als ob es sich bei dem Fallback um Bruteforce handelt und alles herunterzuladen, was im http-Index aufgeführt ist, um Metadaten usw. zu extrahieren. Ein Vorschlag hier wäre, einfach eine einfache Protokollierung hinzuzufügen, um zu warnen, dass diese Fallback-Methode verwendet wird - es könnte jemand anderem ersparen, tiefer graben zu müssen, um dies herauszufinden.

2. Bei der Brute-Force-Methode scheint der Code Pakete herunterzuladen, die für die verwendete Architektur nicht relevant sind. Auf einem Linux-Rechner wurden beispielsweise win32 oder osx spezifische Radpakete heruntergeladen. Dies scheint etwas, das erkannt und vermieden werden könnte, da klar ist, dass Binärpakete, die für andere Architekturen erstellt wurden, keinen Nutzen haben werden.

Ich werde weiter debuggen und alle nützlichen Informationen melden, wenn ich sie finde.

Es scheint, als ob pipenv selbst bei Verwendung der json-Schnittstelle unnötige Anfragen nach Wheel-Dateien stellt, die sich auf verschiedene Architekturen beziehen. Die Implementierung ist derzeit insofern ziemlich naiv, als sie alle aufgelisteten Dateien mit einer bestimmten Version abgleicht, unabhängig von der Zielplattform / dem Arch.

Minimaler Testfall:

Auf einem Linux-Host: pipenv install grpcio

Folgende Anfragen wurden erstellt (erfasst mit mitmproxy ):

$ mitmdump -w dump.out
Proxy server listening at http://*:8080
127.0.0.1:62303: clientconnect
127.0.0.1:62303: GET https://pypi.org/simple/setuptools/
              << 200 OK 79.82k
127.0.0.1:62305: clientconnect
127.0.0.1:62305: GET https://files.pythonhosted.org/packages/7f/e1/820d941153923aac1d49d7fc37e17b6e73bfbd2904959fffbad77900cf92/setuptools-39.2.0-py2.py3-none-any.whl
              << 200 OK 554.25k
127.0.0.1:62303: GET https://pypi.org/simple/pip/
              << 200 OK 9.56k
127.0.0.1:62303: GET https://pypi.org/simple/wheel/
              << 200 OK 6.91k
127.0.0.1:62303: clientdisconnect
127.0.0.1:62305: clientdisconnect
127.0.0.1:62307: clientconnect
127.0.0.1:62307: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62309: clientconnect
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62307: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62309: clientdisconnect
127.0.0.1:62307: clientdisconnect
127.0.0.1:62311: clientconnect
127.0.0.1:62311: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62313: clientconnect
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62311: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62315: clientconnect
127.0.0.1:62315: GET https://pypi.org/pypi/six/json
              << 200 OK 5.94k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
              << 200 OK 29.16k
127.0.0.1:62315: GET https://pypi.org/pypi/grpcio/json
              << 200 OK 164.26k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5c/73/5e65b81301956bdd32c5e8da691fde3fbd6e61283b65d2bac590b8f43765/grpcio-1.12.1-cp27-cp27m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/e1/c3/bcce8247da4e6f95a900489b6f7ff3d14d93df40d69875fe4164c1b9544a/grpcio-1.12.1-cp27-cp27mu-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/ed/89/03924c56e9044b0842a014fcc0a81f55975028d1caa9cdd14234a230bc70/grpcio-1.12.1-cp27-cp27m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/d7/f6/ddeab13c25b8451f05875587801ad87e4e0fc23c4e3eb328c4bd1a80a415/grpcio-1.12.1-cp36-cp36m-linux_armv7l.whl
              << 200 OK 7.77m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2d/a4/4d1d73c0339e987ea173f44cf62ec6b40fb91e0336c09c960c4a44137552/grpcio-1.12.1-cp35-cp35m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/76/27/b03ec8fc96745cde68d6ec29115f9a444945a6acc45209c5772378cc4d66/grpcio-1.12.1-cp35-cp35m-macosx_10_7_intel.whl
              << 200 OK 1.83m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/30/24/8e247548321e52c266a639b51a838ec19b41fb6bfd27e3bbef018496752e/grpcio-1.12.1-cp27-cp27m-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/80/c9/e582b962a4a3aa2684666ff67fc994a042b1b0e444eb6672eb9740f7b59a/grpcio-1.12.1-cp34-cp34m-macosx_10_7_intel.whl
              << 200 OK 1.84m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/a2/25/6d910070a4a07c32633c2376075d5dc03e90f69f855d700e3f73c1affebb/grpcio-1.12.1-cp27-cp27m-macosx_10_12_x86_64.whl
              << 200 OK 1.57m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/33/38/58f3e8d133de1f2e911206ead03799621205079c303ae5b27e7350051f4a/grpcio-1.12.1.tar.gz
              << 200 OK 13.56m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/68/57/da122cbfc1b7815381480b23044fff06b90f58c1be9310e68c2d6b1d623c/grpcio-1.12.1-cp36-cp36m-macosx_10_7_intel.whl
              << 200 OK 1.82m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/c6/b8/47468178ba19143e89b2da778eed660b84136c0a877224e79cc3c1c3fd32/grpcio-1.12.1-cp35-cp35m-manylinux1_x86_64.whl
              << 200 OK 8.55m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5d/8b/104918993129d6c919a16826e6adcfa4a106c791da79fb9655c5b22ad9ff/grpcio-1.12.1-cp36-cp36m-win_amd64.whl
              << 200 OK 1.37m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/94/6c/02e9cb803cd7b9608c9c1768d86d31c61b088f5b9513a203c10fa7e905d8/grpcio-1.12.1-cp36-cp36m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2a/ed/71169dccb7f9250d17031068579832371a72891d8e64891265370ca6e264/grpcio-1.12.1-cp27-cp27mu-linux_armv7l.whl
              << 200 OK 7.68m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/63/38/d73bf5b1ef950dbab8203122b9681137b35012492ecfec56719be109e343/grpcio-1.12.1-cp27-cp27m-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/13/71/87628a8edec5bffc86c5443d2cb9a569c3b65c7ff0ad05d5e6ee68042297/grpcio-1.12.1-cp36-cp36m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1d/0d/146582f71161a0074dda2378617ae5f7e2c3d6cf62d4588eb586c1d6b675/grpcio-1.12.1-cp27-cp27mu-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/9e/3a/6aceb4fccacf6d2d7d087190c221a90f14b2bdcb56cbee5af24b7050278b/grpcio-1.12.1-cp34-cp34m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f9/fa/a0187d220544b744dd3bb0d8b8ec716d130159160bf627415b2880ae599a/grpcio-1.12.1-cp34-cp34m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/dd/aa/ac8e3c6badf1744f04be7d35fa95dae56df12b956f861285c8cced2a22cb/grpcio-1.12.1-cp34-cp34m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/38/2a/94665daafbcf0214adcf77ad8f5aed8b9dfcbfa871115c7890d88b1b8f3c/grpcio-1.12.1-cp34-cp34m-manylinux1_x86_64.whl
              << 200 OK 8.58m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/0d/33/22ad4a9dcefe330180cdb2d24fdd980af2a7a2dc03af208a408fd48195e0/grpcio-1.12.1-cp35-cp35m-win_amd64.whl
              << 200 OK 1.36m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/b5/13/9e8e5d68a15c51b251e512955a971214fd8425b237e6d6a04f0257c5d090/grpcio-1.12.1-cp34-cp34m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/21/41/66ab386c65be68b4e907f2cd35223965aea2a086bcd0bd6825999e0bda7c/grpcio-1.12.1-cp35-cp35m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f7/db/fc084f59804a32a8d6efb467896a505f4dc93ea89ec44da856b91f05a5cb/grpcio-1.12.1-cp35-cp35m-manylinux1_i686.whl
              << 200 OK 8.09m
127.0.0.1:62313: clientdisconnect
127.0.0.1:62311: clientdisconnect
127.0.0.1:62315: clientdisconnect

Zählen Sie einige der unnötigen Anfragen zusammen:

• 4 x win32
• 4 x Arm
• 4 x macosx

Etc. Scheint ein schneller Erfolg zu sein, um einige einfache Filterungen basierend auf Host-Betriebssystem und Arch durchzuführen?

Sie möchten, dass die Dinge nach Host und Architektur gefiltert werden, die meisten anderen möchten eine Sperrdatei, die Hashes enthält, die es ihnen ermöglichen, auf diesen Hosts und Architekturen zu installieren (wir haben eine beträchtliche Anzahl von Hacks in der Pip-Resolver-Codebasis, die dies speziell ermöglichen, also ist es nicht so.) Neuigkeiten für uns)

In Bezug auf die JSON-API ist sie in der aktuellen Version nicht direkt aktiviert, und ich plane, sie vor der Veröffentlichung in der Codebasis wieder zu deaktivieren. Ich habe umfangreiches Profiling durchgeführt und weiß, dass fehlgeschlagene Aufrufe von packaging.version.parse() etwa 20-50% der Laufzeit von pipenv ausmachen.

Pip 10 verwendet jedoch standardmäßig die JSON-API als Hauptresolver. Wenn Sie also nicht aufhören möchten, pip zu verwenden, gibt es an dieser Front nicht viel zu tun.

Ich habe das Gefühl, dass wir die gleichen Dinge mehrmals herunterladen müssen, oder?

Wir sollten die Diskussion wahrscheinlich auf #2284 verschieben. Es ist tatsächlich der Sperrteil, der langsam ist ( install ist im Wesentlichen TOML-Manipulation + lock + sync ), nicht installiert.

Bezüglich der Sperrung auf einen einzelnen Bogen. Ich verstehe die Designwahl; könnte es vielleicht eine Option geben, ein Flag zu übergeben, um einem Benutzer zu ermöglichen, nur für die Host-Architektur zu sperren? Dies wäre eine ziemlich bedeutende Optimierung sowohl in Bezug auf Zeit als auch Bandbreite für einige Anwendungsfälle.

@techalchemy danke für deine Antwort. Der Fund von packaging.version.parse() scheint eine gute Spur zu sein. Könnten Sie dieser Aussage etwas mehr Farbe verleihen:

In Bezug auf die JSON-API ist sie in der aktuellen Version nicht direkt aktiviert, und ich plane, sie vor der Veröffentlichung in der Codebasis wieder zu deaktivieren.

Ich habe nicht verstanden, warum Sie planen, es zu deaktivieren?

@jkp In Bezug auf die JSON-API sagen wir einfach, dass sie nicht das beste Design auf dem einfache API ist für uns viel besser geeignet. Durch die Deaktivierung verwenden wir die einfache API und nicht vollständig keine APIs.

Die Installation von Pyspark dauert zu lange.
Mein Pipfile -

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

[dev-packages]
pylint = "*"
pyspark = "*"

[requires]
python_version = "3.5"

Shell-Ausgabe -

Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...

Der Prozess hängt in der letzten Zeile oben fest.
Ende nach 15-20 Minuten

pipenv, Version 2018.7.1

@keshavkaul PySpark ist sehr groß und das Herunterladen kann einige Zeit in Anspruch nehmen. Gib ihm etwas Zeit, danach wird es viel besser (weil Pipenv das Ergebnis zwischenspeichert).

(Oder Sie können die Entwickler auffordern, eine Radverteilung zu veröffentlichen. Das würde ein bisschen helfen.)

Hinweis für zukünftige Besucher: Bitte sehen Sie davon ab, Ihr langsames Installationsergebnis zu veröffentlichen. Wir wissen, dass es langsam sein kann. Wir wissen, warum es langsam ist. Ihr Ergebnis fügt diesem Thema nichts hinzu.

Wäre es möglich, während des Downloads der Bibliotheken einige Informationen oder Fortschrittsbalken wie apt-get oder wget (Download-Geschwindigkeit, heruntergeladene Größe, Gesamtgröße) anzuzeigen?
Ich denke, das ist hier das Problem, pipenv schien mir langsam, aber es war nur der Download der Bibliothek. Ich musste einen Systemmonitor öffnen, um zu verstehen, dass pipenv die Dateien herunterlädt und wie viel bereits heruntergeladen wurde, welche Geschwindigkeit usw

Hava gleiches Problem: Locking [packages] dependencies... bleibt für immer hängen
mein Umfeld:

• macOS High Sierra 10.13.6
• Python: Python 3.6.4
• pipenv: Version 2018.7.1

@crifan Es ist nicht erforderlich, bei jedem geöffneten oder geschlossenen Problem die gleiche Nachricht zu posten, in der die

Hier gilt das gleiche. Pipenv sehr langsam.
Das Sperren und Installieren dauert eine Stunde.

Ich denke, dieses Problem wurde hier gut beantwortet: https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

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.

• von @techalchemy

Wäre es möglich, die Liste der Hashes von der PyPI-API abzurufen, anstatt sie selbst zu berechnen?

pipenv ist großartig, aber dieses Problem scheint immer noch zu bestehen. freut sich über jeden Fortschritt. --skip-lock hat nicht funktioniert.

pipenv ist großartig, aber dieses Problem scheint immer noch zu bestehen. freut sich über jeden Fortschritt. --skip-lock hat nicht funktioniert.

Hat bei mir funktioniert

Ich fand, dass die Verwendung von Git Bash unter Windows im Vergleich zu Powershell sehr langsam war. Ich habe keine Statistiken oder Daten dazu, aber PS schien schneller zu sein. Wenn Sie also Git Bash verwenden, sollten Sie das native PS für pipenv 'ing ausprobieren.

Ich weiß, dass dieses Problem geschlossen ist, aber für mich dauert die Installation von Pandas viel Zeit. Die ausführliche Ausgabe ist dies

pipenv install pandas --verbose
Installing pandas…
⠋ Installing...Installing 'pandas'
$ ['/Users/sinscary/.local/share/virtualenvs/signzy-MSzur11z/bin/pip', 'install', '--verbose', '--upgrade', 'pandas', '-i', 'https://pypi.org/simple']
Adding pandas to Pipfile's [packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
⠦ Locking...

Es bleibt mehr als 30 Minuten bei Locking hängen. Ich verwende Python 3.7.0, Macos Mojave. Jede Hilfe dabei.

Warum sind alle Ausgaben zu diesem Thema geschlossen? Ich kann aufgrund des Lock-Step-Hangs keine einzige Sache installieren.

Das folgende Docker-Image braucht mehr als 30 Minuten, um auf meinem Laptop (i7/16Gb) zu bauen, der Befehl pipenv install ... läuft ewig...

Dockerfile

FROM python:3.7-alpine

# Update package list.
RUN set -ex && apk update

# Install apk dependencies.
RUN set -ex && apk add --no-cache musl-dev gcc libffi-dev openssl-dev make

# Install Pipenv.
RUN set -ex && pip install pipenv --upgrade

# Copy Pipfiles.
RUN mkdir /website
COPY Pipfile /website

# Install Pipenv dependencies.
WORKDIR /website
RUN set -ex && pipenv install --system --skip-lock --verbose

Pipfile

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


[requires]
python_version = "3.7"

[packages]
sanic = "*"
jinja2 = "*"
asyncpg = "*"
uvloop = "*"
munch = "*"

[dev-packages]

[pipenv]
allow_prereleases = true

Ist das normal? Kann jemand reproduzieren?

Update: Seien Sie vorsichtig mit Alpine Linux

Mir wurde klar, dass das Problem nicht auf der Seite von pipenv liegt...

Ich habe das Docker-Image der Alpine- Basis durch eines ersetzt, das auf Debian-Slim basiert und jetzt ist pipenv install innerhalb von Sekunden fertig.

Das Problem in meinem Beispiel ist, dass Alpine Linux immer versucht, Pakete zu erstellen, die cython-extension oder c-extensions aus dem Quellcode enthalten, was in einem Docker-Container ewig dauern kann, während Debian Linux sie mit dem wheel installiert

Mehr dazu: https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

Ich habe Pipenv schon lange verlassen und immer wenn ich eine virtuelle Umgebung erstellen muss, verwende ich "venv" oder andere Optionen.

Ich habe auch ein seltsames Langsamkeitsproblem, nur 2 Module für einige Skripte, die ich mache.

click

Die Installation dauerte 15/20 Minuten, Internettests mit über 60 Mbit/s Down und auf einem aktuellen MacBook Pro 2019 (nicht meine Hardware-Wahl).

Bitte nutzen Sie vorerst virtualenv. bis bessere Lösung verfügbar

In 99% der Fälle werden die Abhängigkeiten in meiner Sperrdatei in dieselbe aufgelöst, weil sie Teil meiner Entwicklungspipeline ist.

Falls es seit dem letzten Lauf keine neuen Upstream-Pakete gibt, könnte der Vorgang sicher übersprungen werden ?