<p>установка pipenv очень медленная</p>

Созданный на 15 мая 2017  ·  107Комментарии  ·  Источник: pypa/pipenv

Выполнение pipenv install после изменения одной зависимости у меня занимает около 5 минут на компьютере с Windows 10 и SSD.

Подавляющее большинство этого времени проводится внутри Locking [packages] dependencies...

Кажется, что на этом этапе может быть какая-то квадратичная или худшая сложность?

Я включил большую часть нашего pip-файла ниже, но мне пришлось удалить некоторые из наших частных зависимостей репо:

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

[packages]
alembic = "==0.8.4"
amqp = "==1.4.7"
analytics-python = "==1.2.5"
anyjson = "==0.3.3"
billiard = "==3.3.0.20"
braintree = "==3.20.0"
celery = "==3.1.18"
coverage = "==4.0.3"
docopt = "==0.4.0"
eventlet = "==0.19.0"
flake8 = "==3.0.4"
Flask-Cors = "==2.1.2"
Flask-Login = "==0.3.2"
Flask = "==0.12.1"
funcsigs = "==0.4"
fuzzywuzzy = "==0.12.0"
gcloud = "==0.14.0"
html2text = "==2016.9.19"
itsdangerous = "==0.24"
Jinja2 = "==2.8"
jsonpatch = "==1.15"
jsonschema = "==2.5.1"
PyJWT = "==1.4.2"
kombu = "==3.0.30"
LayerClient = "==0.1.9"
MarkupSafe = "==0.23"
mixpanel = "==4.3.0"
mock = "==1.3.0"
nose-exclude = "==0.4.1"
nose = "==1.3.7"
numpy = "==1.12.1"
pdfrw = "==0.3"
Pillow = "==4.1.0"
pusher = "==1.6"
pycountry = "==1.20"
pycryptodome = "==3.4.5"
pymongo = "==3.2"
PyMySQL = "==0.7.4"
python-dateutil = "<=2.5.1"
python-Levenshtein = "==0.12.0"
python-magic = "==0.4.6"
python-coveralls = "==2.9.0"
pytz = "==2015.6"
raygun4py = "==3.1.2"
"repoze.retry" = "==1.3"
requests = "==2.8.1"
sendgrid = "==2.2.1"
slacker = "==0.7.3"
SQLAlchemy-Enum34 = "==1.0.1"
SQLAlchemy-Utils = "==0.31.6"
SQLAlchemy = "==1.1.9"
typing = "==3.5.2.2"
twilio = "==5.6.0"
Unidecode = "==0.4.19"
voluptuous = "==0.8.11"
Wand = "==0.4.4"
watchdog = "==0.8.3"
Werkzeug = "==0.12.1"
wheel = "==0.24.0"
WTForms = "==2.0.2"
xmltodict = "==0.9.2"
zeep = "==0.24.0"

Самый полезный комментарий

Почему все вопросы к этой теме закрыты? Я не могу установить pipenv из-за зависания блокировки.

Все 107 Комментарий

Привет еще раз, @Diggsey , это связано с тем, как мы пишем изменения прямо сейчас. У меня есть эти изменения, готовые к слиянию, но они не работают для API projects.py поэтому мы собираемся отложить их до следующего крупного релиза. Надеюсь, мы подготовим это в ближайшие несколько недель. Я оставлю это открытым, чтобы отслеживать проблему на данный момент.

Мы вместе ускорили это на PyCon. Скоро будет быстрее.

Сейчас для меня это не медленно, это морозно...

pipenv install my_package или простой pipenv install не дают мне никаких результатов через 20 минут.

РЕДАКТИРОВАТЬ: Подтверждение, по-прежнему ничего через несколько часов. Это та же проблема? Обычно это было медленно, но закончилось через 5-10 минут.

Привет, @NicolasWebDev , какую версию pipenv ты используешь? Также у вас есть delegator.py установленные в вашей системе отдельно? Если да, то какая это версия? Это была проблема, которая должна была быть решена в v3.6.0.

Если все вышеперечисленное обновлено, не могли бы вы предоставить содержимое вашего Pipfile? Спасибо!

Привет @nateprewitt , ты был прав, у меня была версия 3.5.x. Обновление до 4.1.1 решило проблему зависания. Теперь это все еще занимает 5 минут, но, по крайней мере, это можно использовать!

Извините за шум, я всегда забываю, что пакеты, установленные через pip, автоматически не обновляются.
Спасибо!

Рад, что у тебя все разрешилось @NicolasWebDev! Мы работаем над тем, чтобы сделать это еще быстрее, надеюсь, № 373 станет на шаг ближе к следующему выпуску.

@Diggsey @NicolasWebDev , я только что выпустил 4.1.2, в котором должны быть добавлены эти улучшения скорости. Здесь еще предстоит проделать некоторую работу, но это, по крайней мере, ускорит начальную загрузку pipenv.

@nateprewitt Спасибо за обновление, теперь pipenv кажется мне быстрее, но по-прежнему требуется несколько минут, чтобы просто запустить pipenv lock , даже если ничего не изменилось - он все еще ждет Locking [packages] dependencies... для обширного большую часть этого времени.

@Diggsey , большая часть этого времени

@nateprewitt Мы могли бы удалить некоторые из них, но большинство из них являются прямыми зависимостями - зачем ему загружать все зависимости каждый раз, когда он создает файл блокировки?

Нам нужно определить все, что он устанавливает как зависимости. Для этого мы загружаем каждый пакет и определяем, как выглядит установка во время блокировки. Это позволяет нам правильно закрепить все в Pipfile.lock. Без загрузки нет надежного способа проверки подзависимостей и разрешения объявлений зависимостей диапазона.

Учитывая, что большинство пакетов со временем останутся неизменными, можно ли кэшировать загруженные пакеты?

@Diggsey хочет изучить это для нас?

Это может быть глупый вопрос, но разве Pip уже не кэширует пакеты ?

Я под впечатлением, что это так.

Может ли pipenv использовать систему кэширования пипсов или ее нужно реализовать с нуля?

Pipenv просто запускает pip, поэтому кеш должен использоваться автоматически.

фиксированный! блокировка сейчас очень быстрая.

О, спасибо. Я думаю, что это было единственное, что удерживало меня от того, чтобы подтолкнуть всех к pipenv на работе.

Вау, здорово, для меня это было ускорение более чем в 100 раз, а также обнаружился конфликт зависимостей, который не уловил предыдущая версия!

Что было бы полезно, так это флаг verbose для pipenv lock — я смог диагностировать конфликт зависимостей, только отредактировав piptools/logging.py чтобы включить подробное ведение журнала, но как только я это сделал, это дало очень четкое указание на то, что происходит.

Я наверное что-то упускаю :) Где исправлено? Последний выпуск вышел 4 дня назад, поэтому я установил последнюю версию с master . Однако pipenv install по-прежнему работает медленно.

Я пытался:

  • установите pipenv необычным способом ⚡️ 🍰 ⚡️
  • используйте как последнюю опубликованную версию pipenv и последнюю версию master
  • установить один пакет

При использовании последней стабильной версии (5.3.5.) установка одного пакета занимает 3:40:

∙ 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

При использовании версии от master все равно зависает (один пакет, +10 минут)

РЕДАКТИРОВАТЬ: Это только что закончилось:

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

Любые идеи? Большое спасибо!

Иногда для установки зависимостей требуется некоторое время, особенно если у них есть компиляции c. Хотите поделиться своими 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 может занять некоторое время, так как он может компилироваться из исходного кода. Все остальное должно быть красиво и быстро. Попробуйте удалить его и посмотрите, насколько увеличится ваша скорость.

Для меня $ pipenv install raven заняло всего 1 с.

$ pipenv install raven у меня занял 1 с.

Это то, что я ожидал! Можно ли как-то включить подробный вывод?

Я попытался удалить psycopg2 , но это не сильно повлияло. Запуск pipenv install raven зависает на некоторое время.

У меня есть:

  • Питон 3.6.2
  • макОС 10.12.6

я не вижу причин, почему Raven не должен быть мгновенным.

сделайте $ pip install raven внутри $ pipenv shell и скажите мне, если там тоже медленно.

Все, что делает pipenv, — это запуск pip, так что это фактически «подробный режим».

Это мгновенно:

∙ 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

Запуск pipenv зависает примерно на 2-3 минуты (внутри/снаружи 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, вы можете открыть новый выпуск о --verbose и привести пример того, как вы хотите, чтобы он выглядел?

@ tricoder42 : медленная часть — это этап блокировки или этап установки? Блокировка была значительно улучшена в последних версиях.

``` оболочка
$ time pipenv установить ворон
Установка ворона...
Сбор ворона
Использование кэшированного raven-6.1.0-py2.py3-none-any.whl
Требование уже выполнено: contextlib2 в /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (от raven)
Установка собранных пакетов: raven
Успешно установил raven-6.1.0

Добавление ворона в [пакеты] Pipfile...
Блокировка зависимостей [dev-packages]...
Блокировка зависимостей [пакетов]...
Обновлен Pipfile.lock!
9,30 реальный 5,49 пользовательский 0,42 системный

@tricoder42, а ты используешь последнюю

Позвольте мне повторить с вашим точным pipfile.

Полагаю, что так:

∙ 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

``` оболочка
$ время установить pipenv
Пакет не предоставлен, установка всех зависимостей.
Pipfile находится в /Users/kennethreitz/pipenv/testapp/Pipfile. Учитывая, что это проект дома.
Pipfile.lock не найден, создается...
Блокировка зависимостей [dev-packages]...
Блокировка зависимостей [пакетов]...
Обновлен Pipfile.lock!
Установка зависимостей из Pipfile.lock...
[===============================] 22/22 - 00:00:37
58,94 реальных 40,51 пользовательских 8,62 системных

Это происходит, даже когда я устанавливаю первый пакет в новый новый pipenv. Я попробую создать pipenv --three вместо pipenv --python python3.6

@tricoder42 хочешь

Или мы можем использовать совместное использование экрана Apple, если вы используете Messages.app.

Добавь меня! Я [email protected].

Я собираюсь присоединиться к собранию, но после этого я буду доступен.

Прохладный! Я попробую очистить и переустановить все с нуля, а там посмотрим. я свободен через час

Круто - тогда разберемся. Добавьте меня в messages.app :)

Если кто-то испытывает чрезвычайно медленное поведение Locking с v11.9.0 , я обнаружил, что понижение до v9.0.0 требует установки с 5 минут

@ryantuck Я бы порекомендовал, если вы собираетесь закрепить старую версию, чтобы закрепить 9.0.3 но вы теряете значительную дополнительную безопасность из-за скорости, вы можете просто использовать --skip-lock в эта точка

--skip-lock определенно ускорили процесс. Я пошел по этому пути, потому что pipenv install --system --python=3.6 самом деле не устанавливался на правильный системный python, и я предполагал, что мне нужно сгенерировать Pipfile.lock перед попыткой установки системы. Это все еще не сработало, поэтому я вернулся к использованию обычного старого pip , но прокомментирую эту тему, если когда-нибудь добьюсь прогресса в этом направлении.

—system и —python являются взаимоисключающими — для последнего варианта всегда требуется виртуальная среда

да, блокировка занимает некоторое время для меня тоже. v11.10.0. Убунту на 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

Это должно быть немного быстрее во второй или третий раз из-за
кеширование, т.к. Вы видите улучшение?
В четверг, 12 апреля 2018 г., 10:23 Александр Кавано <
уведомления@github.com> написал:

да, блокировка занимает некоторое время для меня тоже. v11.10.0. Убунту на WSL.

[[source]]url = " https://pypi.python.org/simple"verify_ssl = truename = "pypi"
[пакеты] 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"ворон = "==6.6.0"sendgrid-django = "==4.2.0"бездельник = "==0.9.65"termcolor = "==1.1.0"tqdm = "==4.21.0"twitter-ads = "==3.0.0"brotlipy = "==0.7.0"официантка = "==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"
[требуется] python_version = "3.6"

Pipfile.lock не найден, создается…
Блокировка зависимостей [dev-packages]…
Блокировка зависимостей [пакетов]…
Обновлен Pipfile.lock (7a535c)!
Установка зависимостей от Pipfile.lock (7a535c)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

реальные 8м1.993с
пользователь 5m32.406s
система 7m15.203s


Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pipenv/issues/356#issuecomment-380882203 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

Я уже установил пакеты до этого; Я просто удалил файл блокировки и снова запустил установку. Я сделаю это снова, чтобы получить другую точку данных

@jtratner Вау . Очень интересно... почему кеширование срабатывает только после третьего и более раза?

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 также представил функцию кэширования хэшей, что должно значительно улучшить ситуацию.

Я здесь... 15 минут спустя

@giantas бесполезен. Укажите pipfile, выходные данные и продолжительность установки pip. Также можете ли вы делать отдельные пакеты.

Для работы на моей машине требуется довольно много. macOS 10.13.4, pipenv, версия 11.10.0

Загрузка запускается почти сразу, но потом зависает на Locking [packages] dependencies… . Вот полминуты для двух зависимостей, а затем 6 минут для еще 3 зависимостей, если я брошу на него все зависимости моего проекта, он просто зависнет на неопределенный срок на шаге блокировки

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 черт возьми , это медленно! Обратите внимание, что это частично связано с установкой numpy, который, я уверен, мы, вероятно, компилируем из исходного кода в блокировку или что-то глупое. помогло бы, если бы мы предоставили полезный вывод здесь

Могу ли я что-нибудь с этим поделать? или мне просто не повезло с использованием pipenv и медленным временем блокировки файлов? Думаю, я мог бы --skip-lock, но я как бы хотел эту функцию

@pablote, можете ли вы проверить, повторяете ли вы ту же операцию блокировки, она все еще медленная?

Если я перезапущу его, он завершится почти сразу, поэтому я думаю, что это просто первый раз, когда добавляется какая-то новая зависимость.

так что на самом деле это кэширование хэшей локально, поэтому по какой-то причине процесс генерации хэшей здесь невероятно медленный...

Дайте мне знать, если есть какая-либо информация, которую я могу предоставить, чтобы помочь в диагностике. На данный момент я просто вернусь к pip + virtualenv + pip-tools :/

@pablote, когда у вас есть хэши один раз, блокировка снова не будет такой медленной

Пожалуйста, предоставьте полезный вывод. Я только что обновил свой pipenv с 9.1.0 до 11.10.0, чтобы устранить ошибку недопустимого маркера на этапе блокировки пакета, например, # 1622 --- теперь у меня есть pipfile с ipykernel, pandas, jupyter, numpy, и matplotlib там, и с моей последней попыткой использовать pipenv install для запуска файла блокировки, я сидел в locking [packages] dependencies… более 10 минут.

Поскольку вывода нет, я не могу сказать, действительно ли что-то происходит (например, создание numpy из исходного кода) или оно просто зависает. Лучшее, что я могу сделать, это как бы покоситься на top и сделать вывод, что, возможно, он что-то делает, потому что процесс Python, кажется, зависает ... но мне придется выбросить этот виртуальный файл и начать заново, если что-то не скоро сдвинется.

Я рад внести свой вклад в работу над этим, если это необходимо.

Пожалуйста, предоставьте полезный вывод. Я только что обновил свой pipenv с 9.1.0 до 11.10.0, чтобы устранить ошибку недопустимого маркера на этапе блокировки пакета, например, # 1622 --- теперь у меня есть pipfile с ipykernel, pandas, jupyter, numpy, и matplotlib там, и с моей последней попыткой использовать pipenv install для запуска файла блокировки я сидел в блокировке зависимостей [пакетов]… более 10 минут.

Совершенно понятная жалоба, и я крутился в глубине души, пытаясь подумать о том, как мы можем предоставить более полезную обратную связь пользователю (потому что я согласен, что это немного сбивает с толку, что у него нет никакого вывода). Я бы сдался через 15 минут. Как отметил @techalchemy , каждый раз ваш кеш должен заполняться немного больше, поэтому со временем он должен становиться все быстрее.

Один вопрос: используете ли вы публичный PyPI?

@jtratner да, используя общедоступный PyPi --- и в конце концов я сдался, разгромил virtualenv и создал новый; Мне удалось создать файл блокировки, установив мои зависимости по одной за раз. (Интересно, что matplotlib был самым медленным --- даже хуже, чем numpy!)

Возможно, такое сообщение, как This may take a long time , поможет успокоить людей, пока не будет принято более четкое решение.

15 минут все еще безумно долго, я сомневаюсь, что буду сидеть и ждать этого. @paultopia вы можете запустить pipenv lock —verbose для большего вывода

В целом кажется, что он медленнее, чем должен быть, но, возможно, я недооцениваю проблему. Если я посмотрю на запущенные процессы на моем компьютере, я увижу, что python работает все время, пока работает pipenv, и он никогда не превышает ~ 15%, вероятно, ему следует использовать больше, если он выполняет интенсивную работу процессора, например хеширование файлов. . Кроме того, я использовал другие менеджеры пакетов, которые хешируют зависимости, такие как пряжа, и они довольно быстрые.

Нам нужно выяснить, что он делает...

Я создал проект github, демонстрирующий медлительность при использовании блокировки. Пожалуйста, посмотрите https://github.com/AndreasPresthammer/slow-pipenv . Хотя я не уверен на 100%, что это одна и та же проблема. Вытащите репозиторий и запустите сценарий slow.sh и наблюдайте за разницей во времени выполнения.

@AndreasPresthammer, так что ваш скрипт просто синхронизирует некешированную блокировку по сравнению с установкой с блокировкой. Мы знаем, что это блокировка, но она медленная. В случае numpy это, вероятно, потому, что в прошлом ему приходилось использовать sdists для разрешения, что означало компиляцию. Теперь мы можем использовать колеса. Это может ускорить процесс

Это определенно все еще проблема (5+ минут) с последними версиями python3.6, pip и pipenv и установкой простого пакета, такого как torch . Я не думаю, что этот вопрос следует помечать как закрытый.

Для всех, кто хочет прокомментировать закрытие этой проблемы: предоставьте вывод pipenv lock --verbose . Мы знаем, что разрешение является медленным для пакетов, которые компилируются из исходного кода и сборка которых занимает много времени в нормальных условиях. Нам нужны журналы, чтобы понять причину, если это происходит медленнее, чем обычно.

Я также использую Docker для своей среды разработки и производства и думаю, что установка внутри Docker кажется медленной по сравнению с установкой на хосте. Возможно, это просто комбинация всех пакетов, но я хотел бы услышать отзывы от людей более опытных, чем я.

Вот журнал pipenv lock --verbose , включая Pipfile и Pipfile.lock :

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

@mimischi Результаты разрешения кэшируются на хосте, но Docker не может получить к ним доступ. Это медленно, потому что нужно переделать все разрешение с нуля. Это поможет, если вы смонтируете каталог кеша хоста в Docker. В проблеме есть комментарий, в котором упоминается путь, который вы должны смонтировать. У меня нет времени искать его сейчас, но вы можете попытаться найти его. (И, пожалуйста, добавьте его на страницу часто задаваемых вопросов документа, когда вы это сделаете!)

FWIW, блокировка моего ящика разработчика теперь занимает менее 30 секунд. Гораздо лучше, чем раньше - оцените это.

Привет, такая же проблема.
вот подробно

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…

Вот pipenv --version : pipenv, версия 2018.05.18

Также я не знаю, почему это происходит, нет конкретной причины/ошибки.
В моем случае, когда я делаю pipenv lock он начинается, но никогда не заканчивается, насколько мне известно. Жду уже 2 часа, до сих пор нет признаков завершения. И дважды дал мне ReadTimeoutError, это третий раз, когда я делаю это.
Использование Python 3.6.4

Любая помощь будет очень полезна, так как срок выполнения моих проектов приближается.

Также проголосуйте за повторное открытие этого вопроса. Это далеко не решено... потребуется где-то 10-20 минут, чтобы заблокировать мой проект в контейнере Docker. Он также использует безумное количество памяти — так что мне пришлось увеличить выделение для Docker, чтобы он не убил процесс.

Пожалуйста, предоставьте пример Pipfiles и сведения о вашей среде, если вам нужна помощь в решении проблем со скоростью разрешения. На этой неделе мы вырезаем релиз, и у нас нет времени отслеживать отдельные разовые комментарии в закрытых темах, но мы можем протестировать Pipfiles, если вы их предоставите.

@jkp Позвольте мне заверить вас, что каждый основной разработчик этого проекта (не то, чтобы нас было много с самого начала) очень хорошо осведомлен об этой проблеме и обеспокоен ею так же, как и вы, если не больше. Однако это ни в коем случае не простая проблема, и мы уже приложили к ней все усилия, чтобы сделать ее максимально удобной для использования без необходимости разбирать все в пакете Python. Мы также имеем много на нашей тарелке на данный момент, и необходимо также сосредоточить внимание на тех , других вопросах. Таким образом, неизбежное решение, которое я должен принять, состоит в том, чтобы определить приоритеты проблем, которые мы действительно знаем, как решить, и начать думать о наших следующих шагах только после того, как они будут сделаны, чтобы максимизировать эффект наших усилий.

Я полностью признаю, что ваш приоритет может отличаться от нашего. Эта проблема с производительностью может быть самой большой проблемой в вашем рабочем процессе, и вы хотите сделать ее самой важной в этом проекте. Однако имейте в виду, что вы не единственный пользователь этого инструмента, и мы должны отдавать приоритет потребностям всех, даже нашим собственным , перед вашими. Я признаю это. Поэтому я призываю всех, кто разделяет ситуацию, объединить мнения по этому вопросу и попытаться придумать способ его решения. Как только мы знаем, что на самом деле делать, мы можем это сделать.

Проблема остается закрытой, потому что мы не знаем, что мы можем сделать, и будет служить только шумом в системе отслеживания проблем, когда мы попытаемся справиться с ней. Нет смысла, по крайней мере, в нашем рабочем процессе, иметь проблему, над которой никто не может работать.

Цените свой рабочий процесс, поэтому, если вы решаете проблемы именно так, это нормально. Я постараюсь добавить любую информацию, которую я могу помочь отследить проблему.

Я провел некоторую отладку, установив mitmproxy между pipenv и сетью, чтобы отслеживать выполняемые запросы. Я нашел пару интересных вещей.

  1. Мы используем закрытый индекс pypi который еще не поддерживает индекс json-api . Это значительно замедляет работу, поскольку похоже, что запасной вариант заключается в переборе и загрузке всего, указанного в http-индексе, для извлечения метаданных и т. д. Одним из предложений здесь было бы просто добавить какое-то простое ведение журнала, чтобы предупредить, что этот резервный метод используется — это может избавить кого-то еще от необходимости копать глубже, чтобы понять это.

  2. Используя метод грубой силы, кажется, что код загружает пакеты, которые не имеют отношения к используемой архитектуре. Например, на Linux-машине он загружал win32 или osx определенные пакеты колес. Это похоже на то, что можно обнаружить и избежать, поскольку ясно, что бинарные пакеты, созданные для других архитектур, бесполезны.

Я буду продолжать отлаживать и сообщать любую полезную информацию по мере ее обнаружения.

Похоже, что даже при использовании интерфейса json pipenv делает ненужные запросы на файлы колес, относящиеся к разным архитектурам. Реализация в настоящее время довольно наивна в том смысле, что она проверяет все файлы, перечисленные в данном выпуске, независимо от целевой платформы/архитектуры.

Минимальный тест-кейс:

На хосте Linux: pipenv install grpcio

Произведены следующие запросы (захваченные с помощью 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

Подсчет некоторых ненужных запросов:

  • 4 х Win32
  • 4 х рука
  • 4 х Macosx

И т. д. Кажется, что можно быстро выполнить простую фильтрацию на основе ОС хоста и архитектуры?

Вы хотите, чтобы вещи отфильтровывались по хосту и архитектуре, большинству других нужен файл блокировки, который включает хэши, которые позволят им устанавливать на эти хосты и архитектуры (у нас есть значительное количество хаков в кодовой базе pip-преобразователя, которые специально позволяют это, так что это не так). новость для нас)

Что касается API-интерфейса JSON, то в текущем выпуске он фактически не может работать напрямую, и я планирую снова отключить его в кодовой базе перед выпуском. Я выполнил обширное профилирование и знаю, что на неудачные вызовы packaging.version.parse() приходится примерно 20-50% времени выполнения pipenv.

Однако Pip 10 по умолчанию использует JSON API в качестве основного преобразователя, поэтому, если вы не хотите прекратить использовать pip, в этом отношении вам особо нечего делать.

Я чувствую, что мы должны скачивать одни и те же вещи несколько раз, верно?

Вероятно, нам следует перенести обсуждение на #2284. На самом деле медленная часть блокировки ( install по сути является манипуляцией с TOML + lock + sync ), а не установка.

По поводу замыкания на одинарную. Я понимаю выбор дизайна; возможно, можно было бы передать флаг, чтобы разрешить пользователю блокировку только для архитектуры хоста? Это было бы довольно значительной оптимизацией как с точки зрения времени, так и пропускной способности для некоторых вариантов использования.

@techalchemy спасибо за ваш ответ. Находка packaging.version.parse() кажется хорошей зацепкой. Не могли бы вы добавить больше красок в это утверждение:

Что касается API-интерфейса JSON, то в текущем выпуске он фактически не может работать напрямую, и я планирую снова отключить его в кодовой базе перед выпуском.

Я не понял, почему вы планируете отключить его?

@jkp Что касается JSON API, скажем так, это не самая лучшая разработка. Нам гораздо больше подходит простой API . Отключив его, мы используем простой API, а не вообще никаких API.

Установка Pyspark занимает слишком много времени.
Мой пипфайл -

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

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

[requires]
python_version = "3.5"

вывод оболочки -

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

Процесс застрял на последней строке выше.
Заканчивается через 15-20 минут

pipenv, версия 2018.7.1

@keshavkaul PySpark очень большой, и его загрузка может занять довольно много времени. Дайте ему немного времени, потом будет намного лучше (потому что Pipenv кэширует результат).

(Или вы можете призвать разработчиков выпустить дистрибутив колеса. Это немного поможет.)

Примечание для будущих посетителей: Пожалуйста, воздержитесь от публикации результатов медленной установки. Мы знаем, что это может быть медленно. Мы знаем, почему это медленно. Ваш результат ничего не добавляет к этой теме.

Можно ли иметь некоторую информацию или индикатор выполнения, например apt-get или wget (скорость загрузки, загруженный размер, общий размер) во время загрузки библиотек?
Я предполагаю, что это проблема здесь, pipenv казался мне медленным, но это была просто загрузка библиотеки, мне пришлось открыть системный монитор, чтобы понять, что pipenv загружает файлы и сколько уже загружено, какая скорость и т. д.

та же проблема: Locking [packages] dependencies... зависает навсегда
моя среда:

  • macOS Высокая Сьерра 10.13.6
  • Питон: Питон 3.6.4
  • пипенв: версия 2018.7.1

@crifan нет необходимости публиковать одно и то же сообщение при каждой открытой или закрытой проблеме, в которой упоминается скорость блокировки. Мы увидим ваш комментарий независимо от того, сколько раз вы говорите одно и то же. Если вы хотите быть полезным, вам нужно будет предоставить воспроизводимый пример. Если вы скажете «я тоже», это просто не добавит ничего, кроме дополнительного трафика на трекере. Пожалуйста, помните об этом.

То же самое. Пипенв очень медленный.
Блокировка и установка занимает час.

Я думаю, что на эту проблему хорошо ответили здесь: https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

Зависимости Python требуют от нас полной загрузки и выполнения установочных файлов каждого пакета для разрешения и вычисления. Это просто реальность, это немного медленно. Если вы не можете ждать 2 минуты или считаете, что это не стоит компромисса, вы всегда можете передать --skip-lock .

  • от @techalchemy

Можно ли получить список хэшей из PyPI API, а не вычислять их самостоятельно?

pipenv великолепен, но эта проблема, похоже, все еще существует. буду рад любому прогрессу. --skip-lock не сработал.

pipenv великолепен, но эта проблема, похоже, все еще существует. буду рад любому прогрессу. --skip-lock не сработал.

Работал на меня

Я обнаружил, что использование Git Bash в Windows было очень медленным по сравнению с Powershell. У меня нет статистики или данных по этому поводу, но PS показался быстрее. Поэтому, если вы используете Git Bash, вы можете попробовать нативную PS за pipenv .

Я знаю, что эта проблема закрыта, но для меня установка панд занимает много времени. Подробный вывод таков

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

Он застрял в блокировке более 30 минут. Я использую Python 3.7.0, MacOS Mojave. Любая помощь в этом.

Почему все вопросы к этой теме закрыты? Я не могу установить pipenv из-за зависания блокировки.

Сборка следующего образа докера на моем ноутбуке (i7/16Gb) занимает более 30 минут, команда pipenv install ... выполняется целую вечность...

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

Это нормально? Кто-нибудь может воспроизвести?

Обновление: будьте осторожны с Alpine Linux

Я понял, что проблема не на стороне pipenv ...

Я заменил базовый образ докера Alpine на образ, построенный на основе Debian-Slim, и теперь pipenv install завершается за секунды.

Проблема в моем примере заключается в том, что Alpine Linux всегда будет пытаться собрать пакеты, содержащие cython-extension или c-extensions из исходного кода, что может занять вечность в контейнере Docker, в то время как Debian Linux устанавливает их с помощью cython-extension или c-extensions wheel Формат

Подробнее об этом: https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

Я давно оставил pipenv и всякий раз, когда мне нужно создать виртуальную среду, используйте «venv» или другие параметры.

У меня также странная проблема с медлительностью, только 2 модуля для некоторых сценариев, которые я делаю.

click

Установка заняла 15/20 минут, интернет-тесты со скоростью более 60 Мбит / с работают на обновленном MacBook Pro 2019 (не мой выбор оборудования).

Пожалуйста, используйте virtualenv на данный момент. пока не появится лучшее решение

В 99% случаев, когда я это делаю, зависимости разрешаются в один и тот же файл блокировки, потому что это часть моего конвейера разработки.

В случае, если с момента последнего запуска нет новых исходных пакетов, можно ли пропустить процесс?

Была ли эта страница полезной?
0 / 5 - 0 рейтинги