Pipenv: El bloqueo es lento (y realiza descargas redundantes)

@colllin ¿Ha verificado si los comandos pip que se comunican con el servidor, como pip search (creo), también son lentos?

Veo un comportamiento similar, pero es un problema conocido y depende de la red. Por alguna razón, el acceso a pypi.org desde mi red de trabajo es increíblemente lento, pero normalmente es rápido desde mi red doméstica. Creo que el bloqueo hace muchas transacciones de pip bajo el capó, por lo que el acceso lento al servidor ralentiza mucho la operación.

EDITAR: También puede ser que solo tenga muchas subdependencias para resolver: qué tan grande es el entorno una vez creado (por ejemplo, cuántos paquetes de nivel superior en su pipfile y cuántos paquetes devueltos por pip list una vez que se inicia el entorno)?

Gracias por la atenta respuesta.

pip search no es especialmente rápido o lento para mí ... ~ 1 segundo?

Perdóname por mi falta de conocimiento del dominio: ¿Realmente es necesario realizar una búsqueda con pip? ¿No acaba de instalar todo? ¿No solo necesita anotar lo que ya está instalado? O ... dado que garantiza la existencia del archivo de bloqueo de todos modos, ¿podría hacer esto mientras instala los paquetes o antes?

Supongo que ... ¿pipenv usa pip debajo del capó? entonces el proceso de instalación es una caja negra, y no puede conocer el gráfico de dependencia de lo que fue / será instalado sin hacer ~ una búsqueda de pip ~ sus propias consultas de pip?

EDITAR: Hay 1 paquete de nivel superior y ~ 65 paquetes devueltos por pip list en este repositorio en particular.

No soy un colaborador del proyecto y por el momento no conozco todos los detalles, pero tengo entendido que la fase de bloqueo es donde todas las dependencias se resuelven y anclan. Entonces, si tiene un paquete de nivel superior con ~ 65 dependencias, es durante la fase de bloqueo que se descubren (recursivamente) todas las dependencias de ese primer paquete, y luego el árbol de dependencias se usa para resolver qué paquetes deben instalarse y (probablemente) en el orden aproximado en el que deberían instalarse. No estoy tan seguro de la última parte.

Si pip instala desde un Pipfile sin un archivo de bloqueo presente, notará que realiza la fase de bloqueo antes de instalar los paquetes en venv. Del mismo modo, si tiene un archivo de bloqueo pero no está actualizado. Sospecho que tener un archivo de bloqueo e instalar usando la opción --deploy sería más rápido, al igual que la opción --no-lock ; en el primer caso, obtiene un error si el archivo de bloqueo está desactualizado; en el segundo, pierde la división lógica de los paquetes de nivel superior (entorno declarado) y el entorno real instalado (bloqueado) de todos los paquetes. Al menos así es como lo entiendo.

Ya sea que pipenv use o no pip bajo el capó, creo que lo hace, todavía necesita obtener la información del servidor pypi sobre las dependencias de paquetes y similares, por lo que mi pregunta sobre la búsqueda de pip fue más un proxy de qué tan rápido o ralentizar su camino al servidor pypi es una implicación directa sobre el mecanismo por el cual pipenv hace lo suyo.

Un experimento interesante podría ser comparar el tiempo requerido para bloquear el árbol de dependencias en pipenv e instalar los requisitos en un nuevo venv usando pip install -r requirements.txt . Creo que deberían hacer cosas bastante similares durante la fase de resolución de dependencias.

¿Hemos establecido en algún lugar que se están produciendo descargas redundantes por cierto? Sospecho que ese es el caso, pero demostrarlo sería realmente útil.

Para su información, comparar pip install -r requirements.txt con el tiempo que lleva bloquear un gráfico de dependencia no será informativo como punto de comparación. En realidad, Pip no _ tiene_ un resolutor, no en ningún sentido real. Creo que puedo describir la diferencia. Cuando pip instala su requirements.txt , sigue este proceso básico:

• Encuentre el primer requisito en la lista
  
  
  
  • Encuentra todas sus dependencias
  
  
  • Instalarlos todos
  
  
• Encuentre el segundo requisito en la lista
  
  
  
  • Encuentra todas sus dependencias
  
  
  • Instalarlos todos
  
  
• Encuentre el tercer requisito enumerado
  
  
  
  • Encuentra todas sus dependencias
  
  
  • Instalarlos todos
  
  

Esto resulta ser bastante rápido porque a pip realmente no le importa si las dependencias de _package 1_ entran en conflicto con las dependencias de _package 3_, simplemente instaló las de _package 3_ por último, así que eso es lo que obtienes.

Pipenv sigue un proceso diferente: calculamos un gráfico de resolución que intenta satisfacer _todas_ las dependencias que especifique, antes de construir su entorno. Eso significa que tenemos que comenzar a descargar, comparar y, a menudo, incluso _construir_ paquetes para determinar cómo debería verse su entorno en última instancia, todo antes incluso de haber comenzado el proceso real de instalación (hay muchas publicaciones en el blog sobre por qué esto es el caso de Python, por lo que no entraré más aquí).

Cada paso de ese proceso de resolución se hace más costoso computacionalmente al requerir hash, que es una mejor práctica. Hacemos hash de los paquetes entrantes después de recibirlos, luego los comparamos con los hash que PyPI nos dijo que deberíamos esperar, y almacenamos esos hash en el archivo de bloqueo para que, en el futuro, las personas que quieran construir un entorno idéntico puedan hacerlo con la garantía contractual de que los paquetes a partir de los cuales se construyen son los mismos que usó originalmente.

La búsqueda de pip es un punto de referencia deficiente para todo esto, de hecho, cualquiera de las herramientas de pip es un punto de referencia deficiente para hacer este trabajo: usamos pip para cada pieza, pero poniéndolo en conjunto y en muchas dependencias para formar y administrar entornos y gráficos es donde se agrega el valor de pipenv.

Un punto de aclaración: una vez que resuelva el gráfico de dependencia completo, el orden de instalación ya no debería importar. Debajo del capó, en realidad pasamos --no-deps a cada instalación de todos modos.

Como pequeña nota al margen, la búsqueda de pip es actualmente la única pieza de las herramientas de pip que se basa en la interfaz XMLRPC ahora obsoleta, que no se puede almacenar en caché y es muy lenta. Siempre será más lento que cualquier otra operación.

Bloquear numpy (y nada más) toma 220 s en mi máquina (ver más abajo). La mayor parte del tiempo parece dedicarse a descargar más de 200 MB de datos, lo cual es bastante desconcertante dado que toda la fuente tiene 4 MB. Aunque claramente, incluso si fue instantáneo, todavía hay 25 s de procesamiento real, e incluso eso parece excesivo para calcular algunos hash. El bloqueo posterior, incluso después de eliminar Pipenv.lock, tarda 5 s.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-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
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

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

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpy debería ser sustancialmente más rápido ahora (¡de hecho, he estado usando tu ejemplo como caso de prueba!). En mi prueba más reciente, lo tenía a ~ 30 s en un caché frío en una máquina virtual.

¿Puede confirmar alguna mejora con la última versión?

También ha mejorado sustancialmente para mí. Ahora estoy sentado en una conexión muy rápida, y bajé a 14 s, pero fue entonces cuando la descarga fue a 30 MB / s. ¿Qué se está descargando además de una única copia del código fuente de numpy?

Creo que estamos descargando ruedas redundantes (no estoy seguro). Ya estamos evaluando la situación.

Cambié drásticamente mi Pipfile.lock al desinstalar un cambio de fe y ahora implementarlo en una máquina diferente se está congelando. ¿Alguna solución en particular para esto?

No se recomienda que edite manualmente su archivo de bloqueo. Sin más información no es posible ayudar. Abra un problema por separado.

Si desea comparar el rendimiento de pipenv lock, debe intentar agregar pytmx a sus dependencias ...
El bloqueo de pipenv solía llevarnos 1 hora o más (tenemos una Internet bastante lenta), y después de eliminar pytmx, bajamos a unos 5 minutos y finalmente pipenv es más utilizable.
Sé que pytmx es un paquete grande porque es una gran biblioteca monolítica y depende de opengl / pygame y otras cosas relacionadas, pero no debería tomar 1 hora para bloquear pipenv sin importar cuán grande sea el paquete

No me toma una hora

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

Además, PyTMX tiene menos de 20 kb en PyPI y solo tiene una dependencia de seis (lo cual es muy pequeño), por lo que la red no debería ser un problema. Es probable que suceda algo más en su entorno.

tienes razón, es más pequeño de lo que pensaba, no depende explícitamente de pygame y demás, ¡no estoy seguro de por qué estaba tardando tanto entonces!
Intentaré encontrar más información, pero tengo una CPU y un SSD superiores, así que sigo pensando que el problema está relacionado con nuestra conexión lenta a Internet.

@techalchemy No pipenv uninstall package_name y luego lo ejecuté en el servidor. Permaneció en el estado de bloqueo durante mucho tiempo.

No me interesa gastar energía en esta discusión con tomas al azar en la oscuridad. Proporcione un caso de prueba reproducible.

Esto es lo que espero sea un caso de prueba reproducible
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Intentando hacer
pipenv install
en este repositorio sin bloqueo hasta ahora han descargado más de 700 MB aproximadamente mientras se mostraba
Locking [packages] dependencies...

Se rendirá en un momento y volverá a ejecutar con --skip-lock hasta que se solucione

Noté que lock fue muy lento y descargué una gran cantidad de datos de files.pythonhosted.org , más de 800 MB para un proyecto pequeño que depende de scipy flask etc.

Así que olfateé las solicitudes hechas a files.pythonhosted.org , y resultó que pip o pipenv estaban haciendo descargas completamente innecesarias, lo que hace que lock dolorosamente lento.

Por ejemplo, la misma versión numpy había descargado varias veces en su totalidad. Y descargó Wheels para Windows / Linux, aunque estaba usando una Mac.

Mi configuración:

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

¿Son útiles los archivos Pip adicionales para depurar aquí?

Lo más probable es que @AlJohri , también

He estado atrapado aquí durante unos 5 minutos. Primero pensé que podría haber sido algún tipo de problema de instalación de pip y reinstalé todo nuevo a través de Homebrew, pero sigue siendo el mismo problema. ¿Alguna idea de por qué?

Finalmente terminó después de aproximadamente 6 a 7 minutos. Bastante nuevo en Python y Pipenv, por lo que sería genial recibir un poco de ayuda sobre dónde encontrar los archivos necesarios para la depuración. :)

esto es bastante malo hasta el punto de que tengo miedo de instalar nuevas bibliotecas de Python o actualizar las existentes.

Después de ver una de las charlas del creador, decidí usar pipenv . Pero es demasiado lento.

Gracias por sus valiosos comentarios.

@techalchemy Si hay algo que pueda hacer para ayudar y solucionar este problema. Estoy muy feliz de poder contribuir.

Noté que lock fue muy lento y descargué una gran cantidad de datos de files.pythonhosted.org , más de 800 MB para un proyecto pequeño que depende de scipy flask etc.

Tengo la sospecha, aunque no una prueba concluyente, de que scipy está correlacionado con tiempos de bloqueo de pipenv muy largos.

realmente doloroso a veces, estoy instalando PyPDF2 y textract; pipenv tardó ~ 10 minutos en bloquearse.

La lentitud de pipenv realmente dificulta el proceso de desarrollo para nosotros. Ahora les aconsejo a todos que se queden con pip + virtualenv hasta que se resuelva este problema.

¿Alguna noticia sobre esto? ¿Alguna forma de ayudar?
engañado de https://github.com/pypa/pipenv/issues/1914

/ edit: por cierto, ¿por qué pipenv install actualiza las versiones en el archivo de bloqueo? o.Ò Acabo de ejecutarlo después de que se agotó el tiempo de bloqueo y ahora que miro el nuevo archivo de bloqueo, veo que pandas se actualizó de 0.23.4 a 0.24.0, numpy de 0.16.0 a 0.16.1, etc. No espero que eso suceda a menos que yo haya hecho pipenv update ...

Encuentro que se instala rápidamente y se bloquea lentamente, así que tan pronto como reciba el mensaje Installation Succeeded estará bien para continuar trabajando ... a menos que desee instalar algo más ...

... o necesita empujar el archivo de bloqueo a algún repositorio.

¿Debería install realizar el bloqueo de todos modos, ya que lock ya es un comando separado? Mientras tanto, la descripción de la opción install debe especificar que el bloqueo también tiene lugar, y tal vez incluso recomendar --skip-lock .

Además, ¿qué tal fijar este problema?

Pipenv es una herramienta realmente maravillosa y solía recomendarla, pero un proyecto con 8 módulos no se puede bloquear ... simplemente se agota. No parece haber ningún interés en resolver este problema y eso es muy frustrante. Leí que ahora puede obtener dependencias sin descargar de pypy, ¿es una solución para este problema? No veo ninguna charla sobre esa opción aquí. Por el momento, la herramienta no se puede utilizar para mis propósitos.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

¿Cómo no es esta la principal prioridad de este proyecto? Pipenv es tan lento que es prácticamente inutilizable. Y no solo en algunos casos de usos secundarios poco comunes, siempre es súper lento.

Sin saber demasiado sobre lo que está sucediendo bajo el capó, estaba pensando que esto podría resolverse muy bien con un caché local del gráfico de dependencia.

Piénselo: si almacenamos en caché ese paquete x-1.2.3 depende de y>=3.4 , podemos hacer localmente gran parte del trabajo que se realiza actualmente en la descarga de paquetes de uno en uno, expandiéndolos y verificando dependencias . La fase lock sería tan simple como:

• Compare el Pipfile con el caché y asegúrese de que tenemos todo lo que necesitamos.
• Si no es así, descargue algo nuevo y calcule las dependencias allí.
  
  
  
  • Caché los cambios
  
  
• Instalar en pc.

En todos los casos, si bien la primera vez puede ser lenta, los bloqueos posteriores serían indoloros, ¿no?

Decidí usar pipenv en lugar de pip para un proyecto pequeño. Lo primero que hice fue pipenv install -r requirements.txt . Ha estado bloqueando las dependencias durante unos 10 minutos. Por lo tanto, voy a volver a pip.

Chicos, este problema les está costando muchos usuarios. Propongo abordarlo rápidamente.

En mi caso, la instalación de las dependencias en el servidor cuelga el servidor durante horas. Estoy usando la instancia AWS EC2 t2.micro con 1 GB de RAM. Esta cantidad de RAM es suficiente para una sola aplicación con pocas dependencias, pero la instalación ocupa toda la memoria y solo hay una forma de hacer que funcione reiniciando el servidor.

Este problema está pendiente durante tantos años y no se ha solucionado. Veo que se cierran varios problemas sin ninguna resolución.

Una herramienta tan bonita que se descuida. Daré de baja la suscripción a este problema porque veo que nunca se resolverá. Se apegará a algo como conda o lo hará manualmente usando virtualenv.

Supongo que le daré una oportunidad a https://github.com/sdispater/poetry : |

¿Puede un administrador cerrar este hilo con comentarios? Parece que no se está agregando contenido adicional útil a la discusión.

Estaría feliz de suscribir un boleto de seguimiento del trabajo para solucionar el problema.

¡Gracias!

Sospecho que el 99% de las personas que usan esta herramienta y se quejan en este hilo son programadores. En lugar de lloriquear, ponga su tiempo donde está su boca y envíe un PR.

Hola @idvorkin ,

Lo intenté una vez .
Se necesitaron semanas para lograr la fusión de la solución trivial .
Simplemente compare la cantidad de discusiones con el tamaño real de la corrección.

Definitivamente no quiero enviar más arreglos a este proyecto.

Entonces, su consejo no es tan viable como puede suponer.

@Jamim en nombre de los muchos usuarios (y sospecho que los administradores también), gracias por sus contribuciones. Leí tus relaciones públicas y pude sentir empatía por la frustración. Sin embargo, tengo que estar de acuerdo con @techalchemy en este:

Por supuesto que nos preocupamos por la biblioteca que mantenemos, pero sugeriría que la redacción probablemente no sea la forma más efectiva de tener una interacción positiva.

Nunca conocí a los administradores, pero si se parecen a mí (y tal vez a usted), son humanos con vidas ocupadas cuyas vidas están llenas de compromisos incluso antes de tener energía para gastar en este proyecto.

Del mismo modo, apuesto a que si usted (o cualquier otra persona) solucionara el problema de rendimiento, tendría una gran cantidad de personas que lo ayudarían a desarrollarlo, probarlo, fusionarlo o, si es necesario (y dudo mucho que lo sea) crear una bifurcación. .

Estoy agradecido por el tiempo que los desarrolladores de este proyecto están dedicando a esto, pero sugiero que se debe advertir en negrita que este proyecto aún no está listo para producción justo encima de los testimonios de los usuarios en README.md , actualmente es engañar a las personas para que dediquen un tiempo precioso a reemplazar su pila pip / virtualenv actual con pipenv hasta que descubran este bloqueo lento y comprendan que no pueden usarlo.

hasta que se enteren de este bloqueo lento y comprendan que no pueden usarlo.

Si bien estoy muy feliz de aumentar la velocidad, ya que de hecho es muy lento, no hay necesidad de tal hipérbole.

Estoy usando pipenv muy bien todos los días. Las mejoras en el flujo de trabajo que proporciona superan en gran medida la lentitud ocasional. El bloqueo no es algo que haga todo el tiempo, a diferencia de ejecutar scripts, por ejemplo.

¿Con qué frecuencia bloqueas que realmente se convierte en un problema que sientes que no puedes usarlo? :boca abierta:

@bochecha mi declaración puede ser una hipérbole en su opinión, pero es un hecho basado en mi experiencia, escuché sobre pipenv de algunos compañeros de trabajo, hoy intenté actualizar un proyecto antiguo, actualizando sus dependencias, etc. Pensé que vamos a actualizar de pip / virtualenv a pipenv como parte del proceso de actualización. Tuve que actualizar una dependencia, verificar cómo funcionan las cosas con ella, actualizar partes del código si es necesario y luego actualizar otra dependencia, cada vez que ejecuté pipenv install <something> tuve que esperar un tiempo ridículamente largo, primero pensé que estaba calculando algo y lo almacenará en caché para el futuro, ya que no podía creer que fuera un problema en un administrador de paquetes que afirmaba ser listo para producción. Después de instalar ~ 10th paquete comencé a buscar sobre él y encontré este hilo, eliminé Pipfile y Pipfile.lock y volví a mi flujo de trabajo pip / virtualenv. Estuve tentado de probar la poesía, pero no podía arriesgarme ni una hora más.

Esto sucede en la comunidad JS, por ejemplo, pero no lo espero en la comunidad Python, no tenemos este tipo de problemas en nuestra comunidad y deberíamos tratar de evitarlo, un descargo de responsabilidad en README.md puede evitarlo. este inconveniente así que lo sugerí en mi comentario. Podría ahorrarme tiempo hoy y creo que ahorrará tiempo a otros recién llegados y no tendrán una mala experiencia con este proyecto, por lo que pueden permanecer como futuros usuarios potenciales.

Estoy un poco de acuerdo con Sassanh. No todo el mundo se ve igualmente afectado por el problema, pero algunos de nosotros nos afectó bastante. He realizado proyectos de código abierto que no eran realmente completamente funcionales o no estaban listos para la producción y, cuando fue el caso, puse un descargo de responsabilidad para no perder el tiempo de las personas si no están listas para los baches.

No estoy enojado con la gente que trabaja en este proyecto, pero estoy un poco enojado con la persona que hizo una charla pública sobre él, vendiéndolo como una gran herramienta con 0 descargo de responsabilidad. Como resultado, perdí gran parte de mi valioso tiempo tratando de hacer que una herramienta funcionara, con la esperanza de ahorrar tiempo a largo plazo, pero terminé teniendo que volver a pip y a mi propio script, porque pipenv no funcionó. en mi entorno con limitaciones de tiempo y ancho de banda.

cada vez que ejecuté pipenv install

¿Sabías acerca de pipenv install -r requirements.txt para bloquear / instalar solo una vez desde tu proyecto existente cuando intentas moverlo a pipenv? Si no lo hace, ¿el problema podría ser de documentación?

Antes que nada, estoy seguro de que pipenv será un buen reemplazo para el flujo de trabajo pip / virtualenv, supongo que todos sabemos que lo necesitamos y creo que el día en que pipenv esté lista para producción será de gran ayuda para muchas personas / proyectos.

@bochecha, como expliqué, tuve que instalar una versión más nueva de un paquete, hacer algunas cosas y luego ir con el siguiente paquete, tal vez si hiciera este proceso con pip y luego migrara a pipenv, no notaría el problema en absoluto, pero primero migré a pipenv y luego hice las actualizaciones del paquete una por una y fue realmente molesto. Me alegro de que funcione para su caso de uso, pero estoy seguro de que no funciona para muchas personas como yo (eche un vistazo a los comentarios de arriba). Debe mencionarse en el README.md , al menos debe mencionarse que "cada bloqueo puede llevar mucho tiempo, por lo que si su caso de uso incluye instalar / eliminar muchos paquetes rápidamente, debe evitar el uso de pipenv hasta que se solucione este problema resuelto "(nuevamente en negrita, y además de los testimonios) si anuncia los problemas antes de que alguien se vea afectado, todos estarán agradecidos, si los problemas afectan a otros y no les advirtió, todos se enojarán.

Acordado. Comencé a buscar en la poesía y aunque agregué otro usuario a mi sistema operativo por proyecto en lugar de usar pipenv nuevamente. Si no funciona bien para casos de uso casual con la configuración predeterminada, está roto en mi humilde opinión .
¡Es una herramienta súper útil! Solo hay una cosa que lo hace súper inútil para mí. Y lamentablemente tengo poco tiempo para contribuir: |

Claro, es molesto esperar un bloqueo cuando se tienen que hacer varias instalaciones en mitad de la sesión de desarrollo, pero esto se puede administrar.

Lo importante es que se genera un archivo de bloqueo antes de enviar cambios locales al repositorio. Hago un uso juicioso de la bandera —skip-lock durante las sesiones de desarrollo, y pipenv lock una vez al final antes de comprometerme.

Gracias por el proyecto. Pero,
El bloqueo es verrrrrrrrrrrrrrrrrrrrrrrrrrrry lentowwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
Este entorno hace que el bloqueo sea más rápido, si ya tiene instalado un caché de paquete pip.

Hola @yssource y a todos,

Gracias por el proyecto. Pero,
El bloqueo es verrrrrrrrrrrrrrrrrrrrrrrrrrrry lentowwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

Este proyecto parece estar muerto, por lo que si desea eliminar el problema de la velocidad, considere migrar a Poetry, que es significativamente más rápido.

@Jamim , gracias por

Habiendo dicho eso, que el proyecto esté muerto es una gran exageración, y si estuviera en el lugar de los autores pipenv, lo encontraría irrespetuoso. El autor respondió en la sección de problemas ayer. Es solo que se pasa por alto este problema de bloqueo, probablemente porque es difícil de solucionar.

Para el registro, Poetry también sufre de problemas de rendimiento:
https://github.com/sdispater/poetry/issues/338

Tengo el mismo problema en todos mis proyectos.
La causa parece ser pylint.
Pipenv (pip) puede instalarlo correctamente, ¡pero el bloqueo tarda una eternidad!
pipenv, version 2018.11.26

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

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

Escuché mucho sobre pipenv y lo probé hoy,
el bloqueo también es muy lento para mí. Ya han pasado alrededor de 2 minutos, todavía atascado en el bloqueo.
La descarga es bastante rápida, pero el problema está en el bloqueo.
¿Este problema está resuelto?
Estoy usando Pop os 19.10, pipenv, versión 11.9.0 de apt, python 3.7.5.

Quiero llamar la atención sobre este excelente comentario de # 1914 sobre el mismo tema https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 que sugiere que descargar y ejecutar cada dependencia ya no es necesario.

Me pregunto si algún desarrollador podría comentar sobre la viabilidad de este enfoque.

Me di cuenta de que en realidad es más rápido eliminar el entorno y volver a crearlo desde cero para actualizar el archivo de bloqueo.
Esto es cierto tanto para ejecutar pipenv lock como pipenv install some-package

Realmente me gusta pipenv pero no tanto como me gusta mi ancho de banda y mi tiempo. Entonces termino resolviendo el problema usando:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

Deseamos mucha suerte a los desarrolladores ...

@ravexina gracias por la sugerencia, lo intentaré seguro