<p>a instalação do pipenv é muito lenta</p>

Ei novamente @Diggsey , isso se deve à maneira como estamos escrevendo as mudanças agora. Eu tenho essas mudanças prontas para mesclar, mas elas estão falhando para a API projects.py então vamos adiar até o próximo grande lançamento. Espero que tenhamos isso pronto e pronto nas próximas semanas. Vou deixar isso em aberto para rastrear o problema por enquanto.

Corremos nisso juntos no PyCon. Será mais rápido em breve.

Agora para mim não está lento, está congelando...

Um pipenv install my_package ou um simples pipenv install não me dá nenhuma saída, após 20 minutos.

EDIT: Confirmação, ainda nada depois de algumas horas. É o mesmo problema? Geralmente era lento, mas terminava depois de 5 a 10 minutos.

Ei @NicolasWebDev , qual versão do pipenv você está usando? Além disso, você tem delegator.py instalado em seu sistema separadamente? Se sim, em que versão está? Este era um problema que deveria ter sido resolvido na v3.6.0.

Se tudo acima estiver atualizado, você poderia fornecer o conteúdo do seu Pipfile? Obrigado!

Oi @nateprewitt , você estava certo, eu estava na v3.5.x. A atualização para 4.1.1 resolveu o problema de congelamento. Agora ainda está levando 5 minutos, mas pelo menos é utilizável!

Desculpe o barulho, sempre esqueço que os pacotes instalados pelo pip não são atualizados automaticamente.
Obrigado!

Que bom que você resolveu as coisas @NicolasWebDev! Estamos trabalhando para acelerar ainda mais, esperamos que o #373 seja um passo mais próximo no próximo lançamento.

@Diggsey @NicolasWebDev , acabei de lançar o 4.1.2 que deve ter essas melhorias de velocidade adicionadas. Ainda há algum trabalho a fazer aqui, mas isso pelo menos agilizará o tempo inicial de inicialização do pipenv.

@nateprewitt Obrigado pela atualização, pipenv parece mais rápido para mim agora, mas ainda leva vários minutos apenas para executar pipenv lock , mesmo quando nada mudou - ele ainda espera em Locking [packages] dependencies... pelo vasto maior parte desse tempo.

@Diggsey , muito desse tempo é porque você está baixando um grande número de arquivos nesse Pipfile. Parece que você está fixando todas as suas dependências também. Você está importando diretamente tudo isso para o seu projeto ou alguns requisitos de dependência dos outros?

@nateprewitt Poderíamos remover alguns deles, mas a maioria são dependências diretas - por que ele precisa baixar todas as dependências toda vez que gera o arquivo de bloqueio?

Precisamos determinar tudo o que ele instala como dependências. Para conseguir isso, baixamos cada pacote e determinamos como é a instalação no momento do bloqueio. Isso nos permite fixar adequadamente tudo no Pipfile.lock. Sem download, não há uma maneira confiável de verificar subdependências e resolver declarações de dependência de intervalo.

Dado que a maioria dos pacotes permanecerá a mesma ao longo do tempo, seria possível armazenar em cache os pacotes baixados?

@Diggsey quer investigar isso para nós?

Esta pode ser uma pergunta boba, mas o Pip já não faz cache de pacotes ?

Tenho a impressão de que sim.

O pipenv pode usar o sistema pip cache ou deve ser implementado do zero?

O Pipenv apenas executa o pip, então o cache deve ser usado automaticamente.

fixo! bloqueio é perverso rápido agora.

Obrigado. Acho que foi a única coisa que me impediu de empurrar todo mundo para o pipenv no trabalho.

Uau, legal, isso foi literalmente mais do que uma aceleração de 100x para mim, e também pegou um conflito de dependência que a versão anterior não pegou!

O que seria útil é um sinalizador verbose para pipenv lock - só consegui diagnosticar o conflito de dependência editando piptools/logging.py para habilitar o log detalhado, mas depois que fiz isso, deu uma indicação muito clara do que estava acontecendo.

Provavelmente está faltando alguma coisa :) Onde foi corrigido? A versão mais recente é de 4 dias atrás, então instalei a versão mais recente de master . No entanto, pipenv install ainda é lento.

Eu tentei:

• instale pipenv da maneira mais chique ⚡️ 🍰 ⚡️
• use a versão mais recente publicada de pipenv e a versão mais recente de master
• instalar pacote único

Usando a versão estável mais recente (5.3.5.), leva 3:40 para instalar um pacote:

∙ time pipenv install --dev raven
Installing raven...
Collecting raven
  Using cached raven-6.1.0-py2.py3-none-any.whl
Collecting contextlib2 (from raven)
  Using cached contextlib2-0.5.5-py2.py3-none-any.whl
Installing collected packages: contextlib2, raven
Successfully installed contextlib2-0.5.5 raven-6.1.0

Adding raven to Pipfile's [dev-packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install --dev raven  10,11s user 2,77s system 5% cpu 3:40,04 total

Usando a versão de master , ainda trava (um pacote, +10 minutos)

EDIT: Acabou de terminar:

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

Alguma ideia? Muito obrigado!

Às vezes, as dependências demoram um pouco para serem instaladas, especialmente se tiverem compilações c. Quer compartilhar seu Pipfile ?

Eu entendo que às vezes demora um pouco, mas foi lento desde o início. Apenas curioso se é um problema do meu lado.

Aqui está o meu Pipfile:

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

[dev-packages]
pytest = "*"
pytest-django = "*"
pytest-testmon = "*"
pytest-watch = "*"
django-debug-toolbar = "*"
raven = "*"

[packages]
dj-database-url = "*"
Django = "*"
djangorestframework = "*"
gunicorn = "*"
newrelic = "*"
psycopg2 = "*"
requests = "*"
whitenoise = "*"
graphene-django = "*"

psycopg2 pode estar demorando um pouco, pois pode estar compilando a partir da fonte. Todo o resto deve ser bom e rápido. Tente removê-lo e veja o quanto sua velocidade aumenta.

$ pipenv install raven levou apenas 1s para mim.

$ pipenv install raven levou apenas 1s para mim.

Isso é o que eu esperaria! Posso ativar a saída detalhada de alguma forma?

Eu tentei remover psycopg2 , mas isso não afeta muito. Executando pipenv install raven trava por um tempo.

Eu tenho:

• Python 3.6.2
• macOS 10.12.6

não vejo razão para que o raven não seja instantâneo.

faça $ pip install raven dentro de $ pipenv shell e me diga se está lento lá também.

Tudo o que o pipenv está fazendo é executar o pip, então esse é efetivamente o "modo detalhado"

Isso é instantâneo:

∙ time pip install raven                                                                                                                                 19:38  tricoder<strong i="6">@issac</strong>
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)
noglob pip install raven  0,54s user 0,15s system 76% cpu 0,900 total

Correr pipenv trava cerca de 2-3 minutos (dentro/fora de pipenv shell ).

∙ time pipenv install raven                                                                                                                              19:39  tricoder<strong i="12">@issac</strong>
Installing raven...
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)

Adding raven to Pipfile's [packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install raven  4,49s user 0,46s system 2% cpu 3:21,17 total

@Diggsey você pode abrir uma nova edição sobre --verbose e fornecer um exemplo de como você gostaria que fosse?

@tricoder42 a parte lenta é a etapa de travamento ou a etapa de instalação? O bloqueio foi amplamente aprimorado nas versões mais recentes.

```concha
$ time pipenv instalar raven
Instalando o corvo...
Coleta de corvo
Usando raven-6.1.0-py2.py3-none-any.whl em cache
Requisito já satisfeito: contextlib2 em /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (de raven)
Instalando pacotes coletados: raven
Raven-6.1.0 instalado com sucesso

Adicionando corvo aos [pacotes] do Pipfile...
Bloqueando dependências [dev-packages]...
Bloqueando dependências de [pacotes]...
Pipfile.lock atualizado!
9,30 reais 5,49 usuários 0,42 sys

É como 50:50 installing:locking

@tricoder42 e você está usando o mais recente?

Deixe-me replicar com seu pipfile exato.

Eu acho:

∙ pipenv --version                                                                                                                                       19:42  tricoder<strong i="6">@issac</strong>
pipenv, version 5.3.5

∙ pipsi upgrade git+https://github.com/kennethreitz/pipenv.git#egg=pipenv                                                                                19:45  tricoder<strong i="9">@issac</strong>
Collecting pipenv from git+https://github.com/kennethreitz/pipenv.git#egg=pipenv
  Cloning https://github.com/kennethreitz/pipenv.git to /private/var/folders/g9/1wbckv154mbby3tm411z_m340000gn/T/pip-build-se4ao5/pipenv
...
Installing collected packages: pipenv
  Found existing installation: pipenv 5.3.5
    Uninstalling pipenv-5.3.5:
      Successfully uninstalled pipenv-5.3.5
  Running setup.py install for pipenv ... done
Successfully installed pipenv-5.3.5

```concha
$ time instalação do pipenv
Nenhum pacote fornecido, instalando todas as dependências.
Pipfile encontrado em /Users/kennethreitz/pipenv/testapp/Pipfile. Considerando que esta seja a casa do projeto.
Pipfile.lock não encontrado, criando...
Bloqueando dependências [dev-packages]...
Bloqueando dependências de [pacotes]...
Pipfile.lock atualizado!
Instalando dependências do Pipfile.lock...
[================================] 22/22 - 00:00:37
58,94 reais 40,51 usuários 8,62 sistemas

Isso acontece mesmo quando estou instalando o primeiro pacote em um novo pipenv. Vou tentar criar pipenv --three vez de pipenv --python python3.6

@tricoder42 quer

Ou podemos usar o compartilhamento de tela da Apple se você usar o Messages.app.

Me adicione! Eu sou [email protected].

Estou prestes a entrar em uma reunião, mas estarei disponível depois disso.

Legal! Vou tentar limpar e reinstalar tudo do zero e vamos ver. estou disponível em uma hora

Incrível - vamos descobrir isso então. Me adicione no messages.app :)

Se alguém estiver experimentando um comportamento extremamente lento de Locking com v11.9.0 , descobri que o downgrade para v9.0.0 leva uma instalação de 5m30s para 1m36s.

@ryantuck Eu recomendo se você for fixar uma versão antiga para fixar 9.0.3 mas perder uma quantidade significativa de segurança adicional para a velocidade, você também pode usar --skip-lock em esse ponto

--skip-lock definitivamente acelerou as coisas. Eu segui esse caminho porque pipenv install --system --python=3.6 não estava realmente instalando no python correto do sistema, e eu achava que precisava gerar o Pipfile.lock antes de tentar a instalação do sistema. Ainda não funcionou, então voltei a usar pip normal, mas comentarei novamente neste tópico se eu fizer algum progresso nesse sentido.

—system e —python são mutuamente exclusivos - a última opção sempre precisa de um virtualenv

sim, o bloqueio demora um pouco para mim também. v11.10.0. Ubuntu no WSL.

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

[packages]
babel = "==2.5.3"
"boto3" = "==1.7.3"
colorama = "==0.3.9"
coreapi = "==2.3.3"
dj-database-url = "==0.5.0"
djangorestframework = "==3.7.7"
django-axes = "==4.0.2"
django-clever-selects = "==0.8.2"
django-crispy-forms = "==1.7.2"
django-choices = "==1.6.0"
django-extra-views = "==0.10.0"
django-filter = "==1.1.0"
django-hijack = "==2.1.7"
django-hijack-admin = "==2.1.7"
django-js-reverse = "==0.8.1"
django-model-utils = "==3.1.1"
django-phonenumber-field = "==2.0.0"
django-polymorphic = "==2.0.2"
django-redis-cache = "==1.7.1"
django-role-permissions = "==2.2.0"
"django-s3direct" = "==1.0.4"
django-static-precompiler = {extras = ["libsass"], version = "==1.8.2"}
django-storages = "==1.6.6"
"django-tables2" = "==1.21.2"
django-webpack-loader = "==0.6.0"
django-widget-tweaks = "==1.4.2"
facebookads = "==2.11.4"
googleads = "==11.0.1"
markdown = "==2.6.11"
phonenumbers = "==8.9.3"
pillow = "==5.1.0"
"psycopg2-binary" = "==2.7.4"
pygments = "==2.2.0"
pyssim = "==0.4"
python-dotenv = "==0.8.2"
pytz = "==2018.4"
raven = "==6.6.0"
sendgrid-django = "==4.2.0"
slacker = "==0.9.65"
termcolor = "==1.1.0"
tqdm = "==4.21.0"
twitter-ads = "==3.0.0"
brotlipy = "==0.7.0"
waitress = "==1.1.0"
whitenoise = "==3.3.1"
Django = "==2.0.4"

[dev-packages]
coverage = "==4.5.1"
selenium = "==3.11.0"
tblib = "==1.3.2"
"flake8" = "==3.5.0"
django-debug-toolbar = "==1.9.1"
django-extensions = "==2.0.6"

[requires]
python_version = "3.6"

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

real    8m1.993s
user    5m32.406s
sys     7m15.203s

Deve ser um pouco mais rápido na segunda ou terceira vez por causa do
cache mesmo. Você vê uma melhora?
Em qui, 12 de abril de 2018 às 10h23 Alexander Kavanaugh <
[email protected]> escreveu:

sim, o bloqueio demora um pouco para mim também. v11.10.0. Ubuntu no WSL.

[[fonte]]url = " https://pypi.python.org/simple "verify_ssl = truename = "pypi"
[packages]babel = "==2.5.3""boto3" = "==1.7.3"colorama = "==0.3.9"coreapi = "==2.3.3"dj-database-url = "== 0.5.0"djangorestframework = "==3.7.7"django-axes = "==4.0.2"django-clever-selects = "==0.8.2"django-crispy-forms = "==1.7.2" django-choices = "==1.6.0"django-extra-views = "==0.10.0"django-filter = "==1.1.0"django-hijack = "==2.1.7"django-hijack- admin = "==2.1.7"django-js-reverse = "==0.8.1"django-model-utils = "==3.1.1"django-phonenumber-field = "==2.0.0"django- polymorphic = "==2.0.2"django-redis-cache = "==1.7.1"django-role-permissions = "==2.2.0""django-s3direct" = "==1.0.4"django- static-precompiler = {extras = ["libsass"], version = "==1.8.2"}django-storages = "==1.6.6""django-tables2" = "==1.21.2"django-webpack -loader = "==0.6.0"django-widget-tweaks = "==1.4.2"facebookads = "==2.11.4"googleads = "==11.0.1"markdown = "==2.6.11" phonenumbers = "==8.9.3"travesseiro = "==5.1.0""psycopg2-binary" = "==2.7.4"pygments = "==2.2.0"pyssim = "==0.4"python-dotenv = "==0.8.2"pytz = "==2018.4"corvo = "==6.6.0"sendgrid-django = "==4.2.0"slacker = "==0.9.65"termcolor = "==1.1.0"tqdm = "==4.21.0"twitter-ads = "==3.0.0"brotlipy = "==0.7.0"garçonete = "==1.1.0"whitenoise = "==3.3.1"Django = "==2.0.4"
[dev-packages]coverage = "==4.5.1"selenium = "==3.11.0"tblib = "==1.3.2""flake8" = "==3.5.0"django-debug-toolbar = " ==1.9.1"django-extensions = "==2.0.6"
[requer]python_version = "3.6"

Pipfile.lock não encontrado, criando…
Bloqueando dependências [dev-packages]…
Bloqueando dependências de [pacotes]…
Pipfile.lock atualizado (7a535c)!
Instalando dependências do Pipfile.lock (7a535c)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

8m1.993s reais
usuário 5m32.406s
sistema 7m15.203s

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pipenv/issues/356#issuecomment-380882203 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

Eu já tinha instalado os pacotes antes disso; Acabei de remover o arquivo de bloqueio e executei a instalação novamente. Eu vou fazer isso de novo para obter outro ponto de dados

@jtratner Uau. Super interessante... o que faz com que o cache seja ativado somente após a terceira vez?

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
An error occurred while installing coreapi==2.3.3! Will try again.
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:58
Installing initially–failed dependencies…
Success installing coreapi==2.3.3!▉▉▉ 0/1 — 00:00:00
  ☤  ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 1/1 — 00:00:01

real    2m50.218s
user    2m19.438s
sys     5m44.797s

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:55

real    2m32.042s
user    2m6.516s
sys     5m10.219s

@kavdev @jtratner introduziu um recurso para armazenar em cache os hashes também, o que deve fazer uma melhoria considerável

Aqui estou... 15 minutos depois

@giantas não é útil. Forneça pipfile, saída e duração com a instalação do pip. Também se você pode fazer pacotes individuais.

Demora muito para rodar na minha máquina. macOS 10.13.4, pipenv, versão 11.10.0

O download é executado quase imediatamente, mas fica travado em Locking [packages] dependencies… . Aqui está levando meio minuto para duas dependências e depois 6 minutos para outras 3 dependências, se eu lançar todas as dependências do meu projeto, ele trava indefinidamente na etapa de bloqueio

pablo<strong i="8">@batman</strong> scanr (develop) $ time pipenv install flask flask_pymongo
Installing flask…
Looking in indexes: https://pypi.python.org/simple
Collecting flask
  Using cached https://files.pythonhosted.org/packages/77/32/e3597cb19ffffe724ad4bf0beca4153419918e7fa4ba6a34b04ee4da3371/Flask-0.12.2-py2.py3-none-any.whl
Collecting Werkzeug>=0.7 (from flask)
  Using cached https://files.pythonhosted.org/packages/20/c4/12e3e56473e52375aa29c4764e70d1b8f3efa6682bef8d0aae04fe335243/Werkzeug-0.14.1-py2.py3-none-any.whl
Collecting itsdangerous>=0.21 (from flask)
Collecting Jinja2>=2.4 (from flask)
  Using cached https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl
Collecting click>=2.0 (from flask)
  Using cached https://files.pythonhosted.org/packages/34/c1/8806f99713ddb993c5366c362b2f908f18269f8d792aff1abfd700775a77/click-6.7-py2.py3-none-any.whl
Collecting MarkupSafe>=0.23 (from Jinja2>=2.4->flask)
Installing collected packages: Werkzeug, itsdangerous, MarkupSafe, Jinja2, click, flask
Successfully installed Jinja2-2.10 MarkupSafe-1.0 Werkzeug-0.14.1 click-6.7 flask-0.12.2 itsdangerous-0.24

Adding flask to Pipfile's [packages]…
Installing flask_pymongo…
Looking in indexes: https://pypi.python.org/simple
Collecting flask_pymongo
  Using cached https://files.pythonhosted.org/packages/fa/71/ab920741dedd605ef4adbd57d0c7d9f43a6b6fe4068604fffbc6f64b2c9c/Flask_PyMongo-0.5.1-py3-none-any.whl
Requirement already satisfied: Flask>=0.8 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from flask_pymongo) (0.12.2)
Collecting PyMongo>=2.5 (from flask_pymongo)
  Using cached https://files.pythonhosted.org/packages/5c/7f/1f7240883ec3fa768d7e066c9cbd42ceb42d699ba1a0fb9d231c098a542d/pymongo-3.6.1-cp36-cp36m-macosx_10_6_intel.whl
Requirement already satisfied: click>=2.0 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (6.7)
Requirement already satisfied: itsdangerous>=0.21 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.24)
Requirement already satisfied: Werkzeug>=0.7 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.14.1)
Requirement already satisfied: Jinja2>=2.4 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (2.10)
Requirement already satisfied: MarkupSafe>=0.23 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Jinja2>=2.4->Flask>=0.8->flask_pymongo) (1.0)
Installing collected packages: PyMongo, flask-pymongo
Successfully installed PyMongo-3.6.1 flask-pymongo-0.5.1

Adding flask_pymongo to Pipfile's [packages]…
Pipfile.lock (c202d3) out of date, updating to (3068be)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (3068be)!
Installing dependencies from Pipfile.lock (3068be)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 32/32 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    0m37.816s
user    0m34.556s
sys 0m4.517s

pablo<strong i="5">@batman</strong> scanr (develop) $ time pipenv install gunicorn h5py joblib
Installing gunicorn…
Looking in indexes: https://pypi.python.org/simple
Collecting gunicorn
  Using cached https://files.pythonhosted.org/packages/64/32/becbd4089a4c06f0f9f538a76e9fe0b19a08f010bcb47dcdbfbc640cdf7d/gunicorn-19.7.1-py2.py3-none-any.whl
Installing collected packages: gunicorn
Successfully installed gunicorn-19.7.1

Adding gunicorn to Pipfile's [packages]…
Installing h5py…
Looking in indexes: https://pypi.python.org/simple
Collecting h5py
  Using cached https://files.pythonhosted.org/packages/69/d5/dff2a8f7658fd87ab3330a0ab47e4363681d8bdf734a495add65a347f5e3/h5py-2.7.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Requirement already satisfied: six in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from h5py) (1.11.0)
Collecting numpy>=1.7 (from h5py)
  Using cached https://files.pythonhosted.org/packages/a0/df/fa637677800e6702a57ef09e1d62e42aec3f598fb235f897155d146f2f59/numpy-1.14.2-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy, h5py
Successfully installed h5py-2.7.1 numpy-1.14.2

Adding h5py to Pipfile's [packages]…
Installing joblib…
Looking in indexes: https://pypi.python.org/simple
Collecting joblib
  Using cached https://files.pythonhosted.org/packages/4f/51/870b2ec270fc29c5d89f85353da420606a9cb39fba4747127e7c7d7eb25d/joblib-0.11-py2.py3-none-any.whl
Installing collected packages: joblib
Successfully installed joblib-0.11

Adding joblib to Pipfile's [packages]…
Pipfile.lock (0d514f) out of date, updating to (a4d15f)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (a4d15f)!
Installing dependencies from Pipfile.lock (a4d15f)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 36/36 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    6m31.572s
user    1m1.986s
sys 0m11.047s

@pablote puta merda que é lento! Observe que isso se deve em parte à instalação do numpy, que tenho certeza de que provavelmente estamos compilando da fonte para o bloqueio ou algo estúpido. ajudaria se fornecermos uma saída útil aqui

Existe algo que eu possa fazer sobre isso? ou estou apenas sem sorte em usar pipenv e ter esses tempos de arquivo de bloqueio lentos? Acho que poderia --skip-lock, mas eu meio que queria esse recurso

@pablote você pode verificar se você reexecutou a mesma operação de bloqueio, ainda está lento?

Se eu executar novamente, ele terminará quase imediatamente, então acho que é apenas a primeira vez que uma nova dependência é adicionada.

então, na verdade, está armazenando os hashes localmente, por qualquer motivo, é o processo de geração de hash que é incrivelmente lento aqui ...

Deixe-me saber se há alguma informação que eu possa fornecer para ajudar a diagnosticar. No momento, vou voltar para pip + virtualenv + pip-tools :/

@pablote uma vez que você tenha os hashes uma vez, bloquear novamente não será tão lento

Por favor, forneça uma saída útil. Acabei de atualizar meu pipenv de 9.1.0 para 11.10.0 para resolver a falha do Invalid Marker na etapa de bloqueio do pacote conforme, por exemplo, #1622 --- agora, tenho um pipfile com ipykernel, pandas, jupyter, numpy, e matplotlib lá e com minha última tentativa de usar pipenv install para ativar o arquivo de bloqueio, estou sentado em locking [packages] dependencies… por mais de 10 minutos.

Como não há saída, não posso dizer se há algo realmente acontecendo (como construir numpy a partir da fonte) ou se está apenas travando. O melhor que posso fazer é olhar de soslaio para top e concluir que talvez esteja fazendo algo porque um processo python parece estar por aí ... algo não se move em breve.

Fico feliz em contribuir com algum trabalho sobre isso, se necessário.

Por favor, forneça uma saída útil. Acabei de atualizar meu pipenv de 9.1.0 para 11.10.0 para resolver a falha do Invalid Marker na etapa de bloqueio do pacote conforme, por exemplo, #1622 --- agora, tenho um pipfile com ipykernel, pandas, jupyter, numpy, e matplotlib lá e com minha última tentativa de usar pipenv install para fazer o arquivo de bloqueio funcionar, eu estive sentado em dependências de bloqueio de [pacotes]… por mais de 10 minutos.

Reclamação totalmente compreensível e fiquei pensando em como podemos fornecer feedback mais útil ao usuário (porque concordo que é um pouco confuso que não tenha nenhuma saída). Eu desistiria depois de 15 minutos. Como @techalchemy apontou, cada vez que seu cache deve ser preenchido um pouco mais, ele deve ficar consistentemente mais rápido ao longo do tempo.

Uma pergunta: você está usando o PyPI público?

@jtratner sim, usando PyPi público --- e acabei desistindo, destruindo o virtualenv e construindo um novo; Consegui criar um arquivo de bloqueio instalando minhas dependências uma de cada vez. (Curiosamente, matplotlib foi o mais lento --- ainda pior que numpy!)

Talvez uma mensagem como This may take a long time ajude a tranquilizar as pessoas até que uma solução mais clara seja decidida.

15 minutos ainda é insanamente longo, duvido que sentaria e esperaria por isso. @paultopia você pode executar pipenv lock —verbose para mais saída

Ele tem a sensação geral de ser mais lento do que deveria, mas talvez eu esteja subestimando o problema. Se eu olhar para os processos em execução no meu computador, posso ver o python em execução o tempo todo em que o pipenv está em execução e nunca ultrapassa ~ 15%, provavelmente deve usar mais se estiver fazendo um trabalho intensivo de CPU, como arquivos de hash . Além disso, usei outros gerenciadores de pacotes que usam dependências de hash, como yarn, e eles são bem rápidos.

Precisamos descobrir o que está fazendo...

Eu criei um projeto github mostrando lentidão ao usar o bloqueio. Por favor, dê uma olhada em https://github.com/AndreasPresthammer/slow-pipenv . Não tenho 100% de certeza de que seja o mesmo problema. Puxe o repositório para baixo e execute o script slow.sh e observe a diferença no tempo de execução.

@AndreasPresthammer para que seu script esteja apenas cronometrando um bloqueio sem cache em vez de instalar com bloqueio. Sabemos que é o travamento, mas isso é lento. No caso do numpy, provavelmente é porque ele teve que usar sdists para resolução no passado, o que significava compilação. Podemos usar rodas agora. Isso pode acelerar as coisas

Isso definitivamente ainda é um problema (mais de 5 minutos), com as versões mais recentes do python3.6, pip e pipenv e instalando um pacote simples como torch . Eu não acho que este problema deve ser marcado como encerrado.

Para quem quiser comentar sobre o encerramento deste problema: forneça a saída de pipenv lock --verbose . Sabemos que a resolução é lenta para pacotes compilados a partir do código-fonte e que levam muito tempo para serem compilados em condições normais. Precisamos de logs para obter informações sobre a causa se isso for mais lento que o normal.

Também estou usando o Docker para meu ambiente de desenvolvimento e produção e acho que a instalação dentro do Docker parece lenta, em comparação com a instalação no host. Talvez seja apenas a combinação de todos os pacotes, mas gostaria de ouvir alguns comentários de pessoas mais experientes do que eu.

Aqui está o log de pipenv lock --verbose , incluindo Pipfile e Pipfile.lock :

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

@mimischi Os resultados da resolução são armazenados em cache no host, mas o Docker não pode acessá-los. É lento porque precisa refazer toda a resolução do zero. Ajudaria se você montasse o diretório de cache do host no Docker. Há um comentário em um problema mencionando o caminho que você deve montar. Eu não tenho tempo para procurá-lo agora, mas você pode tentar encontrá-lo. (E, por favor, contribua para a página de perguntas frequentes do documento quando fizer isso!)

FWIW, travar na minha caixa de desenvolvimento agora leva menos de 30s. Muito melhor do que antes - apreciá-lo.

Olá, to com o mesmo problema.
aqui está o verboso

pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:
  pylint

Finding the best candidates:
  found candidate pylint==1.9.1 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six

New dependencies found in this round:
  adding ['astroid', '<2.0,>=1.6', '[]']
  adding ['isort', '>=4.2.5', '[]']
  adding ['mccabe', '', '[]']
  adding ['six', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  mccabe
  pylint
  six

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  isort==4.3.4              requires -
  mccabe==0.6.1             requires -
  six==1.11.0               requires -

New dependencies found in this round:
  adding ['lazy-object-proxy', '', '[]']
  adding ['wrapt', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  lazy-object-proxy
  mccabe
  pylint
  six
  wrapt

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate lazy-object-proxy==1.3.1 (constraint was <any>)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)
  found candidate wrapt==1.10.11 (constraint was <any>)

Finding secondary dependencies:
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  wrapt==1.10.11            requires -
  lazy-object-proxy==1.3.1  requires -
  six==1.11.0               requires -
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  mccabe==0.6.1             requires -
  isort==4.3.4              requires -
------------------------------------------------------------
Result of round 3: stable, done

Locking [packages] dependencies…

Aqui está o pipenv --version : pipenv, versão 2018.05.18

Também não sei por que isso está acontecendo, nenhum motivo específico / erro está ocorrendo.
No meu caso quando eu faço pipenv lock ele começa mas nunca termina até onde eu sei. Estou esperando há 2 horas e agora ainda não há sinal de conclusão. E me deu ReadTimeoutError duas vezes, é a terceira vez que estou fazendo isso.
Usando Python 3.6.4

Qualquer ajuda seria de grande ajuda, pois a data de vencimento dos meus projetos está mais próxima.

Votem também para que esta questão seja reaberta. Está longe de ser resolvido... demore entre 10 e 20 minutos para bloquear meu projeto em um contêiner do Docker. Ele também usa uma quantidade insana de memória - de modo que eu tive que aumentar a alocação para o Docker para impedir que ele matasse o processo.

Forneça um exemplo de Pipfilesmand detalhes sobre seus ambientes se quiser ajuda com problemas de velocidade de resolução. Estamos cortando um lançamento esta semana e não temos tempo para rastrear comentários individuais em tópicos fechados, mas podemos testar contra Pipfiles se você fornecer um

@jkp Permita-me garantir que todo e qualquer desenvolvedor principal deste projeto (não que haja muitos de nós para começar) está muito ciente desse problema e está tão preocupado com isso quanto você, se não mais. No entanto, isso não é um problema fácil, e já lançamos tudo o que podíamos para torná-lo o mais utilizável possível, sem ter que desmontar tudo no empacotamento do Python. No momento, também temos muito o que fazer e precisamos nos concentrar também nessas outras questões. A decisão inevitável que devo tomar, então, é priorizar questões que realmente sabemos como resolver, e só começar a pensar em nossos próximos passos depois que eles estiverem concluídos, para maximizar o efeito de nosso esforço.

Agora, reconheço plenamente que sua prioridade pode ser diferente da nossa. Esse problema de desempenho pode ser o maior problema em seu fluxo de trabalho e você deseja colocá-lo como a coisa mais importante neste projeto. Tenha em mente, porém, que você não é o único usuário desta ferramenta, e precisamos priorizar a necessidade de todos, até mesmo a nossa própria , à frente da sua. Eu reconheço isso. Exorto, portanto, qualquer pessoa que compartilhe a situação a se unir a essa questão e tentar pensar em uma maneira de resolvê-la. Uma vez que sabemos o que realmente fazer, podemos fazê-lo.

O problema é mantido fechado porque não sabemos o que podemos fazer e serviria apenas como ruído no rastreador de problemas quando tentamos gerenciá-lo. Não faz sentido, pelo menos em nosso fluxo de trabalho, ter um problema no qual ninguém possa trabalhar.

Aprecie seu fluxo de trabalho, portanto, se é assim que você gerencia problemas, tudo bem. Vou tentar adicionar qualquer informação que puder para ajudar a rastrear o problema.

Fiz uma depuração instalando mitmproxy entre pipenv e a rede para rastrear as requisições que estavam sendo feitas. Achei algumas coisas interessantes.

1. Estamos usando um índice pypi privado que ainda não suporta o json-api . Isso diminui significativamente as coisas, pois parece que o fallback é bruteforce e baixar tudo listado no índice http para extrair metadados etc. Uma sugestão aqui seria apenas adicionar algum log simples para avisar que esse método de fallback está sendo usado - pode salvar alguém de ter que cavar mais fundo para descobrir isso.

2. Usando o método de força bruta, parece que o código baixa pacotes que não são relevantes para a arquitetura em uso. Por exemplo, em uma máquina linux, estava baixando pacotes específicos de rodas win32 ou osx . Isso parece algo que pode ser detectado e evitado, já que está claro que os pacotes binários criados para outras arquiteturas não serão úteis.

Continuarei a depurar e relatar qualquer informação útil que encontrar.

Parece que mesmo com a interface json em uso pipenv está fazendo solicitações desnecessárias de arquivos wheel que se relacionam a diferentes arquiteturas. Atualmente, a implementação é bastante ingênua, pois verifica todos os arquivos listados em uma determinada versão, independentemente da plataforma / arco de destino.

Caso de teste mínimo:

Em um host Linux: pipenv install grpcio

Produziu as seguintes solicitações (capturadas usando mitmproxy ):

$ mitmdump -w dump.out
Proxy server listening at http://*:8080
127.0.0.1:62303: clientconnect
127.0.0.1:62303: GET https://pypi.org/simple/setuptools/
              << 200 OK 79.82k
127.0.0.1:62305: clientconnect
127.0.0.1:62305: GET https://files.pythonhosted.org/packages/7f/e1/820d941153923aac1d49d7fc37e17b6e73bfbd2904959fffbad77900cf92/setuptools-39.2.0-py2.py3-none-any.whl
              << 200 OK 554.25k
127.0.0.1:62303: GET https://pypi.org/simple/pip/
              << 200 OK 9.56k
127.0.0.1:62303: GET https://pypi.org/simple/wheel/
              << 200 OK 6.91k
127.0.0.1:62303: clientdisconnect
127.0.0.1:62305: clientdisconnect
127.0.0.1:62307: clientconnect
127.0.0.1:62307: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62309: clientconnect
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62307: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62309: clientdisconnect
127.0.0.1:62307: clientdisconnect
127.0.0.1:62311: clientconnect
127.0.0.1:62311: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62313: clientconnect
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62311: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62315: clientconnect
127.0.0.1:62315: GET https://pypi.org/pypi/six/json
              << 200 OK 5.94k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
              << 200 OK 29.16k
127.0.0.1:62315: GET https://pypi.org/pypi/grpcio/json
              << 200 OK 164.26k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5c/73/5e65b81301956bdd32c5e8da691fde3fbd6e61283b65d2bac590b8f43765/grpcio-1.12.1-cp27-cp27m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/e1/c3/bcce8247da4e6f95a900489b6f7ff3d14d93df40d69875fe4164c1b9544a/grpcio-1.12.1-cp27-cp27mu-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/ed/89/03924c56e9044b0842a014fcc0a81f55975028d1caa9cdd14234a230bc70/grpcio-1.12.1-cp27-cp27m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/d7/f6/ddeab13c25b8451f05875587801ad87e4e0fc23c4e3eb328c4bd1a80a415/grpcio-1.12.1-cp36-cp36m-linux_armv7l.whl
              << 200 OK 7.77m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2d/a4/4d1d73c0339e987ea173f44cf62ec6b40fb91e0336c09c960c4a44137552/grpcio-1.12.1-cp35-cp35m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/76/27/b03ec8fc96745cde68d6ec29115f9a444945a6acc45209c5772378cc4d66/grpcio-1.12.1-cp35-cp35m-macosx_10_7_intel.whl
              << 200 OK 1.83m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/30/24/8e247548321e52c266a639b51a838ec19b41fb6bfd27e3bbef018496752e/grpcio-1.12.1-cp27-cp27m-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/80/c9/e582b962a4a3aa2684666ff67fc994a042b1b0e444eb6672eb9740f7b59a/grpcio-1.12.1-cp34-cp34m-macosx_10_7_intel.whl
              << 200 OK 1.84m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/a2/25/6d910070a4a07c32633c2376075d5dc03e90f69f855d700e3f73c1affebb/grpcio-1.12.1-cp27-cp27m-macosx_10_12_x86_64.whl
              << 200 OK 1.57m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/33/38/58f3e8d133de1f2e911206ead03799621205079c303ae5b27e7350051f4a/grpcio-1.12.1.tar.gz
              << 200 OK 13.56m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/68/57/da122cbfc1b7815381480b23044fff06b90f58c1be9310e68c2d6b1d623c/grpcio-1.12.1-cp36-cp36m-macosx_10_7_intel.whl
              << 200 OK 1.82m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/c6/b8/47468178ba19143e89b2da778eed660b84136c0a877224e79cc3c1c3fd32/grpcio-1.12.1-cp35-cp35m-manylinux1_x86_64.whl
              << 200 OK 8.55m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5d/8b/104918993129d6c919a16826e6adcfa4a106c791da79fb9655c5b22ad9ff/grpcio-1.12.1-cp36-cp36m-win_amd64.whl
              << 200 OK 1.37m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/94/6c/02e9cb803cd7b9608c9c1768d86d31c61b088f5b9513a203c10fa7e905d8/grpcio-1.12.1-cp36-cp36m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2a/ed/71169dccb7f9250d17031068579832371a72891d8e64891265370ca6e264/grpcio-1.12.1-cp27-cp27mu-linux_armv7l.whl
              << 200 OK 7.68m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/63/38/d73bf5b1ef950dbab8203122b9681137b35012492ecfec56719be109e343/grpcio-1.12.1-cp27-cp27m-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/13/71/87628a8edec5bffc86c5443d2cb9a569c3b65c7ff0ad05d5e6ee68042297/grpcio-1.12.1-cp36-cp36m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1d/0d/146582f71161a0074dda2378617ae5f7e2c3d6cf62d4588eb586c1d6b675/grpcio-1.12.1-cp27-cp27mu-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/9e/3a/6aceb4fccacf6d2d7d087190c221a90f14b2bdcb56cbee5af24b7050278b/grpcio-1.12.1-cp34-cp34m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f9/fa/a0187d220544b744dd3bb0d8b8ec716d130159160bf627415b2880ae599a/grpcio-1.12.1-cp34-cp34m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/dd/aa/ac8e3c6badf1744f04be7d35fa95dae56df12b956f861285c8cced2a22cb/grpcio-1.12.1-cp34-cp34m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/38/2a/94665daafbcf0214adcf77ad8f5aed8b9dfcbfa871115c7890d88b1b8f3c/grpcio-1.12.1-cp34-cp34m-manylinux1_x86_64.whl
              << 200 OK 8.58m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/0d/33/22ad4a9dcefe330180cdb2d24fdd980af2a7a2dc03af208a408fd48195e0/grpcio-1.12.1-cp35-cp35m-win_amd64.whl
              << 200 OK 1.36m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/b5/13/9e8e5d68a15c51b251e512955a971214fd8425b237e6d6a04f0257c5d090/grpcio-1.12.1-cp34-cp34m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/21/41/66ab386c65be68b4e907f2cd35223965aea2a086bcd0bd6825999e0bda7c/grpcio-1.12.1-cp35-cp35m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f7/db/fc084f59804a32a8d6efb467896a505f4dc93ea89ec44da856b91f05a5cb/grpcio-1.12.1-cp35-cp35m-manylinux1_i686.whl
              << 200 OK 8.09m
127.0.0.1:62313: clientdisconnect
127.0.0.1:62311: clientdisconnect
127.0.0.1:62315: clientdisconnect

Contando algumas das solicitações desnecessárias:

• 4 x win32
• 4 x braço
• 4 x macosx

Etc. Parece uma vitória rápida para fazer uma filtragem simples com base no sistema operacional do host e no arco?

Você quer coisas filtradas por host e arquitetura, a maioria dos outros quer um arquivo de bloqueio que inclua hashes que lhes permita instalar nesses hosts e arquiteturas (temos um número significativo de hacks na base de código do resolvedor de pip que permitem especificamente isso, então não é novidades para nós)

Em relação à API JSON, ela não está realmente habilitada para atingir diretamente na versão atual, e estou planejando desativá-la na base de código novamente antes de lançarmos. Eu fiz um perfil extenso e sei que as chamadas com falha para packaging.version.parse() representam algo como 20-50% do tempo de execução do pipenv.

O Pip 10 usa a API JSON por padrão como seu resolvedor principal, portanto, a menos que você queira parar de usar o pip, não há muito o que fazer nessa frente.

Eu sinto que devemos estar baixando as mesmas coisas várias vezes, certo?

Provavelmente deveríamos mover a discussão para #2284. Na verdade, é a parte de bloqueio que é lenta ( install é essencialmente manipulação de TOML + lock + sync ), não instalando.

Em relação ao bloqueio para um único arco. Eu entendo a escolha do design; talvez possa haver uma opção para passar um sinalizador para permitir que um usuário bloqueie apenas para a arquitetura do host? Isso seria uma otimização bastante significativa em termos de tempo e largura de banda para alguns casos de uso.

@techalchemy obrigado pela sua resposta. A descoberta de packaging.version.parse() parece ser uma boa pista. Você poderia colocar um pouco mais de cor nesta declaração:

Em relação à API JSON, ela não está realmente habilitada para atingir diretamente na versão atual, e estou planejando desativá-la na base de código novamente antes de lançarmos.

Eu não entendi porque você está planejando desativá-lo?

@jkp Em relação à API JSON, digamos que não é a coisa mais bem projetada que existe. A API simples é muito mais adequada para nós. Ao desativá-lo, estamos usando a API simples, não usando nenhuma API.

Está demorando muito para eu instalar o Pyspark.
Meu Pipfile -

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

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

[requires]
python_version = "3.5"

saída do shell -

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

O processo está preso na última linha acima.
Termina após 15-20 minutos

pipenv, versão 2018.7.1

@keshavkaul PySpark é muito grande e pode levar algum tempo apenas para baixar. Dê um tempo, será muito melhor depois (porque o Pipenv armazena o resultado em cache).

(Ou você pode pedir aos desenvolvedores que lancem uma distribuição wheel. Isso ajudaria um pouco.)

Nota para futuros visitantes: Por favor, evite postar seu resultado de instalação lenta. Sabemos que pode ser lento. Sabemos porque é lento. Seu resultado não acrescenta nada a este tópico.

Seria possível ter alguma informação ou barra de progresso como apt-get ou wget (velocidade de download, tamanho baixado, tamanho total) durante os downloads das bibliotecas?
Acho que esse é o problema aqui, o pipenv parecia lento para mim, mas era apenas o download da biblioteca, tive que abrir um monitor do sistema para entender que o pipenv estava baixando os arquivos e quanto já foi baixado, qual velocidade etc.

tem o mesmo problema: Locking [packages] dependencies... trava para sempre
meu ambiente:

• macOS High Sierra 10.13.6
• Python: Python 3.6.4
• pipenv: versão 2018.7.1

@crifan, não há necessidade de postar a mesma mensagem em todos os problemas abertos ou fechados que mencionam a velocidade de bloqueio. Veremos seu comentário, não importa quantas vezes você diga a mesma coisa. Se você quiser ser útil, precisará fornecer um caso de exemplo reproduzível. Entrar em contato para dizer “eu também” simplesmente não adiciona nada além de tráfego extra no rastreador de problemas. Por favor, esteja atento a isso.

Mesmo aqui. Pipenv muito lento.
Leva uma hora para bloquear e instalar.

Acho que esse problema foi bem respondido aqui: https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

As dependências do Python exigem que baixemos e executemos totalmente os arquivos de configuração de cada pacote para resolver e calcular. Essa é apenas a realidade, é um pouco lento. Se você não puder esperar 2 minutos ou achar que não vale a pena, você sempre pode passar --skip-lock .

• por @techalchemy

Seria possível obter a lista de hashes da API PyPI, em vez de computá-los nós mesmos?

pipenv é incrível, mas esse problema parece ainda existir. ficará feliz em ver qualquer progresso. --skip-lock não funcionou.

pipenv é incrível, mas esse problema parece ainda existir. ficará feliz em ver qualquer progresso. --skip-lock não funcionou.

Trabalhou para mim

Descobri que usar o Git Bash no Windows era muito lento em comparação com o Powershell. Não tenho estatísticas ou dados sobre isso, mas o PS parecia mais rápido. Portanto, se você estiver usando o Git Bash, tente o PS nativo para pipenv 'ing.

Eu sei que esse problema está encerrado, mas para mim, ao instalar pandas, leva muito tempo. A saída detalhada é esta

pipenv install pandas --verbose
Installing pandas…
⠋ Installing...Installing 'pandas'
$ ['/Users/sinscary/.local/share/virtualenvs/signzy-MSzur11z/bin/pip', 'install', '--verbose', '--upgrade', 'pandas', '-i', 'https://pypi.org/simple']
Adding pandas to Pipfile's [packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
⠦ Locking...

Está travado no Locking por mais de 30 minutos. Estou usando python 3.7.0, macos mojave. Qualquer ajuda com isso.

Por que todas as questões para este tópico estão encerradas? Não consigo pipenv instalar uma única coisa devido ao travamento da etapa.

A imagem do docker a seguir leva mais de 30 minutos para ser criada no meu laptop (i7/16Gb), o comando pipenv install ... é executado por muito tempo...

Dockerfile

FROM python:3.7-alpine

# Update package list.
RUN set -ex && apk update

# Install apk dependencies.
RUN set -ex && apk add --no-cache musl-dev gcc libffi-dev openssl-dev make

# Install Pipenv.
RUN set -ex && pip install pipenv --upgrade

# Copy Pipfiles.
RUN mkdir /website
COPY Pipfile /website

# Install Pipenv dependencies.
WORKDIR /website
RUN set -ex && pipenv install --system --skip-lock --verbose

Pipfile

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


[requires]
python_version = "3.7"

[packages]
sanic = "*"
jinja2 = "*"
asyncpg = "*"
uvloop = "*"
munch = "*"

[dev-packages]

[pipenv]
allow_prereleases = true

Isso é normal? Alguém pode reproduzir?

Atualização: Tenha cuidado com Alpine Linux

Percebi que a questão não está do lado de pipenv ...

Substituí a imagem de encaixe base Alpine por uma que é construída no Debian-Slim e agora pipenv install termina em segundos.

O problema no meu exemplo é que o Alpine Linux sempre tentará construir pacotes que contenham cython-extension ou c-extensions da fonte, o que pode levar uma eternidade em um contêiner Docker, enquanto o Debian Linux os instala usando o wheel , que acontece MUITO mais rápido (em segundos).

Mais sobre isso: https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

Eu deixei pipenv há muito tempo e sempre que preciso criar env virtual em uso "venv" ou outras opções.

Tendo um problema de lentidão estranho também, apenas 2 módulos para alguns scripts que estou fazendo.

click

Demorou 15/20 min para instalar, testes de internet a mais de 60Mbps inativos e rodando em um MacBook Pro 2019 atualizado (não é minha escolha de hardware).

Por favor, use virtualenv por enquanto. até que a melhor solução esteja disponível

99% das vezes que faço isso, as dependências serão resolvidas para o mesmo no meu arquivo de bloqueio, isso porque faz parte do meu pipeline dev.

No caso em que não há novos pacotes upstream desde a última execução, certamente o processo pode ser ignorado?