Pipenv: Блокировка выполняется медленно (и выполняет избыточные загрузки)

@colllin Вы проверили, pip search (я думаю), также медленными?

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

РЕДАКТИРОВАТЬ: также может быть, что вам просто нужно разрешить много подчиненных зависимостей - насколько велика среда после создания (например, сколько пакетов верхнего уровня в вашем pipfile и сколько пакетов возвращено pip list после загрузки среды)?

Спасибо за вдумчивый ответ.

pip search для меня не особенно быстро или медленно ... ~ 1 секунда?

Простите меня за незнание предметной области: действительно ли нужен пип-поиск? Разве он не просто все установил? Разве не нужно просто записать то, что уже установлено? Или ... поскольку он в любом случае обеспечивает существование файла блокировки, может ли он сделать это во время установки пакетов или раньше?

Я предполагаю ... pipenv использует pip под капотом? так что процесс установки - это черный ящик, и он не может знать график зависимостей того, что было / будет установлено, не выполнив ~ поиск по пипу ~ ~ свои собственные запросы по пипу?

РЕДАКТИРОВАТЬ: есть 1 пакет верхнего уровня и ~ 65 пакетов, возвращаемых pip list в этом конкретном репо.

Я не участвую в проекте и на данный момент не знаю всех подробностей, но я понимаю, что на этапе блокировки все зависимости разрешаются и закрепляются. Итак, если у вас есть один пакет верхнего уровня с ~ 65 зависимостями, именно во время фазы блокировки обнаруживаются (рекурсивно) все зависимости этого первого пакета, а затем дерево зависимостей используется для определения того, какие пакеты необходимо установить и (возможно) в каком примерном порядке они должны быть установлены. Не так уверен насчет последней части.

Если вы выполняете установку из Pipfile без файла блокировки, вы заметите, что он выполняет фазу блокировки перед установкой пакетов в venv. Точно так же, если у вас есть файл блокировки, но он устарел. Я подозреваю, что наличие файла блокировки и установка с использованием параметра --deploy была бы быстрее, как и вариант --no-lock ; в первом случае вы получите ошибку, если файл блокировки устарел, во втором вы потеряете логическое разделение пакетов верхнего уровня (объявленная среда) и фактическая установленная (заблокированная) среда всех пакетов. По крайней мере, я так понимаю.

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

Интересным экспериментом может быть сравнение времени, необходимого для блокировки дерева зависимостей в pipenv, и установки требований в новый venv с использованием pip install -r requirements.txt . Я думаю, что они должны делать очень похожие вещи на этапе разрешения зависимостей.

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

К вашему сведению, сравнение pip install -r requirements.txt со временем, которое требуется для блокировки графа зависимостей, не будет информативным в качестве точки сравнения. У Пипа на самом деле нет резолвера, ни в каком реальном смысле. Думаю, я могу описать разницу. Когда pip устанавливает ваш requirements.txt , он следует этому базовому процессу:

• Найдите первое требование в списке
  
  
  
  • Найдите все его зависимости
  
  
  • Установите их все
  
  
• Найдите второе требование в списке
  
  
  
  • Найдите все его зависимости
  
  
  • Установите их все
  
  
• Найдите третье требование в списке
  
  
  
  • Найдите все его зависимости
  
  
  • Установите их все
  
  

Оказывается, это происходит довольно быстро, потому что pip на самом деле не заботится о том, противоречат ли зависимости _package 1_ зависимостям _package 3_, он просто установил те из _package 3_ последними, что вы получите.

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

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

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

Одно уточнение: как только вы разрешите полный граф зависимостей, порядок установки больше не будет иметь значения. Под капотом мы все равно передаем --no-deps каждой установке.

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

Блокировка numpy (и ничего больше) на моей машине занимает 220 секунд (см. Ниже). Похоже, что большую часть времени тратится на загрузку более 200 МБ данных, что довольно озадачивает, учитывая, что весь исходный код numpy имеет 4 МБ. Хотя очевидно, что даже если бы это было мгновенно, фактическая обработка еще 25 секунд, и даже это кажется чрезмерным для вычисления нескольких хэшей. Последующая блокировка, даже после удаления Pipenv.lock, занимает 5 секунд.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Теперь Numpy должен быть значительно быстрее (на самом деле я использовал ваш пример в качестве тестового примера!). В моем последнем тесте у меня было ~ 30 секунд в холодном кэше на виртуальной машине.

Можете ли вы подтвердить какие-либо улучшения в последней версии?

Для меня это тоже существенно улучшилось. Я сейчас сижу на очень быстром соединении и получил всего 14 с, но это было тогда, когда загрузка шла со скоростью 30 МБ / с. Что загружается помимо единственной копии исходного кода numpy?

Думаю, мы загружаем лишние колеса (не уверен). Мы уже оцениваем ситуацию.

Я резко изменил свой Pipfile.lock, удалив изменения fe, и теперь развертывание его на другом компьютере зависает. Какое-нибудь конкретное исправление для этого?

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

Если вы хотите протестировать производительность блокировки pipenv, вам следует попробовать добавить pytmx в свои зависимости ...
Раньше блокировка pipenv занимала у нас 1 час или больше (у нас довольно медленный интернет), а после удаления pytmx мы сократились примерно до 5 минут, и, наконец, pipenv более удобен.
Я знаю, что pytmx - это большой пакет, потому что это большая монолитная библиотека и зависит от opengl / pygame и других связанных вещей, но блокировка pipenv не должна занимать 1 час, независимо от того, насколько велик пакет

Для меня это займет не один час

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

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

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

@techalchemy Я не редактировал файл вручную. Я удалил множество зависимостей с помощью pipenv uninstall package_name а затем запустил его на сервере. Он очень долго находился в заблокированном состоянии.

Мне не интересно тратить силы на эту дискуссию со случайными снимками в темноте. Предоставьте воспроизводимый тестовый пример.

Я надеюсь, что это воспроизводимый тестовый пример.
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Попытка сделать
pipenv install
в этом репозитории без блокировки на данный момент было загружено более 700 МБ или около того, пока он отображается
Locking [packages] dependencies...

Через некоторое время сдастся и повторите попытку с --skip-lock пока не будет исправлено.

Я заметил, что lock был очень медленным и загрузил огромное количество данных из files.pythonhosted.org , более 800 МБ для небольшого проекта, который зависит от scipy flask и т. Д.

Итак, я обнюхал запросы, сделанные к files.pythonhosted.org , и оказалось, что pip или pipenv выполняли совершенно ненужные загрузки, что делает lock мучительно медленным.

Например, одна и та же версия numpy была загружена несколько раз полностью. И он скачал колеса для windows / linux, хотя я использовал Mac.

Моя установка:

$ pipenv --version
pipenv, version 2018.05.18

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

полезны ли здесь дополнительные Pip-файлы для отладки?

Скорее всего @AlJohri , также

Застрял здесь уже минут 5. Сначала подумал, что это могут быть какие-то проблемы с установкой pip, и переустановил все свежее через Homebrew, но все та же проблема. Есть идеи, почему?

Окончательно закончили примерно через 6-7 минут. Довольно новичок в Python и Pipenv, поэтому небольшая подсказка о том, где найти файлы, необходимые для отладки, было бы здорово! :)

это довольно плохо, я боюсь устанавливать новые библиотеки python или обновлять существующие.

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

Спасибо за содержательный отзыв.

@techalchemy Если есть что-то, что я могу сделать, чтобы исправить это. Я очень рад внести свой вклад.

Я заметил, что lock был очень медленным и загрузил огромное количество данных из files.pythonhosted.org , более 800 МБ для небольшого проекта, который зависит от scipy flask и т. Д.

У меня есть подозрение, хотя и не окончательное, что scipy коррелирует с очень долгим временем блокировки pipenv .

временами очень больно, я устанавливаю PyPDF2 и textract; Для блокировки pipenv потребовалось ~ 10 минут.

Медлительность pipenv действительно мешает нам процессу разработки. Теперь я советую всем придерживаться pip + virtualenv, пока эта проблема не будет решена.

Есть новости по этому поводу? Есть ли способ помочь?
обман https://github.com/pypa/pipenv/issues/1914

/ edit: кстати, почему pipenv install обновляет версии в файле блокировки? o.Ò Я просто запустил его после того, как время блокировки истекло, и теперь, когда я смотрю новый файл блокировки, я вижу, что pandas был обновлен с 0.23.4 до 0.24.0, numpy с 0.16.0 до 0.16.1 и т. д. Didn не ожидаю, что это произойдет, если я не сделаю pipenv update ...

Я считаю, что он устанавливается быстро и медленно блокируется, поэтому, как только вы получите сообщение Installation Succeeded можете продолжать работу ... если вы не хотите установить что-то еще ...

... или нужно поместить файл блокировки в какое-то репо.

Должна ли команда install любом случае выполнять предварительную блокировку, учитывая, что lock уже является отдельной командой? Между тем, описание параметра install должно указывать, что блокировка также имеет место, и, возможно, даже рекомендовать --skip-lock .

Кроме того, как насчет закрепления этой проблемы?

Pipenv - действительно замечательный инструмент, и я рекомендовал его, но проект с 8 модулями не может заблокироваться ... он просто истекает. Кажется, нет никакого интереса к решению этой проблемы, и это очень расстраивает. Я читал, что теперь вы можете получать зависимости без загрузки из pypy, это обходной путь для этой проблемы? Не вижу здесь разговоров об этом варианте. На данный момент инструмент непригоден для моих целей.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

Почему это не главный приоритет этого проекта? Pipenv настолько медленный, что его практически невозможно использовать. И не только в некоторых необычных случаях использования, он всегда очень медленный.

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

Подумайте об этом: если мы кэшируем этот пакет x-1.2.3 зависит от y>=3.4 , мы можем локально выполнять большую часть работы, которая в настоящее время выполняется, по загрузке пакетов по одному, их расширению и проверке зависимостей. . Тогда фаза lock будет такой же простой, как:

• Сравните Pipfile с кешем и убедитесь, что у нас есть все необходимое.
• Если нет, скачайте что-нибудь новое и рассчитайте там зависимости.
  
  
  
  • Кэшировать изменения
  
  
• Установить.

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

Я просто решил использовать pipenv вместо pip для небольшого проекта. Первым делом я сделал pipenv install -r requirements.txt . Он блокировал зависимости около 10 минут. Поэтому я вернусь к Пипу.

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

В моем случае установка зависимостей на сервере зависает на несколько часов. Я использую экземпляр AWS EC2 t2.micro с 1 ГБ оперативной памяти. Этого объема оперативной памяти достаточно для одного приложения с несколькими зависимостями, но установка занимает всю память, и есть только один способ заставить его работать, перезапустив сервер.

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

Такой хороший инструмент, которым пренебрегают. Я откажусь от подписки по этой проблеме, так как я вижу, что она никогда не будет решена. Будет придерживаться чего-то вроде conda или делать это вручную с помощью virtualenv.

Думаю, я попробую https://github.com/sdispater/poetry : |

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

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

Спасибо!

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

Привет @idvorkin ,

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

Я определенно не хочу вносить какие-либо исправления в этот проект.

Так что ваш совет не так жизнеспособен, как вы думаете.

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

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

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

Точно так же я готов поспорить, если бы вы (или кто-либо другой) исправили проблему с производительностью, у вас было бы множество людей, которые помогли бы вам разработать, протестировать, объединить или, если потребуется (и я очень сомневаюсь, что это будет), создать вилку .

Я благодарен за время, которое разработчики этого проекта тратят на это, но я предлагаю выделить жирным шрифтом, что этот проект еще не готов к производству, прямо над отзывами пользователей в README.md , в настоящее время это вводить людей в заблуждение тратить драгоценное время на замену текущего стека pip / virtualenv на pipenv, пока они не узнают об этой медленной блокировке и не поймут, что не могут ее использовать.

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

Хотя я был бы очень рад получить ускорение, поскольку оно действительно очень медленное, в таких преувеличениях нет необходимости.

Я отлично использую pipenv каждый день. Усовершенствования рабочего процесса, которые он обеспечивает, значительно перевешивают случайную медлительность. Блокировка - это не то, чем я занимаюсь постоянно, в отличие, например, от запуска скриптов.

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

@bochecha мое утверждение может быть pipenv install <something> мне приходилось ждать смехотворно долго, сначала я думал, что он вычисляет что-то, и он будет кэшировать его на будущее, так как я не мог поверить, что это проблема в заявлении о том, что он является менеджером пакетов, готовым к производству. После установки ~ 10-го пакета я начал его искать и нашел эту ветку, я удалил Pipfile и Pipfile.lock и вернулся к своему рабочему процессу pip / virtualenv. Мне хотелось попробовать стихи, но я не мог рисковать еще часом.

Это происходит, например, в сообществе JS, но я не ожидаю этого в сообществе Python, у нас нет таких проблем в нашем сообществе, и мы должны попытаться избежать этого, отказ от ответственности в README.md может избежать это неудобство, поэтому я предложил это в своем комментарии. Это могло бы сэкономить мое время сегодня, и я думаю, что это сэкономит время для других новичков, и у них не будет плохого опыта с этим проектом, поэтому они могут остаться в качестве потенциальных будущих пользователей.

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

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

каждый раз, когда я запускал pipenv install

Знаете ли вы, что pipenv install -r requirements.txt нужно заблокировать / установить только один раз из существующего проекта, когда вы пытаетесь перенести его на pipenv? Если вы этого не сделаете, проблема может быть в документации?

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

@bochecha, как я объяснил, мне пришлось установить более новую версию пакета, сделать кое-что, а затем перейти к следующему пакету, возможно, если бы я проделал этот процесс с помощью pip, а затем перешел на pipenv, я бы вообще не заметил проблемы, но я сначала перешел на pipenv, а затем обновлял пакеты одно за другим, и это действительно раздражало. Я рад, что это работает для вашего случая использования, но я уверен, что это не работает для многих людей, таких как я (взгляните на комментарии выше). Это следует упомянуть в README.md , по крайней мере, следует упомянуть, что «каждая блокировка может занять много времени, поэтому, если ваш сценарий использования включает в себя установку / удаление большого количества пакетов быстро, вам следует избегать использования pipenv, пока эта проблема не будет устранена. решено »(снова выделено жирным шрифтом и поверх отзывов), если вы объявите о проблемах до того, как это затронет кого-либо, все будут благодарны, если проблемы затронут других, а вы не предупредили их, все разозлятся.

Согласованный. Я начал изучать поэзию и даже при добавлении еще одного пользователя в свою ОС для каждого проекта вместо того, чтобы снова использовать pipenv. Если он не работает нормально для случайных случаев использования с настройками по умолчанию, он сломан imho .
Супер полезный инструмент! Есть только одна вещь, которая делает его бесполезным для меня. И, к сожалению, у меня мало времени, чтобы внести свой вклад: |

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

Важно то, что файл блокировки создается перед отправкой локальных изменений в репо. Я разумно использую флаг —skip-lock во время сеансов разработки и pipenv lock один раз в конце перед фиксацией.

Спасибо за проект. Но,
Блокировка очень медленная.

PIP_NO_CACHE_DIR=off
Этот env делает блокировку более быстрой, если в нем уже установлен кеш пакетов pip.

Привет @yssource и всем,

Спасибо за проект. Но,
Блокировка очень медленная.

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

@Jamim , спасибо за предложение Поэзии. Лично мне почему-то не попадалось. Прочитав его ридми, кажется, стоит попробовать. В нем также перечислены некоторые преимущества по сравнению с Pipenv (https://github.com/sdispater/poetry/#what-about-pipenv).

Сказав это, то, что проект мертв - это сильное преувеличение, и если бы я был на месте авторов pipenv, я бы счел это неуважением. Автор ответил в разделе вопросов только вчера. Просто эта проблема с блокировкой упускается из виду, вероятно, потому, что ее трудно исправить.

Для справки, Poetry также страдает от проблем с производительностью:
https://github.com/sdispater/poetry/issues/338

У меня одна и та же проблема во всех моих проектах.
Причина вроде бы в пилинте.
Pipenv (pip) может установить его успешно, но блокировка занимает вечность!
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

Я много слышал о pipenv и пробовал сегодня,
блокировка также очень медленная для меня. Прошло уже около 2 минут, все еще застревает на замке.
Скачивание происходит довольно быстро, но проблема связана с блокировкой.
Эта проблема решена?
Я использую Pop os 19.10, pipenv, версию 11.9.0 от apt, python 3.7.5.

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

Интересно, могут ли разработчики прокомментировать осуществимость такого подхода.

Я заметил, что на самом деле быстрее удалить среду и воссоздать ее с нуля для обновления файла блокировки.
Это верно как для запуска pipenv lock и для pipenv install some-package

Мне очень нравится pipenv но не так сильно, как мне нравится пропускная способность и время. Итак, я решил проблему, используя:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

Удачи разработчикам ...

@ravexina спасибо за предложение, обязательно попробую