Pipenv: O bloqueio é lento (e executa downloads redundantes)

@colllin Você verificou se os comandos pip que contatam o servidor - como pip search (eu acho) - também são lentos?

Vejo um comportamento semelhante, mas é um tipo de problema conhecido e dependente da rede. Por algum motivo, o acesso a pypi.org da minha rede de trabalho é incrivelmente lento, mas normalmente é rápido da minha rede doméstica. Acho que o bloqueio faz muitas transações pip por baixo do capô, então o acesso lento ao servidor retarda muito a operação.

EDIT: também pode ser que você apenas tenha um monte de subdependências para resolver - quão grande é o ambiente uma vez criado (por exemplo, quantos pacotes de nível superior em seu pipfile e quantos pacotes retornados por pip list uma vez que o ambiente é inicializado)?

Obrigado pela resposta atenciosa.

pip search não é especialmente rápido ou lento para mim ... ~ 1 segundo?

Perdoe-me por minha falta de conhecimento sobre o domínio: é realmente necessário realizar a pesquisa pip? Não acabou de instalar tudo? Não é necessário apenas anotar o que já está instalado? Ou ... já que garante a existência do arquivo de bloqueio de qualquer maneira, ele poderia fazer isso enquanto instala os pacotes ou antes?

Eu estou supondo ... pipenv usa pip sob o capô? portanto, o processo de instalação é uma caixa preta e ele não pode saber o gráfico de dependência do que foi / será instalado sem fazer ~ uma pesquisa de pip ~ suas próprias consultas de pip?

EDIT: Há 1 pacote de nível superior e ~ 65 pacotes devolvidos por pip list neste repositório específico.

Não sou um contribuidor do projeto e no momento não sei todos os detalhes, mas meu entendimento é que a fase de bloqueio é onde todas as dependências são resolvidas e fixadas. Portanto, se você tiver um pacote de nível superior com ~ 65 dependências, é durante a fase de bloqueio que todas as dependências desse primeiro pacote são (recursivamente) descobertas e, em seguida, a árvore de dependências é usada para resolver quais pacotes precisam ser instalados e (provavelmente) em que ordem aproximada eles devem ser instalados. Não tenho tanta certeza sobre a última parte.

Se você instalar a partir de um Pipfile sem um arquivo de bloqueio presente, você notará que ele faz a fase de bloqueio antes de instalar os pacotes no venv. Da mesma forma, se você tiver um arquivo de bloqueio, mas ele estiver desatualizado. Suspeito que ter um arquivo de bloqueio e instalar usando a opção --deploy seria mais rápido, assim como a opção --no-lock ; no primeiro caso, você obtém um erro se o arquivo de bloqueio estiver desatualizado; no último, você perde a divisão lógica dos pacotes de nível superior (ambiente declarado) e o ambiente real instalado (bloqueado) de todos os pacotes. Pelo menos é assim que eu entendo.

Independentemente de o pipenv usar ou não pip sob o capô - eu acho que sim - ele ainda precisa obter as informações do (s) servidor (es) pypi sobre dependências de pacotes e similares, então minha pergunta sobre a pesquisa de pip era mais um proxy de quão rápido ou retardar seu caminho para o servidor pypi é mais do que uma implicação direta sobre o mecanismo pelo qual o pipenv faz seu trabalho.

Um experimento interessante pode ser comparar o tempo necessário para bloquear a árvore de dependências no pipenv e instalar os requisitos em um novo venv usando pip install -r requirements.txt . Acho que eles deveriam estar fazendo coisas semelhantes durante a fase de resolução de dependência.

Estabelecemos em algum lugar que há downloads redundantes acontecendo aliás? Suspeito que seja o caso, mas prová-lo seria muito útil

Para sua informação, comparar pip install -r requirements.txt com o tempo que leva para bloquear um gráfico de dependência não será informativo como ponto de comparação. Na verdade, o Pip não _tem_ um resolvedor, não em nenhum sentido real. Acho que posso descrever a diferença. Quando o pip instala seu requirements.txt , ele segue este processo básico:

• Encontre o primeiro requisito listado
  
  
  
  • Encontre todas as suas dependências
  
  
  • Instale todos eles
  
  
• Encontre o segundo requisito listado
  
  
  
  • Encontre todas as suas dependências
  
  
  • Instale todos eles
  
  
• Encontre o terceiro requisito listado
  
  
  
  • Encontre todas as suas dependências
  
  
  • Instale todos eles
  
  

Isso acabou sendo muito rápido porque o pip realmente não se importa se as dependências do _pacote 1_ entraram em conflito com as dependências do _pacote 3_, ele apenas instalou as do _pacote 3_ por último, então é isso que você obtém.

Pipenv segue um processo diferente - calculamos um gráfico de resolução que tenta satisfazer _todas_ as dependências que você especifica, antes de construir seu ambiente. Isso significa que temos que começar a baixar, comparar e, muitas vezes, até mesmo _construir_ pacotes para determinar a aparência final do seu ambiente, tudo antes mesmo de começarmos o processo real de instalá-lo (há muitas postagens de blog sobre por que isso é o caso em python, então não entrarei mais nele aqui).

Cada etapa desse processo de resolução torna-se mais dispendiosa em termos computacionais, exigindo hashes, o que é uma prática recomendada. Fazemos hash dos pacotes recebidos após recebê-los, depois os comparamos com os hashes que o PyPI nos disse que deveríamos esperar e armazenamos esses hashes no arquivo de bloqueio para que, no futuro, as pessoas que desejam construir um ambiente idêntico possam fazê-lo com a garantia contratual de que os pacotes a partir dos quais eles constroem são os mesmos que você usou originalmente.

A pesquisa do Pip é um benchmark pobre para tudo isso, na verdade qualquer uma das ferramentas do pip é um benchmark ruim para fazer este trabalho - usamos o pip para cada parte dele, mas juntando-o em conjunto e entre muitas dependências para formar e gerenciar ambientes e gráficos é onde o valor de pipenv é adicionado.

Um ponto de esclarecimento - depois de resolver o gráfico de dependência completo, a ordem de instalação não importa mais. Sob o capô, nós realmente passamos --no-deps para cada instalação de qualquer maneira.

Como uma pequena observação, a pesquisa de pip é atualmente a única peça do conjunto de ferramentas do pip que depende da interface XMLRPC, agora obsoleta, que não pode ser armazenada em cache e é muito lenta. Sempre será mais lento do que qualquer outra operação.

O bloqueio numpy (e nada mais) leva 220 s na minha máquina (veja abaixo). A maior parte do tempo parece ser gasto baixando mais de 200 MB de dados, o que é bastante intrigante, visto que toda a fonte numpy tem 4 MB. Embora claramente, mesmo que tenha sido instantâneo, ainda há 25 s de processamento real, e mesmo isso parece excessivo para calcular alguns hashes. O bloqueio subsequente, mesmo após a exclusão de Pipenv.lock, leva 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

O Numpy deve ser substancialmente mais rápido agora (estou usando seu exemplo como um caso de teste, na verdade!). No meu teste mais recente, eu o tinha em ~ 30s em um cache frio em uma VM.

Você pode confirmar alguma melhoria com a versão mais recente?

Também melhorou substancialmente para mim. Agora estou sentado em uma conexão muito rápida e chegou a apenas 14 s, mas foi quando o download foi de 30 MB / s. O que está sendo baixado além de uma única cópia do código-fonte do numpy?

Acho que estamos baixando rodas redundantes (não tenho certeza). Já estamos avaliando a situação.

Mudei meu Pipfile.lock drasticamente desinstalando as alterações fe e agora implantá-lo em uma máquina diferente está congelando. Alguma correção específica para isso?

Não é recomendado que você edite manualmente seu lockfile. Sem mais informações não é possível ajudar. Abra um exemplar separado.

Se você quiser avaliar o desempenho do bloqueio pipenv, você deve tentar adicionar pytmx às suas dependências ...
O bloqueio pipenv costumava levar 1 hora ou mais para nós (temos uma internet muito lenta), e depois de remover o pytmx, baixamos para cerca de 5 minutos e finalmente o pipenv é mais utilizável.
Eu sei que o pytmx é um pacote grande porque é uma grande biblioteca monolítica e depende do opengl / pygame e outras coisas relacionadas, mas não deve demorar 1 hora para bloquear o pipenv, não importa o tamanho do pacote

Não leva uma hora para mim

$ 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

Além disso, o PyTMX tem menos de 20kb no PyPI e tem apenas uma dependência para seis (o que é muito pequeno), portanto, a rede não deve ser um problema. Provavelmente, algo mais está acontecendo em seu ambiente.

você está certo é menor do que eu pensei, não depende explicitamente de pygame e tal, não sei por que estava demorando tanto então!
Vou tentar encontrar mais informações, mas tenho uma CPU e um SSD de primeira, então ainda acho que o problema está relacionado à nossa Internet lenta

@techalchemy Não pipenv uninstall package_name e depois executei no servidor. Ele permaneceu no estado de bloqueio por um longo tempo.

Não estou interessado em gastar energia nesta discussão com fotos aleatórias no escuro. Forneça um caso de teste reproduzível.

Espero que seja um caso de teste reproduzível
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Tentando fazer
pipenv install
neste repositório sem bloqueio, até agora baixou mais de 700 MBs enquanto ele era exibido
Locking [packages] dependencies...

Desistirá em breve e será executado novamente com --skip-lock até que seja consertado

Percebi que lock estava muito lento e baixei uma grande quantidade de dados de files.pythonhosted.org , mais de 800 MB para um pequeno projeto que depende de scipy flask etc.

Então, cheirei as solicitações feitas para files.pythonhosted.org e descobri que o pip ou pipenv estava fazendo downloads completamente desnecessários, o que torna lock dolorosamente lento.

Por exemplo, a mesma versão numpy foi baixada várias vezes na íntegra. E baixou o wheel para windows / linux, embora eu estivesse usando um Mac.

Minha configuração:

$ pipenv --version
pipenv, version 2018.05.18

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

são Pipfiles adicionais úteis para depuração aqui?

Provavelmente @AlJohri , também qualquer informação sobre a execução de processos / locks / io ajudaria

Já estou preso aqui há cerca de 5 minutos. Primeiro pensei que poderia ter sido algum tipo de problema de instalação pip e reinstalei tudo novo via Homebrew, mas ainda assim o mesmo problema. Alguma ideia por quê?

Finalmente terminei após cerca de 6 a 7 minutos. Muito novo em Python e Pipenv, então uma ajudinha sobre onde encontrar os arquivos necessários para depuração seria ótimo! :)

isso é muito ruim a ponto de eu ter medo de instalar novas bibliotecas python ou atualizar as existentes.

Depois de assistir a uma das palestras do criador, decidi usar pipenv . Mas é muito lento.

Obrigado pelo seu feedback perspicaz.

@techalchemy Se houver algo que eu possa fazer para ajudar e consertar isso. Estou muito feliz em contribuir.

Percebi que lock estava muito lento e baixei uma grande quantidade de dados de files.pythonhosted.org , mais de 800 MB para um pequeno projeto que depende de scipy flask etc.

Suspeito, embora não sejam evidências conclusivas, de que scipy está correlacionado com pipenv tempos de bloqueio muito longos.

realmente doloroso às vezes, estou instalando PyPDF2 e textract; pipenv levou cerca de 10 minutos para bloquear.

A lentidão do pipenv realmente atrapalha o processo de desenvolvimento para nós. Aconselho agora a todos que fiquem com pip + virtualenv até que esse problema seja resolvido.

Alguma novidade sobre isso? Alguma maneira de ajudar?
dupe de https://github.com/pypa/pipenv/issues/1914

/ edit: aliás, por que pipenv install atualiza as versões no arquivo de bloqueio? o.Ò Acabei de executá-lo após o tempo de bloqueio expirar e agora que vejo o novo arquivo de bloqueio, vejo que o pandas foi atualizado de 0.23.4 para 0.24.0, numpy de 0.16.0 para 0.16.1, etc ... Não não espere que isso aconteça a menos que eu tenha feito pipenv update ...

Acho que ele é instalado rapidamente e travado lentamente, então, assim que receber a mensagem Installation Succeeded você pode continuar trabalhando ... a menos que queira instalar outra coisa ...

... ou precisa enviar o arquivo de bloqueio para algum repositório.

Deveria install estar executando o bloqueio de qualquer maneira, visto que lock já é um comando separado? Nesse ínterim, a descrição da opção install deve especificar que o bloqueio também ocorre, e talvez até recomendar --skip-lock .

Além disso, que tal fixar esse problema?

Pipenv é uma ferramenta realmente maravilhosa e eu costumava recomendar, mas um projeto com 8 módulos não pode travar ... simplesmente atinge o tempo limite. Não parece haver interesse em resolver este problema e isso é muito frustrante. Eu li que agora você pode obter dependências sem baixar do pypy. Isso é uma solução alternativa para esse problema? Não vejo nenhuma conversa sobre essa opção aqui. No momento, a ferramenta está inutilizável para meus 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

Como esta não é a principal prioridade para este projeto? Pipenv é tão lento que é praticamente inutilizável. E não só em alguns casos de uso incomum, é sempre muito lento.

Sem saber muito sobre o que está acontecendo nos bastidores, pensei que isso poderia ser resolvido muito bem com um cache local do gráfico de dependência.

Pense nisso: se armazenarmos em cache aquele pacote x-1.2.3 depende de y>=3.4 , podemos fazer localmente muito do trabalho que está sendo feito atualmente para baixar pacotes um por vez, expandi-los e verificar as dependências . A fase lock seria tão simples como:

• Compare o Pipfile com o cache e verifique se temos tudo o que precisamos.
• Se não, baixe qualquer coisa nova e calcule as dependências lá
  
  
  
  • Armazenar as alterações em cache
  
  
• Instalar.

Em todos os casos, embora a primeira vez possa ser lenta, os bloqueios subsequentes seriam indolores, não?

Decidi usar pipenv em vez de pip para um pequeno projeto. A primeira coisa que fiz foi pipenv install -r requirements.txt . Ele está bloqueando as dependências há cerca de 10 minutos. Portanto, vou voltar ao pip.

Pessoal, esse problema está custando muitos usuários. Proponho abordá-lo rapidamente.

No meu caso, instalar as dependências no servidor trava o servidor por horas. Estou usando a instância AWS EC2 t2.micro com 1 GB de RAM. Essa quantidade de RAM é suficiente para um único aplicativo com poucas dependências, mas a instalação ocupa toda a memória e só há uma maneira de fazê-la funcionar reiniciando o servidor.

Este problema está pendente há muitos anos e nenhuma correção foi feita para isso. Vejo vários problemas sendo fechados sem qualquer resolução.

Uma ferramenta tão boa sendo negligenciada. Vou cancelar a assinatura desse problema, pois vejo que ele nunca será resolvido. Estará aderindo a algo como o conda ou o fará manualmente usando o virtualenv.

Acho que vou tentar https://github.com/sdispater/poetry : |

Um administrador pode, por favor, fechar este tópico para comentários? Parece que nenhum conteúdo adicional útil está sendo adicionado à discussão.

Eu ficaria feliz em assinar um tíquete rastreando o trabalho de correção do problema.

Obrigado!

Suspeito que 99% das pessoas que usam essa ferramenta e se queixam desse tópico são programadores. Em vez de reclamar, coloque seu tempo onde está e envie um PR.

Olá @idvorkin ,

Eu tentei uma vez .
Demorou semanas para conseguir a fusão da correção trivial .
Basta comparar a quantidade de discussões com o tamanho real da correção.

Eu definitivamente não quero enviar mais nenhuma correção para este projeto.

Portanto, seu conselho não é tão viável quanto você pode supor.

@Jamim em nome de muitos usuários (e eu suspeito que os administradores também), obrigado por suas contribuições. Eu li seu PR e pude sentir empatia com a frustração. No entanto, tenho que concordar com @techalchemy sobre este:

É claro que nos preocupamos com a biblioteca que mantemos, mas eu sugeriria que o fraseado provavelmente não é a maneira mais eficaz de ter uma interação positiva.

Eu nunca conheci os administradores, mas se eles forem como eu (e talvez você), eles são humanos com vidas ocupadas, cujas vidas estão repletas de compromissos antes mesmo de terem energia para gastar neste projeto.

Da mesma forma, aposto que se você (ou qualquer outra pessoa) consertasse o problema de desempenho, haveria inúmeras pessoas que o ajudariam a desenvolver, testar, mesclar ou, se necessário (e duvido muito que seja), criar um fork .

Agradeço o tempo que os desenvolvedores deste projeto estão gastando nisso, mas sugiro que deve ser avisado em negrito que este projeto ainda não está pronto para produção logo acima dos depoimentos dos usuários em README.md , atualmente é enganar as pessoas a gastar um tempo precioso para substituir sua pilha pip / virtualenv atual por pipenv até que descubram esse bloqueio lento e entendam que não podem usá-lo.

até descobrirem sobre esse bloqueio lento e entenderem que não podem usá-lo.

Embora eu fique muito feliz em obter uma velocidade, já que é realmente muito lento, não há necessidade de tal hipérbole.

Estou usando pipenv muito bem todos os dias. As melhorias de fluxo de trabalho que ele fornece superam em muito a lentidão ocasional. Travar não é algo que faço o tempo todo, ao contrário de executar scripts, por exemplo.

Com que frequência você bloqueia que realmente se torna um problema que sente que não pode usá-lo? :boca aberta:

@bochecha minha declaração pode ser uma hipérbole na sua opinião, mas é um fato baseado na minha experiência, ouvi falar sobre pipenv de alguns colegas de trabalho, hoje tentei atualizar um projeto antigo, atualizando suas dependências, etc. Pensei: vamos atualizar de pip / virtualenv para pipenv como parte do processo de atualização. Tive que atualizar uma dependência, verificar como as coisas funcionam com ela, atualizar partes do código se necessário e, em seguida, atualizar outra dependência, cada vez que executei pipenv install <something> tive que esperar um tempo ridiculamente longo, primeiro pensei que estava calculando algo e ele vai armazená-lo em cache para o futuro, pois eu não conseguia acreditar que é um problema em um alegado gerenciador de pacotes pronto para produção. Depois de instalar o ~ 10º pacote, comecei a pesquisar sobre ele e encontrei este tópico, removi Pipfile e Pipfile.lock e voltei ao meu fluxo de trabalho pip / virtualenv. Fiquei tentado a tentar poesia, mas não podia arriscar mais uma hora.

Isso acontece na comunidade JS, por exemplo, mas não espero que seja na comunidade Python, não temos esse tipo de problema em nossa comunidade e devemos tentar evitá-lo, uma isenção de responsabilidade em README.md pode evitar este inconveniente então eu sugeri em meu comentário. Isso poderia economizar meu tempo hoje e eu acho que vai economizar tempo para outros novatos e eles não terão uma experiência ruim com este projeto, então eles podem permanecer como potenciais futuros usuários.

Eu meio que concordo com o sassanh. Nem todos são igualmente afetados pelo problema, mas alguns de nós foram bastante afetados. Fiz projetos de código aberto que não estavam totalmente funcionais ou prontos para produção e, quando foi o caso, coloquei uma isenção de responsabilidade para não perder o tempo das pessoas se elas não estiverem prontas para os solavancos.

Não estou bravo com as pessoas que trabalham neste projeto, mas estou um pouco bravo com a pessoa que fez um discurso público sobre ele, vendendo-o como uma ótima ferramenta com 0 disclaimer. Como resultado, perdi muito do meu precioso tempo tentando fazer uma ferramenta funcionar, na esperança de economizar tempo no longo prazo, mas acabei tendo que voltar ao pip e ao meu próprio script, porque o pipenv não funcionou no meu ambiente com restrições de tempo e largura de banda.

cada vez que executei pipenv install

Você sabia que pipenv install -r requirements.txt deve ser bloqueado / instalado apenas uma vez em seu projeto existente ao tentar movê-lo para o pipenv? Se não o fizer, o problema pode ser de documentação?

Antes de qualquer coisa, tenho certeza de que o pipenv será um bom substituto para o fluxo de trabalho pip / virtualenv, acho que todos sabemos que precisamos dele e acho que no dia em que o pipenv estiver pronto para a produção, será uma grande ajuda para muitas pessoas / projetos.

@bochecha como expliquei, tive que instalar uma versão mais recente de um pacote, fazer algumas coisas e então ir com o próximo pacote, talvez se eu fizesse esse processo com pip e migrasse para pipenv eu não notaria o problema de forma alguma, mas primeiro migrei para o pipenv e depois fiz as atualizações do pacote uma por uma e foi realmente irritante. Fico feliz que funcione para o seu caso de uso, mas tenho certeza de que não funciona para muitas pessoas como eu (dê uma olhada nos comentários acima). Deve ser mencionado no README.md , pelo menos deve ser mencionado que "cada bloqueio pode levar muito tempo, então se o seu caso de uso inclui a instalação / remoção de muitos pacotes rapidamente, você deve evitar o uso do pipenv até que esse problema seja resolvido "(novamente em negrito, e além dos depoimentos) se você anunciar os problemas antes que alguém seja afetado por eles, todos ficarão gratos, se os problemas afetarem os outros e você não os avisou, todos ficarão bravos.

Acordado. Comecei a pesquisar poesia e até mesmo adicionar outro usuário ao meu sistema operacional por projeto em vez de usar o pipenv novamente. Se ele não está funcionando bem para casos de uso casuais com as configurações padrão é quebrado imho.
É uma ferramenta super útil! Existe apenas uma coisa que o torna super inútil para mim. E infelizmente tenho pouco tempo para contribuir: |

Claro, é irritante esperar por um bloqueio ao ter que fazer várias instalações no meio da sessão de desenvolvimento, mas isso pode ser gerenciado.

O importante é que um arquivo de bloqueio seja gerado antes de enviar as alterações locais para o repo. Eu faço uso criterioso do sinalizador —skip-lock durante as sessões de desenvolvimento, e pipenv lock uma vez no final, antes de me comprometer.

Obrigado pelo projeto. Mas,
O bloqueio é verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrry lentowwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
Este env torna o bloqueio mais rápido, se ele já tiver um cache de pacote pip instalado.

Olá @yssource e todos,

Obrigado pelo projeto. Mas,
O bloqueio é verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrry lentowwwwwwwwwwwwwwwwwwwwwwwwwwww.

Este projeto parece estar morto, então se você quiser eliminar o problema de velocidade, considere migrar para Poesia, que é significativamente mais rápido.

@Jamim , obrigado por sugerir Poesia. Pessoalmente, por algum motivo, não o encontrei. Depois de ler o readme, parece que vale a pena tentar. Ele lista alguns benefícios sobre o Pipenv também (https://github.com/sdispater/poetry/#what-about-pipenv).

Dito isso, o fato de o projeto estar morto é um exagero grosseiro e, se eu estivesse no lugar de um grande autor, o acharia desrespeitoso. O autor respondeu na seção de questões ontem. É apenas esse problema de bloqueio sendo esquecido, provavelmente porque é difícil de corrigir.

Para que conste, Poesia também sofre de problemas de desempenho:
https://github.com/sdispater/poetry/issues/338

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

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

Eu ouvi muito sobre pipenv e tentei hoje,
o bloqueio também é muito lento para mim. Já se passaram cerca de 2 minutos, ainda travado no travamento.
O download é muito rápido, mas o problema está no bloqueio.
Este problema foi resolvido?
Estou usando o Pop os 19.10, pipenv, versão 11.9.0 do apt, python 3.7.5.

Quero chamar a atenção para este excelente comentário de # 1914 no mesmo tópico https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 que sugere que o download e a execução de cada dependência não são mais necessários.

Eu me pergunto se algum desenvolvedor poderia comentar sobre a viabilidade dessa abordagem.

Percebi que, na verdade, é mais rápido remover o ambiente e recriá-lo do zero para atualizar o arquivo de bloqueio.
Isso é verdade tanto para executar pipenv lock quanto pipenv install some-package

Eu realmente gosto de pipenv mas não tanto quanto gosto de minha largura de banda e tempo. Então, acabo resolvendo o 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

Deseje boa sorte aos desenvolvedores ...

@ravexina obrigada pela sugestão, vou tentar com certeza