<p>L'installation de pipenv est très lente</p>

Hé encore @Diggsey , cela est dû à la façon dont nous écrivons les changements en ce moment. J'ai ces modifications prêtes à être fusionnées, mais elles sont en rupture pour l'API projects.py , nous allons donc attendre jusqu'à la prochaine version majeure. Espérons que nous aurons cela en place et prêt dans les prochaines semaines. Je vais laisser cela ouvert pour suivre le problème pour le moment.

Nous avons sprinté ensemble à PyCon. Ce sera bientôt plus rapide.

En ce moment pour moi ce n'est pas lent, il gèle...

Un pipenv install my_package ou un simple pipenv install ne me donne aucune sortie, après 20 minutes.

EDIT : Confirmation, toujours rien au bout de quelques heures. Est-ce le même problème ? Habituellement, c'était lent, mais cela s'est terminé après 5 à 10 minutes.

Salut @NicolasWebDev , quelle version de pipenv utilisez-vous ? Avez-vous également delegator.py installé sur votre système séparément ? Si oui, à quelle version s'agit-il ? C'était un problème qui aurait dû être résolu dans la version 3.6.0.

Si tout ce qui précède est à jour, pourriez-vous s'il vous plaît fournir le contenu de votre Pipfile ? Merci!

Salut @nateprewitt , tu avais raison, j'étais sur v3.5.x. La mise à jour vers 4.1.1 a résolu le problème de gel. Maintenant, cela prend encore 5 minutes, mais au moins c'est utilisable !

Désolé pour le bruit, j'oublie toujours que les packages installés via pip ne sont pas automatiquement mis à jour.
Merci!

Heureux que les choses se résolvent @NicolasWebDev ! Nous travaillons à accélérer encore plus cela, espérons-le #373 sera un pas de plus dans la prochaine version.

@Diggsey @NicolasWebDev , je viens de publier 4.1.2 qui devrait avoir ces améliorations de vitesse ajoutées. Il y a encore du travail à faire ici, mais cela accélérera au moins le temps d'amorçage initial de pipenv.

@nateprewitt Merci pour la mise à jour, pipenv me semble plus rapide maintenant, mais cela prend encore plusieurs minutes juste pour exécuter pipenv lock , même si rien n'a changé - il attend toujours dans Locking [packages] dependencies... pour le vaste majorité de ce temps.

@Diggsey , une grande partie de ce temps est due au téléchargement d'un grand nombre de fichiers dans ce Pipfile. Il semble que vous épinglez également toutes vos dépendances. Importez-vous directement tous ces éléments dans votre projet ou existe-t-il des exigences de dépendance des autres ?

@nateprewitt Nous pourrions en supprimer certains, mais la majorité sont des dépendances directes - pourquoi a-t-il besoin de télécharger toutes les dépendances chaque fois qu'il génère le fichier de verrouillage ?

Nous devons déterminer tout ce qu'il installe en tant que dépendances. Pour obtenir cela, nous téléchargeons chaque package et déterminons à quoi ressemble une installation au moment du verrouillage. Cela nous permet de tout épingler de manière appropriée dans le Pipfile.lock. Sans téléchargement, il n'existe pas de moyen fiable de vérifier les sous-dépendances et de résoudre les déclarations de dépendances de plage.

Étant donné que la plupart des packages vont rester les mêmes au fil du temps, serait-il possible de mettre en cache les packages téléchargés ?

@Diggsey veut-il examiner cela pour nous ?

C'est peut-être une question idiote, mais Pip ne fait-il pas déjà la mise en cache des packages ?

J'ai l'impression que oui.

Pipenv peut-il utiliser le système de cache pip ou doit-il être implémenté à partir de zéro ?

Pipenv exécute juste pip, donc le cache doit être automatiquement utilisé.

fixé! la serrure est méchante rapide maintenant.

Oh merci. Je pense que c'était la seule chose qui m'empêchait de pousser tout le monde à pipenv au travail.

Wow, sympa, c'était littéralement plus d'une accélération de 100x pour moi, et cela a également détecté un conflit de dépendance que la version précédente n'a pas détecté !

Ce qui serait utile, c'est un indicateur verbose pour pipenv lock - je n'ai pu diagnostiquer le conflit de dépendance qu'en éditant piptools/logging.py pour activer la journalisation détaillée, mais une fois que je l'ai fait, cela a donné une indication très claire de ce qui se passait.

Il me manque probablement quelque chose :) Où est-ce résolu ? La dernière version date de 4 jours, j'ai donc installé la dernière version de master . Cependant, pipenv install est toujours lent.

J'ai essayé:

• installez pipenv manière sophistiquée ⚡️ 🍰 ⚡️
• utilisez à la fois la dernière version publiée de pipenv et la dernière version de master
• installer un seul paquet

En utilisant la dernière version stable (5.3.5.), il faut 3h40 pour installer un paquet :

∙ 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

En utilisant la version de master , il se bloque toujours (un paquet, +10 minutes)

EDIT : il vient de se terminer :

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

Des idées? Merci beaucoup!

Parfois, les dépendances prennent un certain temps à s'installer, surtout si elles ont des compilations en C. Envie de partager votre Pipfile ?

Je comprends que parfois cela prend du temps, mais c'était lent dès le début. Juste curieux de savoir si c'est un problème de mon côté.

Voici mon 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 peut prendre un certain temps, car il peut être compilé à partir de la source. Tout le reste devrait être agréable et rapide. Essayez de le supprimer et voyez à quel point votre vitesse augmente.

$ pipenv install raven vient de prendre comme 1s pour moi.

$ pipenv install raven a juste pris comme 1s pour moi.

C'est ce à quoi je m'attendrais ! Puis-je activer la sortie détaillée d'une manière ou d'une autre ?

J'ai essayé de supprimer psycopg2 , mais cela n'affecte pas grand-chose. L'exécution de pipenv install raven bloque pendant un certain temps.

J'ai:

• Python 3.6.2
• macOS 10.12.6

Je ne vois aucune raison pour laquelle le corbeau ne devrait pas être instantané.

faites $ pip install raven intérieur de $ pipenv shell et dites-moi si c'est lent là aussi.

Tout ce que pipenv fait est d'exécuter pip, c'est donc effectivement le "mode verbeux"

C'est instantané :

∙ 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

L'exécution de pipenv bloque environ 2-3 minutes (à l'intérieur/à l'extérieur de 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 pouvez-vous ouvrir un nouveau numéro sur --verbose et fournir un exemple de ce à quoi vous voudriez qu'il ressemble ?

@ tricoder42 la partie lente est-elle l'étape de verrouillage ou l'étape d'installation ? Le verrouillage a été considérablement amélioré dans les dernières versions.

```coquille
$ temps pipenv installer corbeau
Installation du corbeau...
Collectionneur de corbeau
Utilisation de raven-6.1.0-py2.py3-none-any.whl en cache
Exigence déjà satisfaite : contextlib2 dans /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (de raven)
Installation des paquets collectés : corbeau
Raven-6.1.0 installé avec succès

Ajout de corbeau aux [packages] de Pipfile...
Verrouillage des dépendances [dev-packages]...
Verrouillage des dépendances [des packages]...
Pipfile.lock mis à jour !
9.30 réel 5.49 utilisateur 0.42 sys

C'est comme 50:50 i nstalling:locking

@ tricoder42 et vous utilisez le dernier ?

Permettez-moi de reproduire avec votre pipfile exact.

Je suppose:

∙ 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

```coquille
$ temps d'installation de pipenv
Aucun package fourni, installation de toutes les dépendances.
Pipfile trouvé dans /Users/kennethreitz/pipenv/testapp/Pipfile. Considérant qu'il s'agit de la maison du projet.
Pipfile.lock introuvable, création...
Verrouillage des dépendances [dev-packages]...
Verrouillage des dépendances [des packages]...
Pipfile.lock mis à jour !
Installation des dépendances à partir de Pipfile.lock...
[================================] 22/22 - 00:00:37
58.94 réel 40.51 utilisateur 8.62 sys

Il le fait même lorsque j'installe le premier package dans un nouveau pipenv. Je vais essayer de créer pipenv --three au lieu de pipenv --python python3.6

@ tricoder42 voulez-vous sauter sur un environ ?

Ou nous pouvons utiliser le partage d'écran Apple si vous utilisez Messages.app.

Ajoute moi! Je suis [email protected].

Je suis sur le point de rejoindre une réunion, mais je serai disponible après cela.

Cool! Je vais essayer de nettoyer et de tout réinstaller à partir de zéro et nous verrons. je suis disponible dans une heure

Génial - nous allons le découvrir alors. Ajoutez-moi sur messages.app :)

Si quelqu'un éprouve un comportement extrêmement lent de Locking avec v11.9.0 , j'ai trouvé que la rétrogradation à v9.0.0 prend une installation de 5m30s jusqu'à 1m36s.

@ryantuck Je recommanderais si vous allez épingler une ancienne version pour épingler 9.0.3 mais vous perdez une quantité importante de sécurité supplémentaire pour la vitesse, vous pourriez aussi bien utiliser --skip-lock à ce point

--skip-lock définitivement accéléré les choses. J'ai emprunté ce chemin parce que pipenv install --system --python=3.6 n'était pas réellement installé sur le bon système python, et je supposais que je devais générer le Pipfile.lock avant de tenter l'installation du système. Cela n'a toujours pas fonctionné, alors je suis revenu à l'ancien pip , mais je commenterai ce fil si jamais je progresse dans ce sens.

—system et —python sont mutuellement exclusifs — cette dernière option a toujours besoin d'un virtualenv

oui, le verrouillage prend du temps pour moi aussi. v11.10.0. Ubuntu sur 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

Cela devrait être un peu plus rapide la deuxième ou la troisième fois à cause de
mise en cache tho. Voyez-vous une amélioration?
Le jeu. 12 avril 2018 à 10:23 Alexander Kavanaugh <
[email protected]> a écrit :

oui, le verrouillage prend du temps pour moi aussi. v11.10.0. Ubuntu sur 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- 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"corbeau = "==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"serveuse = "==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"
[nécessite]python_version = "3.6"

Pipfile.lock introuvable, création…
Verrouillage des dépendances [dev-packages]…
Verrouillage des dépendances [des packages]…
Mise à jour de Pipfile.lock (7a535c) !
Installation des dépendances à partir de Pipfile.lock (7a535c)…
▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

réel 8m1.993s
utilisateur 5m32.406s
système 7m15.203s

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pipenv/issues/356#issuecomment-380882203 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

J'avais déjà installé les packages avant cela ; Je viens de supprimer le fichier de verrouillage et de relancer l'installation. Je vais le refaire pour obtenir un autre point de données

@jtratner Woah. Super intéressant... qu'est-ce qui fait que la mise en cache ne démarre qu'après la troisième fois ou plus ?

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 a introduit une fonctionnalité pour mettre également en cache les hachages, ce qui devrait apporter une amélioration considérable

Me voici... 15 minutes plus tard

@giantas pas utile. Veuillez fournir le fichier pip, la sortie et la durée avec l'installation de pip. Aussi si vous pouvez faire des packages individuels.

Il en faut beaucoup pour fonctionner sur ma machine. macOS 10.13.4, pipenv, version 11.10.0

Le téléchargement s'exécute presque immédiatement, mais il reste bloqué sur Locking [packages] dependencies… . Voici prendre une demi-minute pour deux dépendances, puis 6 minutes pour 3 autres dépendances, si je lance toutes les dépendances de mon projet, il se bloque indéfiniment à l'étape de verrouillage

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 sainte merde qui est lente! Notez que cela est en partie dû à l'installation de numpy, que je suis sûr que nous compilons probablement de la source à la serrure ou à quelque chose de stupide. aiderait si nous fournissions une sortie utile ici

Y a-t-il quelque chose que je puisse faire à ce sujet ? ou est-ce que je n'ai tout simplement pas de chance d'utiliser pipenv et d'avoir ces temps de fichier de verrouillage lents? Je suppose que je pourrais --skip-lock mais je voulais en quelque sorte cette fonctionnalité

@pablote pouvez-vous vérifier si vous réexécutez la même opération de verrouillage, est-ce toujours lent?

Si je le réexécute, il se termine presque immédiatement, donc je suppose que ce n'est que la première fois qu'une nouvelle dépendance est ajoutée.

il met donc en cache les hachages localement, donc pour une raison quelconque, c'est le processus de génération de hachage qui est incroyablement lent ici...

Faites-moi savoir s'il y a des informations que je peux fournir pour aider à diagnostiquer. Pour le moment je vais juste revenir sur pip + virtualenv + pip-tools :/

@pablote une fois que vous avez les hachages une fois, le verrouillage à nouveau ne sera pas si lent

S'il vous plaît, veuillez fournir une sortie utile. Je viens de mettre à niveau mon pipenv de 9.1.0 à 11.10.0 afin de résoudre l'échec du marqueur non valide à l'étape de verrouillage du package, par exemple, #1622 --- maintenant, j'ai un pipfile avec ipykernel, pandas, jupyter, numpy, et matplotlib là-dedans et avec ma dernière tentative d'utiliser pipenv install pour lancer le fichier de verrouillage, je suis resté assis dans locking [packages] dependencies… pendant plus de 10 minutes.

Parce qu'il n'y a pas de sortie, je ne peux pas dire s'il y a quelque chose qui se passe réellement (comme construire numpy à partir de la source) ou si c'est juste suspendu. Le mieux que je puisse faire est de loucher sur top et de conclure que cela fait peut-être quelque chose parce qu'un processus python semble traîner ... mais je vais devoir supprimer ce virtualenv et recommencer à zéro si quelque chose ne bouge pas de sitôt.

Je suis heureux de contribuer à certains travaux sur ce si nécessaire.

S'il vous plaît, veuillez fournir une sortie utile. Je viens de mettre à niveau mon pipenv de 9.1.0 à 11.10.0 afin de résoudre l'échec du marqueur non valide à l'étape de verrouillage du package, par exemple, #1622 --- maintenant, j'ai un pipfile avec ipykernel, pandas, jupyter, numpy, et matplotlib là-dedans et avec ma dernière tentative d'utilisation de pipenv install pour lancer le fichier de verrouillage, je suis resté assis dans le verrouillage des dépendances [packages]… pendant plus de 10 minutes.

Plainte tout à fait compréhensible et j'ai mijoté dans le fond de mon esprit en essayant de réfléchir à la façon dont nous pouvons fournir des commentaires plus utiles à l'utilisateur (parce que je suis d'accord que c'est un peu déroutant qu'il n'y ait aucun résultat). J'abandonnerais au bout de 15 minutes. Comme @techalchemy l'a souligné, chaque fois que votre cache devrait être peuplé un peu plus, il devrait donc être constamment plus rapide au fil du temps.

Une question : utilisez-vous PyPI public ?

@jtratner oui, en utilisant PyPi public --- et j'ai fini par abandonner, saccager le virtualenv et en construire un nouveau; J'ai réussi à créer un fichier de verrouillage en installant mes dépendances une par une. (Fait intéressant, matplotlib était le plus lent --- encore pire que numpy !)

Peut-être qu'un message comme This may take a long time aiderait à rassurer les gens jusqu'à ce qu'une solution plus claire soit décidée.

15 minutes, c'est toujours incroyablement long, je doute que je m'assoie et l'attende. @paultopia vous pouvez exécuter pipenv lock —verbose pour plus de sortie

Il a l'impression générale d'être plus lent qu'il ne devrait l'être, mais je sous-estime peut-être le problème. Si je regarde les processus en cours d'exécution sur mon ordinateur, je peux voir le python s'exécuter tout le temps que pipenv est en cours d'exécution, et il ne dépasse jamais ~ 15%, il devrait probablement en utiliser davantage s'il effectue un travail intensif en CPU comme le hachage de fichiers . De plus, j'ai utilisé d'autres gestionnaires de packages qui hachent les dépendances, comme le fil, et ils sont assez rapides.

Il faut savoir ce qu'il fait...

J'ai créé un projet github montrant la lenteur lors de l'utilisation du verrouillage. Veuillez consulter https://github.com/AndreasPresthammer/slow-pipenv . Je ne suis pas sûr à 100% que ce soit le même problème cependant. Déroulez le référentiel et exécutez le script slow.sh, et observez la différence de temps d'exécution.

@AndreasPresthammer donc votre script ne fait que chronométrer un verrou non mis en cache par rapport à l'installation avec verrou. On sait que c'est le verrouillage mais c'est lent. Dans le cas de numpy, c'est probablement parce qu'il a dû utiliser des sdists pour la résolution dans le passé, ce qui signifiait une compilation. Nous pouvons utiliser des roues maintenant. ça peut accélérer les choses

C'est certainement toujours un problème (5 minutes et plus), avec les dernières versions de python3.6, pip et pipenv, et l'installation d'un package simple comme torch . Je ne pense pas que ce problème doive être marqué comme clos.

Pour tous ceux qui souhaitent commenter la fermeture de ce problème : fournissez la sortie de pipenv lock --verbose . Nous savons que la résolution est lente pour les packages qui sont compilés à partir des sources et qui prennent beaucoup de temps à construire dans des conditions normales. Nous avons besoin de journaux pour mieux comprendre la cause si cela est plus lent que la normale.

J'utilise également Docker pour mon environnement de développement et de production et je pense que l'installation à l'intérieur de Docker est lente, par rapport à l'installation sur l'hôte. C'est peut-être juste la combinaison de tous les packages, mais j'aimerais entendre les commentaires de personnes plus expérimentées que moi.

Voici le log de pipenv lock --verbose , incluant les Pipfile et Pipfile.lock :

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

@mimischi Les résultats de la résolution sont mis en cache dans l'hôte, mais Docker ne peut pas y accéder. Il est lent car il doit refaire toute la résolution à partir de zéro. Cela aiderait si vous montiez le répertoire de cache de l'hôte dans Docker. Il y a un commentaire dans un numéro mentionnant le chemin que vous devez monter. Je n'ai pas le temps de chercher maintenant, mais vous pouvez essayer de le trouver. (Et s'il vous plaît, contribuez-le à la page FAQ du document lorsque vous le faites !)

FWIW, le verrouillage de ma boîte de développement prend maintenant moins de 30 secondes. Beaucoup mieux qu'avant - appréciez-le.

Salut, j'ai le même problème.
voici le verbeux

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…

Voici le pipenv --version : pipenv, version 2018.05.18

De plus, je ne sais pas pourquoi cela se produit, aucune raison/erreur spécifique ne se produit.
Dans mon cas, quand je fais pipenv lock ça commence mais ça ne se termine jamais pour autant que je sache. J'attends depuis 2 heures maintenant toujours aucun signe d'achèvement. Et m'a donné ReadTimeoutError deux fois, c'est la troisième fois que je fais cela.
Utiliser Python 3.6.4

Toute aide serait d'une grande aide car la date d'échéance de mes projets est proche.

Votez également pour que cette question soit rouverte. C'est loin d'être résolu... prendre entre 10 et 20 minutes pour verrouiller mon projet dans un conteneur Docker. Il utilise également une quantité insensée de mémoire - de sorte que j'ai dû augmenter l'allocation à Docker pour l'empêcher de tuer le processus.

Veuillez fournir des exemples de Pipfiles et des détails sur vos environnements si vous souhaitez de l'aide pour résoudre les problèmes de vitesse de résolution. Nous réduisons une version cette semaine et n'avons pas le temps de suivre les commentaires ponctuels individuels sur les discussions fermées, mais nous pouvons tester avec Pipfiles si vous en fournissez un

@jkp Permettez-moi de vous assurer que chaque développeur principal de ce projet (pas que nous soyons nombreux pour commencer) est très conscient de ce problème et en est aussi troublé que vous, sinon plus. Cependant, ce n'est en aucun cas un problème facile, et nous avons déjà tout mis en œuvre pour le rendre aussi utilisable que possible, sans avoir à tout démonter dans l'emballage Python. Nous avons également beaucoup à faire en ce moment et devons également nous concentrer sur ces autres problèmes. La décision inévitable que je dois prendre, alors, est de hiérarchiser les problèmes que nous savons réellement résoudre, et de ne commencer à penser à nos prochaines étapes qu'une fois celles-ci terminées, afin de maximiser l'effet de nos efforts.

Maintenant, je reconnais pleinement que votre priorité peut être différente de la nôtre. Ce problème de performances peut être le problème le plus important de votre flux de travail et vous souhaitez le présenter comme la chose la plus importante de ce projet. Veuillez cependant garder à l'esprit que vous n'êtes pas le seul utilisateur de cet outil et que nous devons prioriser le besoin de tous, même le nôtre , avant le vôtre. Je le reconnais. J'exhorte donc tous ceux qui partagent la situation à se concerter sur cette question et à essayer de réfléchir à un moyen de la résoudre. Une fois que nous savons quoi faire, nous pouvons le faire.

Le problème est maintenu fermé car nous ne savons pas ce que nous pouvons faire et ne servirait que de bruit dans le traqueur de problème lorsque nous essayons de le gérer. Il ne sert à rien, du moins dans notre flux de travail, d'avoir un problème sur lequel personne ne peut travailler.

Appréciez votre flux de travail, donc si c'est ainsi que vous gérez les problèmes, ce n'est pas grave. Je vais essayer d'ajouter toutes les informations que je peux pour aider à traquer le problème.

J'ai fait du débogage en installant mitmproxy entre pipenv et le net pour tracer les requêtes en cours. J'ai trouvé quelques choses intéressantes.

1. Nous utilisons un index privé pypi qui ne prend pas encore en charge le json-api . Cela ralentit considérablement les choses car il semble que la solution de secours consiste à forcer brutalement et à télécharger tout ce qui est répertorié dans l'index http afin d'extraire les métadonnées, etc. Une suggestion ici serait simplement d'ajouter une simple journalisation pour avertir que cette méthode de secours est utilisée - elle pourrait éviter à quelqu'un d'autre d'avoir à creuser plus profondément pour comprendre cela.

2. En utilisant la méthode de force brute, il semble que le code télécharge des packages qui ne sont pas pertinents pour l'architecture utilisée. Par exemple, sur une machine Linux, il téléchargeait win32 ou osx des packages de roues spécifiques. Cela ressemble à quelque chose qui pourrait être détecté et évité car il est clair que les packages binaires construits pour d'autres architectures ne seront d'aucune utilité.

Je continuerai à déboguer et à rapporter toute information utile au fur et à mesure que je la trouverai.

Il semble que même avec l'interface json utilisée, pipenv fasse des demandes inutiles de fichiers de roue liés à différentes architectures. L'implémentation est actuellement assez naïve dans la mesure où elle vérifie tous les fichiers répertoriés par rapport à une version donnée, quelle que soit la plate-forme / l'arch cible.

Cas de test minimal :

Sur un hôte Linux : pipenv install grpcio

A produit les requêtes suivantes (capturées à l'aide de 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

Compter certaines des demandes inutiles :

• 4 x win32
• 4 bras
• 4 x macosx

Etc. Cela semble être une victoire rapide pour effectuer un filtrage simple basé sur le système d'exploitation hôte et l'arch ?

Vous voulez que les choses soient filtrées par hôte et architecture, la plupart des autres veulent un fichier de verrouillage qui inclut des hachages qui leur permettront de s'installer sur ces hôtes et architectures (nous avons un nombre important de hacks dans la base de code du résolveur pip qui permettent spécifiquement cela, donc ce n'est pas nouvelles pour nous)

En ce qui concerne l'api JSON, elle n'est pas réellement activée pour frapper directement dans la version actuelle, et je prévois de la désactiver à nouveau dans la base de code avant de la publier. J'ai fait un profilage approfondi et je sais que les appels échoués à packaging.version.parse() représentent quelque chose comme 20-50% du temps d'exécution de pipenv.

Cependant, Pip 10 utilise l'API JSON par défaut comme résolveur principal, donc à moins que vous ne vouliez arrêter d'utiliser pip, il n'y a pas grand-chose à faire sur ce front.

J'ai l'impression que nous devons télécharger les mêmes choses plusieurs fois, n'est-ce pas ?

Nous devrions probablement déplacer la discussion au #2284. C'est en fait la partie verrouillage qui est lente ( install est essentiellement la manipulation TOML + lock + sync ), pas l'installation.

Concernant le verrouillage à une seule arche. Je comprends le choix de conception ; peut-être qu'il pourrait y avoir une option pour passer un indicateur pour permettre à un utilisateur de verrouiller uniquement pour l'architecture hôte ? Ce serait une optimisation assez importante à la fois en termes de temps et de bande passante pour certains cas d'utilisation.

@techalchemy merci pour votre réponse. La recherche de packaging.version.parse() semble être une bonne piste. Pourriez-vous mettre un peu plus de couleur sur cette déclaration :

En ce qui concerne l'api JSON, elle n'est pas réellement activée pour frapper directement dans la version actuelle, et je prévois de la désactiver à nouveau dans la base de code avant de la publier.

Je n'ai pas compris pourquoi vous envisagez de le désactiver?

@jkp En ce qui concerne l'API JSON, disons simplement que ce n'est pas la chose la mieux conçue qui soit. L' API simple nous convient beaucoup mieux. En le désactivant, nous utilisons l'API simple, et non aucune API.

L'installation de Pyspark prend trop de temps.
Mon Pipfile -

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

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

[requires]
python_version = "3.5"

sortie shell -

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

Le processus est bloqué sur la dernière ligne ci-dessus.
Termine après 15-20 minutes

pipenv, version 2018.7.1

@keshavkaul PySpark est très volumineux et le téléchargement peut prendre un certain temps. Donnez-lui un peu de temps, ce sera beaucoup mieux après (car Pipenv met en cache le résultat).

(Ou vous pouvez exhorter les développeurs à publier une distribution de roues. Cela aiderait un peu.)

Remarque pour les futurs visiteurs : veuillez vous abstenir de publier le résultat de votre installation lente. Nous savons que cela peut être lent. Nous savons pourquoi il est lent. Votre résultat n'ajoute rien à ce sujet.

Serait-il possible d'avoir des informations ou une barre de progression comme apt-get ou wget (vitesse de téléchargement, taille téléchargée, taille totale) lors des téléchargements des bibliothèques ?
Je suppose que c'est le problème ici, pipenv me semblait lent mais c'était juste le téléchargement de la bibliothèque, j'ai dû ouvrir un moniteur système pour comprendre que pipenv téléchargeait les fichiers et combien avait déjà été téléchargé, à quelle vitesse, etc.

j'ai le même problème : Locking [packages] dependencies... bloquer pour toujours
mon environnement :

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

@crifan il n'est pas nécessaire de poster le même message sur chaque numéro ouvert ou fermé qui mentionne la vitesse de verrouillage. Nous verrons votre commentaire peu importe combien de fois vous dites la même chose. Si vous voulez être utile, vous devrez fournir un exemple de cas reproductible. Sonner pour dire "moi aussi" n'ajoute tout simplement rien d'autre que du trafic supplémentaire sur le traqueur de problèmes. Veuillez en tenir compte.

Pareil ici. Pipenv très lent.
Prend une heure pour verrouiller et installer.

Je pense que ce problème a été bien répondu ici : https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

Les dépendances Python nous obligent à télécharger et à exécuter entièrement les fichiers d'installation de chaque package à résoudre et à calculer. C'est juste la réalité, c'est un peu lent. Si vous ne pouvez pas attendre 2 minutes ou si vous pensez que cela ne vaut pas le compromis, vous pouvez toujours passer --skip-lock .

• par @techalchemy

Serait-il possible d'obtenir la liste des hachages à partir de l'API PyPI, plutôt que de les calculer nous-mêmes ?

pipenv est génial, mais ce problème semble toujours exister. sera heureux de voir tout progrès. --skip-lock n'a pas fonctionné.

pipenv est génial, mais ce problème semble toujours exister. sera heureux de voir tout progrès. --skip-lock n'a pas fonctionné.

A travaillé pour moi

J'ai trouvé que l'utilisation de Git Bash sous Windows était très lente par rapport à Powershell. Je n'ai pas de statistiques ou de données à ce sujet, mais PS semblait plus rapide. Donc, si vous utilisez Git Bash, vous voudrez peut-être essayer le PS natif pour pipenv 'ing.

Je sais que ce problème est clos, mais pour moi, l'installation de pandas prend beaucoup de temps. La sortie verbeuse est la suivante

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...

Il est bloqué au verrouillage pendant plus de 30 minutes. J'utilise python 3.7.0, macos mojave. Toute aide avec ça.

Pourquoi tous les problèmes liés à ce sujet sont-ils fermés ? Je ne peux pas installer une seule chose en raison du blocage de l'étape de verrouillage.

L'image docker suivante prend plus de 30 minutes à construire sur mon ordinateur portable (i7/16Gb), la commande pipenv install ... s'exécute depuis des lustres...

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

Est-ce normal? Quelqu'un peut-il se reproduire ?

Mise à jour : soyez prudent avec Alpine Linux

J'ai réalisé que le problème n'était pas du côté de pipenv ...

J'ai remplacé l'image docker de base d' Alpine par une image basée sur pipenv install termine en quelques secondes.

Le problème dans mon exemple est qu'Alpine Linux essaiera toujours de créer des packages contenant cython-extension ou c-extensions partir de la source, ce qui peut prendre une éternité dans un conteneur Docker, alors que Debian Linux les installe en utilisant le wheel format, qui se produit BEAUCOUP plus rapidement (en quelques secondes).

Plus d'informations à ce sujet : https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

J'ai longtemps laissé pipenv et chaque fois que j'ai besoin de créer un environnement virtuel, utilisez "venv" ou d'autres options.

Ayant également un problème de lenteur étrange, seulement 2 modules pour certains scripts que je fais.

click

L'installation a pris 15/20 minutes, les tests Internet à plus de 60 Mbps fonctionnent sur un MacBook Pro 2019 à jour (pas mon choix de matériel).

Veuillez utiliser virtualenv pour le moment. jusqu'à ce qu'une meilleure solution soit disponible

99% du temps que je fais cela, les dépendances se résoudront au même dans mon fichier de verrouillage, c'est parce que cela fait partie de mon pipeline de développement.

Dans le cas où il n'y a pas de nouveaux packages en amont depuis la dernière exécution, le processus pourrait-il sûrement être ignoré ?