Pipenv: A atualização do bloqueio é muito lenta

Estamos cientes e temos muitos problemas para rastrear este tópico. Consulte # 1785 # 1886 # 1891 e PR # 1896

O npm e o yarn têm a vantagem de não ter que baixar e executar totalmente cada pacote potencial para determinar seu gráfico de dependências porque as dependências são especificadas em texto simples. As dependências do Python exigem que baixemos e executemos totalmente os arquivos de instalação de cada pacote para resolver e calcular. Essa é a realidade, é um pouco lento. Se você não puder esperar 2 minutos ou achar que não vale a pena trocar, você sempre pode passar --skip-lock .

Fechando para acompanhar nas outras questões.

O mesmo aqui estou tentando fazer agora e instalar o Django já está em 10 minutos e indo

parece que se você tentar instalar alguns de cada vez ficará lento, mas se você fizer um de cada vez, funciona um pouco mais rápido

Se você puder fornecer um Pipfile que reproduz o comportamento lento, seria útil - obrigado

As dependências do Python exigem que baixemos e executemos totalmente os arquivos de instalação de cada pacote para resolver e calcular

Este ainda é o caso quando o pacote tem seu próprio Pipfile.lock , ou o pipenv usará isso quando possível para determinar dependências?

o pipenv usará isso quando possível para determinar dependências?

Não. O Pipenv é uma ferramenta de resolução de dependências de aplicativos. Quando uma dependência é usada como um pacote Python por outro aplicativo, não é mais um aplicativo. Suas dependências são determinadas por setup.py (ou setup.cfg ou o que quer que você use para fazer upload para o PyPI). Carregar dependências de um arquivo de bloqueio é um caminho certo para o inferno das dependências, provavelmente nunca faremos isso.

Ainda é super lento

@iddan Obrigado pelo lembrete, Capitão Óbvio!

Desculpe, como mantenedor do software de fonte aberta, eu sei como às vezes os problemas podem ser ignorados por causa da idade. Só queria afirmar que mesmo o problema foi discutido ainda é relevante

A nota --skip-lock acima é maravilhosa. Esta deve ser uma opção mais acessível ou divulgada. Podemos defini-lo como padrão em algum lugar?

@techalchemy e se demorar 20 minutos com meu novo mac pro?

A nota --skip-lock acima é maravilhosa. Esta deve ser uma opção mais acessível ou divulgada. Podemos defini-lo como padrão em algum lugar?

Pelo que entendi, o grande benefício do pipenv é que as dependências de garantia funcionarão bem juntas - não apenas para você, mas para qualquer um que lidará com seu código posteriormente. O produto dessa garantia, o arquivo de bloqueio, absolutamente leva mais tempo do que qualquer um espera ou deseja, _incluindo os devs_ - veja # 2200.

No entanto, acho que você também pode entender a oportunidade que pipenv tem de orientar desenvolvedores bem-intencionados na comunidade Python em geral em direção a um fluxo de trabalho que impõe menos preocupação a futuros colaboradores - que poderiam ter sido apenas visitantes se tivessem desistido durante o " descobrir como configurar o estágio do ambiente de desenvolvimento; e menos mãos levantadas por futuros mantenedores - que poderiam ter sido apenas autores de relações públicas se tivessem desistido durante o estágio de "mexer seriamente com os detalhes internos do projeto".

Se --skip-lock se tornasse uma bandeira permanente em um Pipfile ou uma configuração em uma configuração pipenv, a percepção de pipenv deslizaria lentamente em direção a "melhor pip", e apenas mais um degrau desaparecendo no horizonte quando a comunidade finalmente pousou um sucessor espiritual menos comprometedor.

Melhor deixá-lo disponível apenas como um env var, ou algum outro método cujo aplicativo repousa diretamente no território _ "sua configuração local específica do usuário, sua falha" _, permitindo que o pipenv supere a fase de passagem da lentidão de geração de lockfile sem desistir a mudança cultural verdadeiramente benéfica em direção a _explicidade em vez de implicitude_ no gerenciamento de pacotes.

A biblioteca padrão incrivelmente vasta do Python é um recurso enorme, cuja história passou por muitas eras de consistência imponente. O fato de a maioria dos pacotes padrão funcionarem bem juntos é um feito enorme que envolve consideração por muitos anos por muitas pessoas. Um dia, essa habilidade play-nice-se estenderá para a maioria dos projetos Python encontrados na web - longe, longe do stdlib, e com muito, muito menos PEPs necessários (_e muito menos BDFLs desocupando em frustração_). O impacto de tal unilateralmente amanteigado experiência é difícil de medir, mas alguns idiomas atuais _did_ se recusam a comprometer a integridade conceitual para conveniência imediata ... e oh, os lugares que vou Ir .

Então _sim_, gerar o arquivo de bloqueio é lento, e _sim_, é frustrante quando você só queria pip install --save . Mas é só porque temos varrido um elefante para dentro do armário por anos - acreditando que não tínhamos uma confusão emaranhada de expectativas e intenções de dependências externas, porque _ "instalou perfeitamente na minha máquina" _.

A geração de arquivos de bloqueio é lenta _somente_ porque torna explícito o que todos nós consideramos garantido. Mas _porque_ dói , vamos ajustar as coisas para que não

Eu seria a última pessoa a lhe dizer para não tornar o pipenv conveniente para você hoje (caso contrário, eu seria um péssimo desenvolvedor - _embora o júri ainda esteja decidido_), mas eu imploro que você veja a frustração da geração de lockfile como um crescimento dor enquanto a comunidade Python se desenvolve em um corpo forte e saudável com membros mais funcionais do que se esperava ao remover um gesso. Chegamos ao Python 3. Vamos chegar ao gerenciamento de dependências no stdlib.

Isso levou 38 minutos na minha máquina para criar o arquivo de bloqueio. Executando o Windows 10 e usando Python 3.7

Apenas o numpy e o travesseiro já estavam instalados e demorou <1 segundo para instalar o numba e 25 minutos para travá-lo. O pipenv compila à força cada lib no bloqueio ou como isso funciona?

O bloqueio de salto persistente para sua informação está apenas esperando que alguém mude o botão para auto_envvar_prefix que é uma configuração de clique. Tenho estado 100% focado na funcionalidade central, então não tive a chance de olhar para isso ainda, mas suspeito que não seja tão difícil

TLDR; Invocação pipenv install típica: Tempo : 144,82 reais 33,68 usuário 5,77 sys. Com --skip-lock : Tempo : 4,54 reais 5,33 usuário 0,87 sys.

A instalação do Pandas-datareader falha na primeira tentativa, possivelmente por causa do travamento de lock . Este é um problema que alguém está vendo em outros pacotes?

Usando a versão 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Conteúdo de requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Invocação típica de pipenv install . Execução cronometrada usando time (BSD).

Resultados : 144,82 reais 33,68 usuário 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 reais 5,33 usuário 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

Acho que https://github.com/pandas-dev/pandas/ pode ser um problema? É um ponto comum com o tempo para mim também.

Embora pytest também possa ser um problema: \

Nem vai terminar na minha 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, eu recomendo tentar em uma concha diferente. Sem mergulhar muito fundo nas coisas, parece que o pexpect (uma biblioteca para interface programática com programas CLI interativos) é usado para detectar o shell a partir do qual o pipenv está sendo executado, e isso pode estar travando. Esperar parece um exagero para tal, mas não estou ciente de todo o contexto.

@ theY4Kman obrigado pelo conselho. pipenv está funcionando bem em outro pc com o mesmo ubuntu e versão bash ...

Leia enquanto espera o pipfile bloquear ... :) Seria ótimo se houvesse uma solução.

Parece que precisamos de algum tipo de API para analisar e armazenar em cache deps de pacotes Python e distribuí-los em um formato amigável à máquina. Portanto, não precisaremos mais baixar pacotes inteiros e analisá-los.

Eu acredito que bundler e ruby ​​gems mantêm e usam algo assim.

Java também possui arquivos POM (XML) que contêm dependências do pacote e outras informações sobre o pacote. Eles são carregados separadamente dos JARs compilados.

Cada gerenciador de pacotes mais recente possui alguns meta arquivos separados (npm / yarn, composer, gradle / maven, cargo, ruby ​​gems / bundler, ...).

questão relacionada:
https://github.com/pypa/warehouse/issues/474

Você pode obter informações de dependência do PyPi sem baixar o pacote completo (consulte PEP 566, que substituiu o 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 você viu o comentário acima?

Isso está acontecendo de forma bastante consistente, essencialmente pipenv viajando pela cidade enquanto "trava" algo: por que esse problema foi encerrado?

Entenda que --skip-lock é o caminho a seguir, mas não está claro por que "instalar" leva alguns segundos e "travar" leva uma eternidade: seria ótimo se pelo menos o comando de bloqueio emitisse algum progresso / logs de atualização: do jeito que as coisas estão, nem mesmo está claro se ficou preso em algum tipo de while True para sempre ...

Eu pelo menos gostaria de saber se sou eu fazendo algo errado ou apenas um "recurso" do pipenv.

Em nosso projeto pipenv lock é tão lento. Definitivamente afetou nosso uso normal. Adicionar um novo pacote se torna uma verdadeira dor para nós agora. Existe alguma maneira de depurar esse comportamento?

Estou tentando instalar o PyTorch e demorou 20 minutos para travar e, em seguida, puxa o seguinte erro

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

O erro não foi lido, não tenho ideia do que deu errado. Instalar com pip no ambiente funciona bem! Este é realmente um obstáculo. Voltando para requirements.txt ...

Esta é a solução alternativa que utilizo agora:

export PIPENV_SKIP_LOCK=true

Então pipenv install foo não estará bloqueando e você pode bloquear manualmente quando tiver tempo, executando pipenv lock .

@awhillas Com certeza, a última linha diz tudo o que você precisa:

Você tentou instalar o "pytorch". O pacote com o nome de PyTorch é "tocha"

Bloquear dependências é importante, então não acho que "ignorar bloqueio" seja uma solução duradoura. Ao mesmo tempo, eu simplesmente não acredito que o "bloqueio de dependências" (o que quer que isso possa acarretar nos bastidores) seja otimizado ao máximo como está agora e funcionalmente requer muitos minutos ou horas para ser concluído. De fato, meu bloqueio pipenv foi executado por vários minutos em um Pipfile que tem 5 dependências ridículas antes de falhar - pilha conectada na parte inferior - e durante esse tempo usou apenas 10-15% da CPU disponível e um pequeno gole de memória.

Podemos pelo menos fazer algum esforço de grupo para traçar o perfil e determinar os gargalos? Tenho a sensação de que há apenas alguns frutos tolos ao alcance da mão, apenas esperando para levar esse processo a um tempo de execução razoável.

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 um adendo ao comentário anterior, executar pip lock separadamente levou um tempo razoável, cerca de 15 segundos, após executar pip install --skip-lock . Portanto, talvez a chamada de bloqueio pós-instalação esteja desatualizada ou com defeito. :)

Para sua informação, descobri que o tensorflow é o culpado do bloqueio lento / temporizado, se isso ajuda o perfil pipenv! (Ainda considero isso um problema pipenv ...)

Tensorflow é um dos muitos pacotes que podem fazer com que o pipenv se torne basicamente uma ferramenta inútil. Eu gosto da sugestão de criação de perfil de grupo, no entanto. Acho que é uma excelente ideia para começar a lidar com esse problema. Apenas para reiterar, o PEP 566 habilitou enumeração de dependência (via pypi) sem carregar a fonte inteira, o que pode ser útil: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz pelo que vejo, baixar todos os pacotes das dependências é onde gasta a maior parte do tempo. Isso também foi confirmado antes.

Como verificar isso:

• Tente criar um novo Pipfile e instalar scipy (por exemplo) nele com o bloqueio ativado
• Espere até que o bloqueio seja concluído. (Demora cerca de 5 minutos na minha máquina)
• remover Pipfile.lock
• execute pipenv lock - o bloqueio agora levará muito pouco tempo (6 segundos na minha máquina), porque todos os pacotes já foram baixados e mantidos no cache do Pipenv que normalmente está em ~/.cache/pipenv

Este é o Dockerfile que usei para testar isso:

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 Sim, isso faz sentido e outros sugeriram isso neste tópico. O download e a análise de dependências são caros. Algumas dessas etapas parecem que podem ser eliminadas puxando da API de dependência pypi.

Para algumas bibliotecas, isso provavelmente não funcionará, devido à má qualidade e às práticas inadequadas (não usando setup.py ou requirements.txt). Mas, uma vez que alguns dos principais infratores parecem ser bibliotecas muito populares (tensorflow, numpy), implementar isso com um fallback para o processo super lento pode ser um bom caminho a seguir.

Você pode me apontar a direção de onde encontrar esse código? Eu poderia tentar paralelizar isso em um garfo.

Acho que https://github.com/pandas-dev/pandas/ pode ser um problema? É um ponto comum com o tempo para mim também.

Embora pytest também possa ser um problema: \

Acho que não, funciona bem na minha máquina, o problema parece ser mais geral do que isso

No meu caso, o problema parece ser pylint. Ele sempre trava quando simplesmente executa pipenv install pylint consulte https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

Tenho o mesmo problema em todos os meus projetos.
A causa parece ser pylint.
Pipenv (pip) pode instalá-lo com sucesso, mas o bloqueio leva uma eternidade!
pipenv, version 2018.11.26

Exemplo de trabalho 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...

Estamos cientes e temos muitos problemas para rastrear este tópico. Consulte # 1785 # 1886 # 1891 e PR # 1896

O npm e o yarn têm a vantagem de não ter que baixar e executar totalmente cada pacote potencial para determinar seu gráfico de dependências porque as dependências são especificadas em texto simples. As dependências do Python exigem que baixemos e executemos totalmente os arquivos de instalação de cada pacote para resolver e calcular. Essa é a realidade, é um pouco lento. Se você não puder esperar 2 minutos ou achar que não vale a pena trocar, você sempre pode passar --skip-lock .

Fechando para acompanhar nas outras questões.

3 dos 4 outros problemas estão encerrados e o restante não teve nenhuma atividade desde 2018. Esse problema ainda persiste, então talvez seja uma boa ideia reabri-lo?

As dependências do Python exigem que baixemos e executemos totalmente os arquivos de instalação de cada pacote para resolver e calcular

Não acho que isso ainda seja verdade para as rodas, que devem ser a maioria dos pacotes agora?

Eu sei que pelo menos tenho que construir a roda para dlib todas as vezes, o que é horrível.

O processo de resolução de dependências deve ser armazenado em cache em algum lugar com base na versão do pacote, mesmo que exija outra pesquisa remota no cliente a cada vez para obter a árvore (não deveria, você poderia apenas armazená-la em cache localmente após o fato ) Por exemplo, repositórios de pacotes podem facilmente armazenar árvores dep resolvidas. O acerto de rede adicional para a árvore dep resolvida em cache sempre seria mais rápido do que baixar um pacote inteiro e a computação.

FWIW Eu removi pipenv de todos os meus projetos (sendo este o motivo principal, existem outros).

virtualenv + pip (com requirements.txt ) agora funciona muito bem, mesmo para implantações Prod; e, em qualquer caso, um contêiner totalmente formado nos dias de hoje; depois de entrar realmente no pipenv, não vejo mais o sentido disso.

Reabra este problema.
Caso contrário, o pipenv nunca será a ferramenta de embalagem de referência