Pipenv: La actualización de la cerradura es muy lenta

Somos conscientes y tenemos muchos problemas para rastrear este tema. Ver # 1785 # 1886 # 1891 y PR # 1896

npm e yarn tienen la ventaja de no tener que descargar y ejecutar por completo cada paquete potencial para determinar su gráfico de dependencia porque las dependencias se especifican en texto plano. Las dependencias de Python requieren que descarguemos y ejecutemos por completo los archivos de configuración de cada paquete para resolverlos y calcularlos. Esa es la realidad, es un poco lento. Si no puede esperar 2 minutos o siente que no vale la pena el intercambio, siempre puede pasar --skip-lock .

Cerrando para rastrear en los otros temas.

Lo mismo aquí, lo estoy probando ahora mismo y la instalación de django ya está en 10 minutos y listo.

Parece que si intentas instalar un par a la vez, es lento, pero si lo haces uno a la vez, funciona un poco más rápido.

Si puede proporcionar un Pipfile que reproduzca el comportamiento lento, sería útil, gracias.

Las dependencias de Python requieren que descarguemos y ejecutemos por completo los archivos de configuración de cada paquete para resolver y calcular

¿Sigue siendo así cuando el paquete tiene su propio Pipfile.lock , o pipenv lo usará cuando sea posible para determinar las dependencias?

¿Pipenv usará eso cuando sea posible para determinar dependencias?

No. Pipenv es una herramienta de resolución de dependencias de aplicaciones. Cuando otra aplicación usa una dependencia como paquete de Python, deja de ser una aplicación. Sus dependencias están determinadas por setup.py (o setup.cfg o lo que sea que use para cargar en PyPI). Cargar dependencias desde un archivo de bloqueo es una ruta segura al infierno de las dependencias, es probable que nunca lo hagamos.

Sigue siendo super lento

@iddan ¡ Gracias por el recordatorio, Capitán Obvio!

Lo siento, como mantenedor de OSS, sé que a veces los problemas pueden descartarse debido a la edad. Solo quería decir que incluso el tema que se discutió sigue siendo relevante.

@techalchemy nota de --skip-lock arriba es maravillosa. Esta debería ser una opción más accesible o publicitada. ¿Podemos configurarlo como predeterminado en alguna parte?

@techalchemy ¿y si toma 20 minutos con mi nuevo mac pro?

@techalchemy nota de --skip-lock arriba es maravillosa. Esta debería ser una opción más accesible o publicitada. ¿Podemos configurarlo como predeterminado en alguna parte?

Por lo que sé, el beneficio abrumador de pipenv es la garantía de que las dependencias funcionarán bien juntas, no solo para usted, sino para cualquier persona que maneje su código más adelante. El producto de esa garantía, el archivo de bloqueo, toma absolutamente más tiempo del que cualquiera espera o desea, _incluidos los desarrolladores_; consulte el n. ° 2200.

Sin embargo, creo que también puede comprender la oportunidad que tiene pipenv de guiar a los desarrolladores bien intencionados de la comunidad de Python en general hacia un flujo de trabajo que imponga menos preocupaciones a los futuros colaboradores, que podrían haber sido visitantes si se hubieran rendido durante el " averigüe cómo configurar la etapa del entorno de desarrollo "; y menos manos levantadas por futuros mantenedores, que podrían haber sido solo autores de relaciones públicas impulsivos si se hubieran dado por vencidos durante la etapa de "jugar seriamente con los aspectos internos profundos del proyecto".

Si --skip-lock se convirtiera en una bandera permanente en un Pipfile o en una configuración en una configuración de pipenv, la percepción de pipenv se deslizaría lentamente hacia "mejor pip", y solo otro escalón que se desvanecería en el horizonte a medida que la comunidad finalmente aterrizara en un sucesor espiritual menos comprometido.

Es mejor dejarlo disponible solo como env var, o algún otro método cuya aplicación descanse directamente en el territorio _ "su configuración local específica del usuario, su culpa" _, permitiendo que pipenv supere la fase de paso de la lentitud de generación de archivos de bloqueo sin darse por vencido el cambio cultural verdaderamente beneficioso hacia la _explicitud sobre la implícita_ en la gestión de paquetes.

La increíblemente amplia biblioteca estándar de Python es un activo enorme, cuya historia ha pasado por muchas épocas de imponente consistencia. Que la mayoría de los paquetes estándar funcionen bien juntos es una hazaña enorme que implica consideración durante muchos años por parte de muchas personas. Algún día, esa capacidad de juego agradable se extenderá a la mayoría de los proyectos de Python encontrados en la web, lejos, lejos del stdlib, y con mucho, mucho menos PEP requeridos (_y mucho, mucho menos BDFL vacantes por frustración_). El impacto de tal manera unilateral a mantequilla experiencia es difícil de medir, pero algunos lenguajes actuales _did_ se niegan a sacrificar la integridad conceptual para la conveniencia inmediata ... y oh, los lugares a los que va a ir .

Entonces, _sí_, generar el archivo de bloqueo es lento, y _sí_, es frustrante cuando solo querías pip install --save . Pero es solo porque hemos estado metiendo un elefante en el armario durante años, creyendo que no teníamos un enredo de expectativas e intenciones de dependencias externas, porque _ "se instaló bien en mi máquina" _.

La generación de archivos de bloqueo es lenta _sólo_ porque hace explícito lo que todos hemos dado por sentado. Pero _porque_ duele , ajustaremos las cosas para que no. Nos rompimos el brazo porque nos esforzamos por hacer cosas en las que creíamos. Claro, podemos evitar el dolor si no volvemos a usar ese brazo, o podemos ponerlo enyesado mientras sana.

Sería la última persona en decirte que no hagas que pipenv sea conveniente para ti hoy (de lo contrario, sería un desarrollador de mierda, aunque el jurado aún está deliberando), pero te imploro que veas la frustración de la generación de archivos de bloqueo como una creciente dolor mientras la comunidad de Python se convierte en un cuerpo fuerte y saludable con más miembros en pleno funcionamiento de lo que realmente se esperaba al quitar un yeso. Llegamos a Python 3. Lleguemos a la gestión de dependencias en stdlib.

Esto tomó 38 minutos en mi máquina para crear el archivo de bloqueo. Ejecutando Windows 10 y usando Python 3.7

Solo numpy y pillow ya estaban instalados y tardó menos de 1 segundo en instalar numba y 25 minutos en bloquearlo. ¿Pipenv compila a la fuerza todas las bibliotecas en el bloqueo o cómo funciona esto?

Para su información, el bloqueo de omisión persistente solo está esperando a que alguien active el interruptor por auto_envvar_prefix que es una configuración de clic. Me he centrado al 100% en la funcionalidad principal, por lo que aún no he tenido la oportunidad de ver esto, pero sospecho que no es tan difícil.

TLDR; Invocación típica pipenv install : Tiempo : 144,82 reales 33,68 usuario 5,77 sys. Con --skip-lock : Tiempo : 4.54 real 5.33 usuario 0.87 sys.

La instalación de Pandas-datareader falla en el primer intento, posiblemente porque lock cuelga. ¿Es este un problema que alguien más está viendo con otros paquetes?

Utilizando la versión 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Contenido de requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Invocación típica pipenv install . Ejecución cronometrada usando time (BSD).

Resultados : 144.82 real 33.68 usuario 5.77 sys

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

Invocando w \ --skip-lock

Resultados : 4.54 real 5.33 usuario 0.87 sys

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

Creo que https://github.com/pandas-dev/pandas/ puede ser un problema. Es un punto en común con el tiempo para mí también.

Aunque pytest también puede ser un problema: \

Ni siquiera terminará en mi máquina:

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

@ black-snow Recomiendo probarlo en un caparazón diferente. Sin profundizar demasiado en las cosas, parece que pexpect (una biblioteca para interactuar mediante programación con programas CLI interactivos) se usa para detectar el shell desde el que se está ejecutando pipenv, y eso podría estar estancado. pexpect parece un poco excesivo para tal cosa, pero no estoy al tanto de todo el contexto.

@ theY4Kman gracias por el consejo. pipenv funciona bien en otra PC con la misma versión de ubuntu y bash ...

Lea esto mientras espera que pipfile se bloquee ... :) Sería genial si hubiera una solución.

Parece que necesitamos algún tipo de API para analizar y almacenar en caché los paquetes de Python y distribuirlos en un formato compatible con la máquina. Por lo tanto, ya no necesitaremos descargar paquetes completos y analizarlos.

Creo que bundler y ruby ​​gems mantienen y usan algo así.

Java también tiene archivos POM (XML) que contienen dependencias de paquetes y otra información sobre el paquete. Se cargan por separado de los archivos JAR compilados.

Cada administrador de paquetes más nuevo tiene algunos metaarchivos separados (npm / yarn, composer, gradle / maven, cargo, ruby ​​gems / bundler, ...).

asunto relacionado:
https://github.com/pypa/warehouse/issues/474

Puede obtener información de dependencia de PyPi sin descargar el paquete completo (consulte PEP 566, que reemplazó a PEP 426).

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

@techalchemy, ¿viste el comentario de arriba?

Esto está sucediendo de manera bastante constante, esencialmente pipenv yendo por la ciudad mientras "bloquea" algo: ¿por qué está cerrado este problema?

Comprenda que --skip-lock es el camino a seguir, pero no está claro en absoluto por qué la "instalación" demora unos segundos y el "bloqueo" demora una eternidad: sería genial si al menos el comando de bloqueo emitiera algún progreso / actualizar registros: tal como están las cosas, ni siquiera está claro si se atascó en algún tipo de while True para siempre ...

Al menos me gustaría saber si soy yo haciendo algo mal, o simplemente una "característica" de pipenv.

En nuestro proyecto pipenv lock es tan lento. Definitivamente afectó nuestro uso normal. Agregar un nuevo paquete se convierte en un verdadero dolor de cabeza para nosotros ahora. ¿Hay alguna forma de que podamos depurar este comportamiento?

Estoy tratando de instalar PyTorch y tardó 20 minutos en bloquearse y luego aparece el siguiente error

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

El error no es correcto, no tengo idea de qué salió mal. ¡La instalación con pip en el medio ambiente funciona bien! Esto es realmente un tapón de espectáculo. Volviendo a requirements.txt ...

Esta es la solución alternativa que uso por ahora:

export PIPENV_SKIP_LOCK=true

Entonces pipenv install foo no se bloqueará y puede bloquear manualmente cuando tenga tiempo ejecutando pipenv lock .

@awhillas Estoy bastante seguro de que la última línea dice todo lo que necesitas:

Intentó instalar "pytorch". El paquete con el nombre de PyTorch es "antorcha"

El bloqueo de las dependencias es importante, por lo que no creo que "omitir el bloqueo" sea una solución duradera. Al mismo tiempo, simplemente no creo que las "dependencias de bloqueo" (lo que sea que pueda implicar bajo el capó) esté optimizada al máximo como está ahora y que funcionalmente requiera muchos minutos u horas para completarse. De hecho, mi bloqueo pipenv se ejecutó durante varios minutos en un Pipfile que tiene 5 dependencias ridículas antes de fallar (pila adjunta en la parte inferior) y durante ese tiempo usó solo el 10-15% de la CPU disponible y un pequeño sorbo de memoria.

¿Podemos al menos hacer un esfuerzo grupal para perfilar y determinar los cuellos de botella? Tengo la sensación de que solo hay una fruta madura tonta que está esperando para llevar este proceso a un tiempo de ejecución razonable.

pipenv version 2018.11.26

Para Pipfile:

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

[packages]

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

[requires]
python_version = ">=3.6"

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

During handling of the above exception, another exception occurred:

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

Como apéndice al comentario anterior, ejecutar pip lock separado tomó una cantidad de tiempo razonable, ~ 15 segundos, después de ejecutar pip install --skip-lock . Entonces, tal vez la invocación de bloqueo posterior a la instalación esté desactualizada o sea defectuosa. :)

Para su información, descubrí que tensorflow es el culpable del bloqueo lento / de tiempo de espera, ¡si eso ayuda al perfil de pipenv! (Aún así, considere esto un problema de pipenv ...)

Tensorflow es uno de los muchos paquetes que pueden hacer que pipenv se convierta básicamente en una herramienta inútil. Sin embargo, me gusta la sugerencia de la elaboración de perfiles de grupo. Creo que es una excelente idea para empezar a abordar este problema. Solo para repetir, PEP 566 habilitó la enumeración de la dependencia (a través de pypi) sin cargar la fuente completa, lo que puede ser útil: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz por lo que veo, descargar todos los paquetes de las dependencias es donde se pasa la mayor parte del tiempo. Esto también se ha confirmado antes.

Cómo verificar esto:

• Intente crear un nuevo Pipfile e instalar scipy (por ejemplo) en él con el bloqueo habilitado
• Espere hasta que se complete el bloqueo. (Tarda unos 5 minutos en mi máquina)
• eliminar Pipfile.lock
• ejecutar pipenv lock - bloquear ahora tomará muy poco tiempo (6 segundos en mi máquina), porque todos los paquetes ya están descargados y guardados en la caché de Pipenv, que normalmente se encuentra en ~/.cache/pipenv

Aquí está el Dockerfile que usé para probar esto:

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

@shtratos Sí, eso tiene sentido y otros lo han sugerido en este tema. Descargar y analizar dependencias es caro. Algunos de esos pasos parecen eliminarse extrayendo de la API de dependencia de pypi.

Para algunas bibliotecas, esto probablemente no funcionará debido a la mala calidad y las malas prácticas (no usar setup.py o requirements.txt). Pero dado que algunos de los principales infractores parecen ser bibliotecas muy populares (tensorflow, numpy), implementar esto con un retroceso al proceso súper lento podría ser un buen camino a seguir.

¿Puede indicarme dónde encontrar ese código? Podría intentar paralelizarlo en una bifurcación.

Creo que https://github.com/pandas-dev/pandas/ puede ser un problema. Es un punto en común con el tiempo para mí también.

Aunque pytest también puede ser un problema: \

No lo creo, funciona bien en mi máquina, el problema parece ser más general que eso

En mi caso, el problema parece ser pylint. Siempre se bloquea cuando se ejecuta simplemente pipenv install pylint ver https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

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

Ejemplo de trabajo mínimo

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

Somos conscientes y tenemos muchos problemas para rastrear este tema. Ver # 1785 # 1886 # 1891 y PR # 1896

npm e yarn tienen la ventaja de no tener que descargar y ejecutar por completo cada paquete potencial para determinar su gráfico de dependencia porque las dependencias se especifican en texto plano. Las dependencias de Python requieren que descarguemos y ejecutemos por completo los archivos de configuración de cada paquete para resolverlos y calcularlos. Esa es la realidad, es un poco lento. Si no puede esperar 2 minutos o siente que no vale la pena el intercambio, siempre puede pasar --skip-lock .

Cerrando para rastrear en los otros temas.

3 de los 4 otros problemas ya están cerrados y el restante no ha tenido actividad desde 2018. Este problema aún persiste, así que quizás volver a abrirlo sería una buena idea.

Las dependencias de Python requieren que descarguemos y ejecutemos por completo los archivos de configuración de cada paquete para resolver y calcular

No creo que eso siga siendo cierto para las ruedas, ¿cuál debería ser la mayoría de los paquetes ahora?

Sé que al menos tengo que construir la rueda para dlib cada vez, lo cual es horrible.

El proceso de resolución de dependencias debe almacenarse en caché en algún lugar según la versión del paquete, incluso si requiere otra búsqueda remota en el cliente cada vez para obtener el árbol (no debería, podría almacenarlo en caché localmente también después del hecho ). Por ejemplo, los repositorios de paquetes podrían almacenar fácilmente árboles de depósito resueltos. El impacto de red adicional para el árbol de depuración resuelto en caché siempre sería más rápido que descargar un paquete completo y la computación.

FWIW He eliminado pipenv de todos mis proyectos (esta es la razón principal, hay otras).

virtualenv + pip (con requirements.txt ) ahora funcionan bastante bien, incluso para implementaciones de Prod; y en cualquier caso, uno despliega un contenedor completamente formado estos días; después de meterme realmente en pipenv, ya no le veo el sentido.

Vuelve a abrir este problema.
De lo contrario, pipenv nunca será la herramienta de empaquetado de referencia