<p>La instalación de pipenv es muy lenta.</p>

Hola de nuevo @Diggsey , esto se debe a la forma en que estamos escribiendo los cambios en este momento. Tengo estos cambios listos para combinar, pero se están interrumpiendo para la API de projects.py por lo que vamos a esperar hasta el próximo lanzamiento principal. Con suerte, tendremos esto listo y listo en las próximas semanas. Dejaré esto abierto para rastrear el problema por ahora.

Corrimos juntos en esto en PyCon. Pronto será más rápido.

Ahora mismo para mí no es lento, es helador...

Un pipenv install my_package o un simple pipenv install no me da ninguna salida, después de 20 minutos.

EDITAR: Confirmación, todavía nada después de unas horas. ¿Es el mismo problema? Por lo general, era lento, pero terminaba después de 5 a 10 minutos.

Hola @NicolasWebDev , ¿qué versión de pipenv estás usando? ¿También tiene delegator.py instalado en su sistema por separado? Si es así, ¿en qué versión es eso? Este fue un problema que debería haberse resuelto en v3.6.0.

Si todo lo anterior está actualizado, ¿podría proporcionar el contenido de su Pipfile? ¡Gracias!

Hola @nateprewitt , tenías razón, estaba en v3.5.x. Actualizar a 4.1.1 resolvió el problema de congelación. Ahora todavía tarda 5 minutos, ¡pero al menos es utilizable!

Perdón por el ruido, siempre olvido que los paquetes instalados a través de pip no se actualizan automáticamente.
¡Gracias!

¡Me alegro de que hayas resuelto las cosas @NicolasWebDev! Estamos trabajando para que esto se acelere más, con suerte el #373 estará un paso más cerca en la próxima versión.

@Diggsey @NicolasWebDev , acabo de publicar 4.1.2 que debería tener estas mejoras de velocidad agregadas. Todavía hay trabajo por hacer aquí, pero esto al menos acelerará el tiempo de arranque inicial para pipenv.

@nateprewitt Gracias por la actualización, pipenv parece más rápido para mí ahora, pero aún toma varios minutos ejecutar pipenv lock , incluso cuando nada ha cambiado, todavía espera en Locking [packages] dependencies... por la gran mayor parte de ese tiempo.

@Diggsey , gran parte de ese tiempo se debe a que está descargando una gran cantidad de archivos en ese Pipfile. Parece que también estás fijando todas tus dependencias. ¿Está importando directamente todo esto en su proyecto o son algunos requisitos de dependencia de los demás?

@nateprewitt Podríamos eliminar algunos de ellos, pero la mayoría son dependencias directas. ¿Por qué necesita descargar todas las dependencias cada vez que genera el archivo de bloqueo?

Necesitamos determinar todo lo que instala como dependencias. Para obtener eso, descargamos cada paquete y determinamos cómo se ve una instalación en el momento del bloqueo. Esto nos permite anclar apropiadamente todo en el Pipfile.lock. Sin descargar, no hay una forma confiable de verificar las subdependencias y resolver las declaraciones de dependencia de rango.

Dado que la mayoría de los paquetes permanecerán igual con el tiempo, ¿sería posible almacenar en caché los paquetes descargados?

@Diggsey quiere investigar eso por nosotros?

Esta puede ser una pregunta tonta, pero ¿Pip no realiza ya el almacenamiento en caché de paquetes ?

Tengo la impresión de que sí.

¿Puede pipenv usar el sistema de caché pip o tiene que implementarse desde cero?

Pipenv solo ejecuta pip, por lo que el caché debe usarse automáticamente.

¡reparado! bloqueo es muy rápido ahora.

Oh gracias. Creo que eso fue lo único que me impidió empujar a todos a pipenv en el trabajo.

Wow, genial, eso fue literalmente más que una aceleración de 100x para mí, ¡y también detectó un conflicto de dependencia que la versión anterior no detectó!

Lo que sería útil es un indicador verbose para pipenv lock . Solo pude diagnosticar el conflicto de dependencia editando piptools/logging.py para habilitar el registro detallado, pero una vez que lo hice, me dio una indicación muy clara de lo que estaba pasando.

Probablemente me estoy perdiendo algo :) ¿Dónde se soluciona? La última versión es hace 4 días, así que instalé la última versión de master . Sin embargo, pipenv install todavía es lento.

Lo intenté:

• instale pipenv la manera elegante ⚡️ 🍰 ⚡️
• use la última versión publicada de pipenv y la última versión de master
• instalar un solo paquete

Usando la última versión estable (5.3.5.), se tarda 3:40 en instalar un paquete:

∙ 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

Usando la versión de master , todavía se cuelga (un paquete, +10 minutos)

EDITAR: Acaba de terminar:

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

¿Algunas ideas? ¡Muchas gracias!

A veces, las dependencias tardan un poco en instalarse, especialmente si tienen compilaciones c. ¿Quieres compartir tu Pipfile ?

Entiendo que a veces lleva un tiempo, pero fue lento desde el principio. Sólo curiosidad si es un problema a mi lado.

Aquí está mi 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 puede estar tardando un poco, ya que puede estar compilando desde la fuente. Todo lo demás debe ser agradable y rápido. Intente eliminarlo y vea cuánto aumenta su velocidad.

$ pipenv install raven solo tomó como 1s para mí.

$ pipenv install raven solo tomó como 1s para mí.

¡Eso es lo que esperaría! ¿Puedo activar la salida detallada de alguna manera?

Intenté eliminar psycopg2 , pero no afecta mucho. Ejecutar pipenv install raven cuelga por un tiempo.

Yo tengo:

• Pitón 3.6.2
• mac OS 10.12.6

No veo ninguna razón por la que Raven no deba ser instantáneo.

haz $ pip install raven dentro de $ pipenv shell y dime si también es lento allí.

Todo lo que hace pipenv es ejecutar pip, por lo que efectivamente es el "modo detallado"

Eso es instantáneo:

∙ 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

Ejecutar pipenv cuelga alrededor de 2-3 minutos (dentro/fuera 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, ¿ puede abrir una nueva edición sobre --verbose y proporcionar un ejemplo de cómo le gustaría que se viera?

@ tricoder42 ¿la parte lenta es el paso de bloqueo o el paso de instalación? El bloqueo se mejoró enormemente en las últimas versiones.

```concha
$ tiempo pipenv instalar cuervo
Instalando cuervo...
recogiendo cuervo
Uso de raven-6.1.0-py2.py3-none-any.whl en caché
Requisito ya satisfecho: contextlib2 en /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (de raven)
Instalación de paquetes recopilados: raven
Cuervo instalado con éxito-6.1.0

Agregando raven a los [paquetes] de Pipfile...
Bloqueando dependencias [paquetes de desarrollo]...
Bloqueando [paquetes] dependencias...
¡Pipfile.lock actualizado!
9.30 real 5.49 usuario 0.42 sys

Es como 50:50 i nstalling:locking

@tricoder42 y estás usando lo último?

Déjame replicar con tu pipfile exacto.

Supongo que sí:

∙ 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

```concha
$ tiempo de instalación de pipenv
No se proporciona ningún paquete, se instalan todas las dependencias.
Pipfile encontrado en /Users/kennethreitz/pipenv/testapp/Pipfile. Teniendo en cuenta que este es el hogar del proyecto.
Pipfile.lock no encontrado, creando...
Bloqueando dependencias [paquetes de desarrollo]...
Bloqueando [paquetes] dependencias...
¡Pipfile.lock actualizado!
Instalando dependencias desde Pipfile.lock...
[===============================] 22/22 - 00:00:37
58.94 real 40.51 usuario 8.62 sys

Lo hace incluso cuando estoy instalando el primer paquete en un nuevo pipenv nuevo. Intentaré crear pipenv --three lugar de pipenv --python python3.6

@tricoder42 ¿ quieres

O podemos usar el uso compartido de pantalla de Apple si usa Messages.app.

¡Agrégame! Soy [email protected].

Estoy a punto de unirme a una reunión, pero estaré disponible después de eso.

¡Frio! Intentaré limpiar y reinstalar todo desde cero y ya veremos. estoy disponible en una hora

Impresionante, lo resolveremos entonces. Agrégame en mensajes.aplicación :)

Si alguien está experimentando un comportamiento extremadamente lento de Locking con v11.9.0 , descubrí que cambiar a v9.0.0 lleva una instalación de 5 minutos y 30 segundos a 1 minuto y 36 segundos.

@ryantuck Te recomiendo que si vas a anclar una versión anterior para anclar 9.0.3 pero pierdes una cantidad significativa de seguridad adicional por la velocidad, también podrías usar --skip-lock en ese punto

--skip-lock definitivamente aceleró las cosas. Seguí este camino porque pipenv install --system --python=3.6 realidad no se estaba instalando en el sistema Python correcto, y supuse que necesitaba generar Pipfile.lock antes de intentar la instalación del sistema. Todavía no funcionó, así que volví a usar el antiguo pip normal, pero volveré a comentar en este hilo si alguna vez hago algún progreso en este sentido.

—system y —python son mutuamente excluyentes; la última opción siempre necesita un entorno virtual

sí, el bloqueo también me lleva un tiempo. v11.10.0. Ubuntu en 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

Debería ser un poco más rápido la segunda o tercera vez debido a
almacenamiento en caché aunque. ¿Ves una mejora?
El jueves 12 de abril de 2018 a las 10:23 Alexander Kavanaugh <
[email protected]> escribió:

sí, el bloqueo también me lleva un tiempo. v11.10.0. Ubuntu en WSL.

[[fuente]]url = " https://pypi.python.org/simple "verify_ssl = truename = "pypi"
[paquetes]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-secuestro = "==2.1.7"django-secuestro- 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- precompilador estático = {extras = ["libsass"], versión = "==1.8.2"}almacenamiento de django = "==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" números de teléfono = "==8.9.3"pillow = "==5.1.0""psycopg2-binary" = "==2.7.4"pigmentos = "==2.2.0"pyssim = "==0.4"python-dotenv = "==0.8.2"pytz = "==2018.4"cuervo = "==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"camarera = "==1.1.0"ruido blanco = "==3.3.1"Django = "==2.0.4"
[paquetes de desarrollo]cobertura = "==4.5.1"selenium = "==3.11.0"tblib = "==1.3.2""flake8" = "==3.5.0"django-debug-toolbar = " ==1.9.1"extensiones de Django = "==2.0.6"
[requiere] python_version = "3.6"

Pipfile.lock no encontrado, creando...
Bloqueando dependencias [paquetes de desarrollo]...
Bloqueando [paquetes] dependencias...
¡Pipfile.lock actualizado (7a535c)!
Instalando dependencias desde Pipfile.lock (7a535c)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

8m1.993s reales
usuario 5m32.406s
sistema 7m15.203s

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pipenv/issues/356#issuecomment-380882203 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

Ya había instalado los paquetes antes de eso; Acabo de eliminar el archivo de bloqueo y ejecuté la instalación nuevamente. Lo haré de nuevo para obtener otro punto de datos.

@jtratner Guau . Súper interesante... ¿Qué hace que el almacenamiento en caché se active solo después de la tercera vez o más?

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 introdujo una función para almacenar en caché los hashes también, por lo que debería suponer una mejora considerable

Aquí estoy... 15 minutos después

@giantas no es útil. Proporcione pipfile, salida y duración con pip install. También si puedes hacer paquetes individuales.

Se necesita bastante para ejecutarse en mi máquina. macOS 10.13.4, pipenv, versión 11.10.0

La descarga se ejecuta casi de inmediato, pero luego se bloquea en Locking [packages] dependencies… . Aquí está tomando medio minuto para dos dependencias, y luego 6 minutos para otras 3 dependencias, si le tiro todas las dependencias de mi proyecto, simplemente se cuelga indefinidamente en el paso de bloqueo

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 santa mierda que lento! Tenga en cuenta que esto se debe en parte a la instalación de numpy, que estoy seguro de que probablemente estamos compilando desde la fuente para bloquear o algo estúpido. ayudaría si proporcionamos resultados útiles aquí

¿Hay algo que pueda hacer al respecto? ¿O simplemente no tengo suerte al usar pipenv y tener estos tiempos de archivo de bloqueo lento? Supongo que podría --skip-lock pero quería esa característica

@pablote, ¿ puede verificar si vuelve a ejecutar la misma operación de bloqueo, sigue siendo lento?

Si vuelvo a ejecutar, finaliza casi de inmediato, así que supongo que es solo la primera vez que se agrega una nueva dependencia.

así que en realidad está almacenando en caché los hashes localmente, por lo que, por alguna razón, es el proceso de generación de hash el que es increíblemente lento aquí...

Avíseme si hay alguna información que pueda proporcionar para ayudar a diagnosticar. Por el momento volveré a pip + virtualenv + pip-tools :/

@pablote una vez que tenga los hashes una vez, bloquear de nuevo no será tan lento

Por favor, proporcione resultados útiles. Acabo de actualizar mi pipenv de 9.1.0 a 11.10.0 para resolver la falla del marcador no válido en el paso de bloqueo del paquete según, por ejemplo, # 1622 --- ahora, tengo un archivo pip con ipykernel, pandas, jupyter, numpy, y matplotlib allí y con mi último intento de usar pipenv install para poner en marcha el archivo de bloqueo, he estado sentado en locking [packages] dependencies… durante más de 10 minutos.

Debido a que no hay salida, no puedo decir si algo realmente está funcionando (como construir numpy desde la fuente) o si solo está colgando. Lo mejor que puedo hacer es entrecerrar los ojos en top y concluir que tal vez esté haciendo algo porque un proceso de Python parece estar dando vueltas... pero tendré que desechar este virtualenv y comenzar de nuevo si algo no se mueve pronto.

Estoy feliz de contribuir a algún trabajo en esto si es necesario.

Por favor, proporcione resultados útiles. Acabo de actualizar mi pipenv de 9.1.0 a 11.10.0 para resolver la falla del marcador no válido en el paso de bloqueo del paquete según, por ejemplo, # 1622 --- ahora tengo un archivo pip con ipykernel, pandas, jupyter, numpy, y matplotlib allí y con mi último intento de usar pipenv install para poner en marcha el archivo de bloqueo, he estado sentado bloqueando dependencias de [paquetes]... durante más de 10 minutos.

Queja totalmente comprensible y he estado pensando en cómo podemos proporcionar comentarios más útiles al usuario (porque estoy de acuerdo en que es un poco confuso que no tenga ningún resultado). Me rendiría después de 15 minutos. Como señaló @techalchemy , cada vez que su caché debe

Una pregunta: ¿estás usando PyPI público?

@jtratner sí, usando PyPi público --- y finalmente terminé rindiéndome, destrozando el virtualenv y construyendo uno nuevo; Logré crear un archivo de bloqueo instalando mis dependencias una a la vez. (Curiosamente, matplotlib fue el más lento, ¡incluso peor que numpy!)

Quizás un mensaje como This may take a long time ayudaría a tranquilizar a las personas hasta que se decida una solución más clara.

15 minutos sigue siendo increíblemente largo. Dudo que me siente a esperar. @paultopia puede ejecutar pipenv lock —verbose para obtener más resultados

Tiene la sensación general de ser más lento de lo que debería ser, pero tal vez estoy subestimando el problema. Si observo los procesos en ejecución en mi computadora, puedo ver el de python ejecutándose todo el tiempo que se está ejecutando pipenv, y nunca supera el ~ 15%, probablemente debería usar más si está haciendo un trabajo intensivo de CPU como hash de archivos . Además, he usado otros administradores de paquetes que modifican las dependencias, como yarn, y son bastante rápidos.

Tenemos que averiguar qué está haciendo...

Creé un proyecto de github que muestra lentitud al usar el bloqueo. Eche un vistazo a https://github.com/AndreasPresthammer/slow-pipenv . Sin embargo, no estoy 100% seguro de que este sea el mismo problema. Tire del repositorio hacia abajo y ejecute el script slow.sh y observe la diferencia en el tiempo de ejecución.

@AndreasPresthammer, por lo que su secuencia de comandos solo está cronometrando un bloqueo no almacenado en caché frente a la instalación con bloqueo. Sabemos que es el bloqueo, pero eso es lento. En el caso de numpy, probablemente se deba a que en el pasado tuvo que usar sdists para la resolución, lo que significaba compilación. Podemos usar ruedas ahora. Eso puede acelerar las cosas.

Esto definitivamente sigue siendo un problema (más de 5 minutos), con las últimas versiones de python3.6, pip y pipenv, e instalando un paquete simple como torch . No creo que este problema deba marcarse como cerrado.

Para cualquiera que quiera comentar sobre el cierre de este problema: proporcione el resultado de pipenv lock --verbose . Sabemos que la resolución es lenta para los paquetes que se compilan desde el código fuente y que tardan mucho tiempo en compilarse en condiciones normales. Necesitamos registros para obtener información sobre la causa si esto es más lento de lo normal.

También estoy usando Docker para mi entorno de desarrollo y producción y creo que la instalación dentro de Docker se siente lenta, en comparación con la instalación en el host. Tal vez sea solo la combinación de todos los paquetes, pero me gustaría escuchar algunos comentarios de personas con más experiencia que yo.

Aquí está el registro de pipenv lock --verbose , incluidos Pipfile y Pipfile.lock :

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

@mimischi Los resultados de la resolución se almacenan en caché en el host, pero Docker no puede acceder a ellos. Es lento porque necesita rehacer toda la resolución desde cero. Sería útil si monta el directorio de caché del host en Docker. Hay un comentario en un problema que menciona la ruta que debe montar. No tengo tiempo para buscarlo ahora, pero puedes intentar encontrarlo. (¡Y contribuya a la página de preguntas frecuentes del documento cuando lo haga!)

FWIW, bloquear mi caja de desarrollo ahora toma menos de 30 segundos. Mucho mejor que antes, se lo agradezco.

Hola, tengo el mismo problema.
aquí está el detallado

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…

Aquí está el pipenv --version : pipenv, versión 2018.05.18

Además, no sé por qué sucede esto, no se produce un motivo/error específico.
En mi caso, cuando hago pipenv lock , comienza pero nunca termina, que yo sepa. He estado esperando durante 2 horas y todavía no hay señales de finalización. Y me ha dado ReadTimeoutError dos veces, esta es la tercera vez que hago esto.
Usando Python 3.6.4

Cualquier ayuda sería de gran ayuda ya que la fecha de vencimiento de mis proyectos está más cerca.

Vota también para que se reabra este tema. Está lejos de resolverse... tomar entre 10 y 20 minutos para bloquear mi proyecto dentro de un contenedor Docker. También usa una cantidad increíble de memoria, de modo que tuve que aumentar la asignación a Docker para evitar que terminara con el proceso.

Proporcione detalles de ejemplo de Pipfilesmand sobre sus entornos si desea ayuda con problemas con la velocidad de resolución. Estamos editando un lanzamiento esta semana y no tenemos tiempo para rastrear comentarios únicos individuales en hilos cerrados, pero podemos probar con Pipfiles si proporciona uno

@jkp Permítame asegurarle que todos y cada uno de los desarrolladores principales de este proyecto (no es que seamos muchos para empezar) conocen muy bien este problema y están tan preocupados por él como usted, si no más. Sin embargo, este no es un problema fácil, y ya hemos hecho todo lo posible para que sea lo más utilizable posible, sin tener que desmontar todo en el paquete de Python. También tenemos mucho en nuestro plato en este momento, y también debemos centrarnos en esos otros problemas. La decisión inevitable que debo tomar, entonces, es priorizar los problemas que realmente sabemos cómo resolver, y solo comenzar a pensar en nuestros próximos pasos después de que se hayan realizado, para maximizar el efecto de nuestro esfuerzo.

Ahora, reconozco plenamente que su prioridad puede ser diferente a la nuestra. Este problema de rendimiento puede ser el problema más grande en su flujo de trabajo y desea presentarlo como lo más importante en este proyecto. Sin embargo, tenga en cuenta que no es el único usuario de esta herramienta y que debemos priorizar la necesidad de todos, incluso la nuestra , frente a la suya. Yo reconozco que. Por lo tanto, insto a cualquiera que comparta la situación a que se una a este problema y trate de pensar en una forma de resolverlo. Una vez que sabemos qué hacer realmente, podemos hacerlo.

El problema se mantiene cerrado porque no sabemos qué podemos hacer y solo serviría como ruido en el rastreador de problemas cuando intentáramos manejarlo. No tiene sentido, al menos en nuestro flujo de trabajo, tener un problema en el que nadie puede trabajar.

Aprecie su flujo de trabajo, así que si así es como maneja los problemas, está bien. Intentaré agregar cualquier información que pueda para ayudar a localizar el problema.

Hice algo de depuración instalando mitmproxy entre pipenv y la red para rastrear las solicitudes que se realizan. Encontré un par de cosas interesantes.

1. Estamos usando un índice privado de pypi que aún no es compatible con json-api . Esto ralentiza significativamente las cosas, ya que parece que el recurso alternativo es usar la fuerza bruta y descargar todo lo que figura en el índice http para extraer metadatos, etc. Una sugerencia aquí sería simplemente agregar un registro simple para advertir que se está utilizando este método alternativo. podría evitar que alguien más tenga que profundizar más para resolver esto.

2. Usando el método de fuerza bruta, parece que el código descarga paquetes que no son relevantes para la arquitectura en uso. Por ejemplo, en una máquina Linux, estaba descargando win32 o osx paquetes de rueda específicos. Esto se siente como algo que podría detectarse y evitarse, ya que está claro que los paquetes binarios creados para otras arquitecturas no serán de ninguna utilidad.

Continuaré depurando e informando cualquier información útil a medida que la encuentre.

Parece que incluso con la interfaz json en uso, pipenv está realizando solicitudes innecesarias de archivos de ruedas que se relacionan con diferentes arquitecturas. Actualmente, la implementación es bastante ingenua, ya que verifica todos los archivos enumerados en una versión determinada, independientemente de la plataforma/arquitectura de destino.

Caso de prueba mínimo:

En un servidor Linux: pipenv install grpcio

Produjo las siguientes solicitudes (capturadas usando 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

Contando algunas de las solicitudes innecesarias:

• 4 x win32
• 4 brazos
• 4 x mac

Etc. ¿Parece una ganancia rápida hacer un filtrado simple basado en el sistema operativo host y el arco?

Quiere que las cosas se filtren por host y arquitectura, la mayoría quiere un archivo de bloqueo que incluya hash que les permita instalar en esos hosts y arquitecturas (tenemos una cantidad significativa de hacks en la base de código de resolución de pip que permiten específicamente esto, por lo que no es noticias para nosotros)

Con respecto a la API JSON, en realidad no está habilitada para acceder directamente en la versión actual, y planeo deshabilitarla en el código base nuevamente antes de que lancemos. He realizado un perfilado extenso y sé que las llamadas fallidas a packaging.version.parse() representan alrededor del 20-50% del tiempo de ejecución de pipenv.

Sin embargo, Pip 10 usa la API JSON de forma predeterminada como su resolución principal, por lo que, a menos que desee dejar de usar pip, no hay mucho que hacer en ese frente.

Siento que debemos estar descargando las mismas cosas varias veces, ¿verdad?

Probablemente deberíamos mover la discusión al #2284. En realidad, es la parte de bloqueo la que es lenta ( install es esencialmente manipulación TOML + lock + sync ), no la instalación.

Con respecto al bloqueo de un solo arco. Entiendo la elección del diseño; ¿Tal vez podría haber una opción para pasar una bandera para permitir que un usuario bloquee solo para la arquitectura del host? Esta sería una optimización bastante significativa tanto en términos de tiempo como de ancho de banda para algunos casos de uso.

@techalchemy gracias por tu respuesta. El hallazgo de packaging.version.parse() parece una buena pista. ¿Podría poner un poco más de color en esta declaración:

Con respecto a la API JSON, en realidad no está habilitada para acceder directamente en la versión actual, y planeo deshabilitarla en el código base nuevamente antes de que lancemos.

No entendí por qué planeas desactivarlo.

@jkp Con respecto a la API JSON, digamos que no es lo mejor diseñado que existe. La API simple es mucho más adecuada para nosotros. Al deshabilitarlo, estamos usando la API simple, no usando ninguna API por completo.

Me está tomando demasiado tiempo instalar Pyspark.
Mi Pipfile -

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

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

[requires]
python_version = "3.5"

salida de shell -

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

El proceso está atascado en la última línea de arriba.
Termina después de 15-20 minutos

pipenv, versión 2018.7.1

@keshavkaul PySpark es muy grande y puede tardar bastante en descargarse. Dale algo de tiempo, será mucho mejor después (porque Pipenv almacena en caché el resultado).

(O puede instar a los desarrolladores a lanzar una distribución de rueda. Eso ayudaría un poco).

Nota para futuros visitantes: Absténgase de publicar el resultado de su instalación lenta. Sabemos que puede ser lento. Sabemos por qué es lento. Su resultado no agrega nada a este tema.

¿Sería posible tener alguna información o barra de progreso como apt-get o wget (velocidad de descarga, tamaño descargado, tamaño total) durante las descargas de las bibliotecas?
Supongo que este es el problema aquí, pipenv me pareció lento, pero solo era la descarga de la biblioteca, tuve que abrir un monitor del sistema para entender que pipenv estaba descargando los archivos y cuánto ya se había descargado, a qué velocidad, etc.

tiene el mismo problema: Locking [packages] dependencies... colgar para siempre
mi entorno:

• macOS High Sierra 10.13.6
• Pitón: Pitón 3.6.4
• pipenv: versión 2018.7.1

@crifan no es necesario publicar el mismo mensaje en cada problema abierto o cerrado que mencione la velocidad de bloqueo. Veremos tu comentario sin importar cuantas veces digas lo mismo. Si desea ser útil, deberá proporcionar un caso de ejemplo reproducible. Intervenir para decir "yo también" simplemente no agrega nada más que tráfico adicional en el rastreador de problemas. Por favor, tenga en cuenta eso.

Aquí igual. Pipenv muy lento.
Tarda una hora en bloquearse e instalarse.

Creo que este problema se ha respondido bien aquí: https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

Las dependencias de Python requieren que descarguemos y ejecutemos completamente los archivos de instalación de cada paquete para resolver y calcular. Esa es la realidad, es un poco lento. Si no puede esperar 2 minutos o cree que no vale la pena el intercambio, siempre puede pasar --skip-lock .

• por @techalchemy

¿Sería posible obtener la lista de hashes de la API de PyPI, en lugar de calcularlos nosotros mismos?

pipenv es increíble, pero este problema parece seguir existiendo. estará encantado de ver cualquier progreso. --skip-lock no funcionó.

pipenv es increíble, pero este problema parece seguir existiendo. estará encantado de ver cualquier progreso. --skip-lock no funcionó.

Trabajó para mi

Descubrí que usar Git Bash en Windows era muy lento en comparación con Powershell. No tengo estadísticas ni datos sobre esto, pero PS parecía más rápido. Entonces, si está utilizando Git Bash, es posible que desee probar el PS nativo por pipenv 'ing.

Sé que este problema está cerrado, pero para mí, la instalación de pandas toma mucho tiempo. La salida detallada es esta

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

Está atascado en Locking durante más de 30 minutos. Estoy usando python 3.7.0, macos mojave. Cualquier ayuda con eso.

¿Por qué están cerrados todos los problemas de este tema? No puedo instalar pipenv ni una sola cosa debido al bloqueo del paso de bloqueo.

La siguiente imagen de la ventana acoplable tarda más de 30 minutos en compilarse en mi computadora portátil (i7/16 Gb), el comando pipenv install ... ejecuta durante mucho tiempo...

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

¿Esto es normal? ¿Alguien puede reproducirse?

Actualización: Tenga cuidado con Alpine Linux

Me di cuenta de que el problema no está del lado de pipenv ...

Reemplacé la imagen acoplable base de Alpine con una que se basa en Debian-Slim y ahora pipenv install finaliza en segundos.

El problema en mi ejemplo es que Alpine Linux siempre intentará crear paquetes que contengan cython-extension o c-extensions desde el origen, lo que puede demorar una eternidad en un contenedor Docker, mientras que Debian Linux los instala usando el wheel formato, que ocurre MUCHO más rápido (en cuestión de segundos).

Más sobre esto: https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

Hace mucho que dejé pipenv y cada vez que necesito crear un entorno virtual en uso "venv" u otras opciones.

También tengo un problema de lentitud extraño, solo 2 módulos para algunas secuencias de comandos que estoy haciendo.

click

La instalación tardó entre 15 y 20 minutos, las pruebas de Internet a más de 60 Mbps y se ejecutaron en una MacBook Pro 2019 actualizada (no es mi elección de hardware).

Utilice virtualenv por el momento. hasta que haya una mejor solución disponible

El 99 % de las veces que hago esto, las dependencias se resolverán en la misma en mi archivo de bloqueo, esto se debe a que es parte de mi tubería de desarrollo.

En el caso de que no haya nuevos paquetes ascendentes desde la última ejecución, seguramente se podría omitir el proceso.