Pipenv: Обновление блокировки происходит очень медленно

Мы знаем, и у нас много проблем с отслеживанием этой темы. См. # 1785 # 1886 # 1891 и PR # 1896

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

Перехожу к рассмотрению других вопросов.

То же самое здесь я пробую прямо сейчас, и установка django уже через 10 минут и идет

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

Если вы можете предоставить Pipfile, который воспроизводит медленное поведение, это было бы полезно - спасибо

Зависимости Python требуют от нас полностью загрузить и выполнить установочные файлы каждого пакета для разрешения и вычисления

Это все еще так, когда у пакета есть собственный Pipfile.lock , или pipenv будет использовать его, когда это возможно, для определения зависимостей?

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

Нет. Pipenv - это инструмент для разрешения зависимостей приложений. Когда зависимость используется как пакет Python другим приложением, она больше не является приложением. Его зависимости определяются файлом setup.py (или setup.cfg, или любым другим способом, который вы используете для загрузки в PyPI). Загрузка зависимостей из файла блокировки - верный путь в ад зависимостей, мы, скорее всего, никогда этого не сделаем.

Это все еще очень медленно

@iddan Спасибо за напоминание, капитан очевидный!

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

Примечание @techalchemy из --skip-lock выше замечательно. Это должен быть более доступный или публичный вариант. Можем ли мы установить его где-нибудь по умолчанию?

@techalchemy что, если это займет 20 минут с моим новым Mac Pro?

Примечание @techalchemy из --skip-lock выше замечательно. Это должен быть более доступный или публичный вариант. Можем ли мы установить его где-нибудь по умолчанию?

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

Тем не менее, я думаю, вы также можете понять возможность, которую имеет pipenv, направлять благонамеренных разработчиков в сообществе Python в целом к ​​рабочему процессу, который меньше ломает голову будущим участникам - которые могли бы быть только посетителями, если бы отказались от них во время " выяснить, как настроить этап "среды разработки"; и меньше рук, брошенных будущими сопровождающими - которые, возможно, были бы только фанатичными авторами по связям с общественностью, если бы они отказались от них на этапе «серьезной ласки с глубокими внутренностями проекта».

Если бы --skip-lock стал постоянным флагом в Pipfile или настройкой в ​​конфигурации pipenv, восприятие pipenv медленно соскользнуло бы в сторону "лучшего pip", и просто еще одна ступенька исчезла на горизонте, когда сообщество в конечном итоге приземлилось менее компромиссный духовный преемник.

Лучше оставить его доступным только как env var или какой-либо другой метод, приложение которого лежит прямо на территории _ "ваша локальная конфигурация пользователя, ваша ошибка" _, что позволяет pipenv преодолеть фазу прохождения медленной генерации файла блокировки без отказа действительно полезный культурный сдвиг в сторону явности вместо неявности в управлении пакетами.

Невероятно обширная стандартная библиотека Python - это огромный актив, история которого претерпела множество эпох внушительной последовательности. То, что большинство стандартных пакетов прекрасно сочетаются друг с другом, - это огромный подвиг, над которым многие люди думают в течение многих лет. Когда-нибудь эта возможность играть приятно будет распространяться на большинство проектов Python, встречающихся в сети - далеко-далеко от stdlib и с гораздо, гораздо меньшим количеством требуемых PEP (_и гораздо, гораздо меньше BDFL освобождаются из-за разочарования_). Воздействие таких односторонне маслянистый опыт трудно измерить, но некоторые нынешние язык _did_ отбросов к компромиссу концептуальной целостности для немедленного удобства ... и, местами они будут Go .

Итак, _да_, создание файла блокировки происходит медленно, и _да_, это неприятно, когда вам нужно всего лишь pip install --save . Но это только потому, что мы годами загоняли слона в шкаф - полагая, что у нас нет запутанного беспорядка ожиданий и намерений из-за внешних зависимостей, потому что _ "он отлично установлен на моей машине" _.

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

Я был бы последним, кто посоветовал бы вам сегодня не делать pipenv удобным для себя (в противном случае я был бы дерьмовым разработчиком - хотя жюри все еще отсутствует), но я умоляю вас увидеть растущее разочарование, связанное с генерацией файлов блокировки. боль, в то время как сообщество Python превращается в сильное, здоровое тело с более полноценно функционирующими конечностями, чем можно было ожидать при снятии гипсовой повязки. Мы добрались до Python 3. Давайте перейдем к управлению зависимостями в stdlib.

На создание файла блокировки на моей машине потребовалось 38 минут. Запуск Windows 10 и использование Python 3.7

Только numpy и подушка были уже установлены, и потребовалось <1 секунды, чтобы установить numba, и 25 минут, чтобы заблокировать его. Компилирует ли pipenv принудительно каждую библиотеку при блокировке или как это работает?

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

TL; DR; Типичный вызов pipenv install : Время : 144,82 реальное 33,68 пользовательское 5,77 sys. С --skip-lock : Time : 4.54 real 5.33 user 0.87 sys.

Установка Pandas-datareader завершается неудачно с первой попытки, возможно, из- lock зависания

Используется версия 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

Содержимое requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

Типичный вызов pipenv install . Выполнение по времени с использованием time (BSD).

Результат : 144,82 реальный 33,68 пользователь 5,77 sys

$ time pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Pipfile.lock (0fdb67) out of date, updating to (a65489)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (0fdb67)!
Installing dependencies from Pipfile.lock (0fdb67)…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 15/15 — 00:00:04
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
      144.82 real        33.68 user         5.77 sys

Вызов w \ --skip-lock

Результат : 4,54 реальный 5,33 пользователь 0,87 sys

$ time pipenv install -r requirements.txt --skip-lock
Requirements file provided! Importing into Pipfile…
Installing dependencies from Pipfile…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
        4.54 real         5.33 user         0.87 sys

Я думаю, что https://github.com/pandas-dev/pandas/ может быть проблемой? Для меня это тоже общая черта со временем.

Хотя pytest тоже может быть проблемой: \

Это даже не закончится на моей машине:

Installing pandas…
Adding pandas to Pipfile's [packages]…
Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 109, in expect_loop
    return self.timeout()
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x00000292ADCCCDD8>
searcher: searcher_re:
    0: re.compile('\n')

@ black-snow Я бы порекомендовал попробовать его в другой оболочке. Не вдаваясь в подробности, кажется, что pexpect (библиотека для программного взаимодействия с интерактивными программами CLI) используется для обнаружения оболочки, из которой выполняется pipenv, и это может тормозить. pexpect кажется излишним для такой вещи, но я не знаю всего контекста.

@ theY4Kman спасибо за совет. pipenv отлично работает на другом компьютере с той же версией ubuntu и bash ...

Прочтите это, ожидая блокировки pipfile ... :) Было бы здорово, если бы было решение.

Похоже, нам нужен какой-то API для анализа и кеширования пакетов Python и их распространения в удобном для машины формате. Таким образом, нам больше не нужно будет загружать целые пакеты и анализировать их.

Я считаю, что Bundler и Ruby Gems поддерживают и используют что-то подобное.

В Java также есть файлы POM (XML), которые содержат зависимости пакетов и другую информацию о пакете. Они загружаются отдельно от скомпилированных JAR-файлов.

Каждый новый менеджер пакетов имеет несколько отдельных мета-файлов (npm / yarn, composer, gradle / maven, cargo, ruby ​​gems / bundler, ...).

связанный вопрос:
https://github.com/pypa/warehouse/issues/474

Вы можете получить информацию о зависимостях из PyPi, не загружая весь пакет (см. PEP 566, который заменил PEP 426).

package_name = 'Django'
PYPI_API_URL = 'https://pypi.python.org/pypi/{package_name}/json'
package_details_url = PYPI_API_URL.format(package_name=package_name)
response = requests.get(package_details_url)
data = json.loads(response.content)
data['info'].get('requires_dist')
data['info'].get('requires')
data['info'].get('setup_requires')
data['info'].get('test_requires')
data['info'].get('install_requires')

@techalchemy вы видели комментарий выше?

Это происходит довольно часто, по сути, pipenv уезжает по городу, «запирая» что-то: почему эта проблема закрыта?

Поймите, что --skip-lock - это правильный путь, но совершенно непонятно, почему «установка» занимает несколько секунд, а «блокировка» - вечность: было бы здорово, если бы хотя бы команда блокировки показала некоторый прогресс. / update logs: как дела, даже не ясно, застрял ли он в какой-то while True навсегда ...

По крайней мере, мне хотелось бы знать, что я делаю не так, или это просто «особенность» pipenv.

В нашем проекте pipenv lock такой медленный. Это определенно повлияло на наше обычное использование. Добавление нового пакета становится для нас настоящей головной болью. Есть ли способ отладить это поведение?

Я пытаюсь установить PyTorch, блокировка заняла 20 минут, а затем выдает следующую ошибку

Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1992, in do_install
[pipenv.exceptions.InstallError]:       skip_lock=skip_lock,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Collecting pytorch==1.0.2 (from -r /tmp/pipenv-pb00kf8t-requirements/pipenv-vae35p2d-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ee/67/f403d4ae6e9cd74b546ee88cccdb29b8415a9c1b3d80aebeb20c9ea91d96/pytorch-1.0.2.tar.gz', 'Building wheels for collected packages: pytorch', '  Building wheel for pytorch (setup.py): started', "  Building wheel for pytorch (setup.py): finished with status 'error'", '  Running setup.py clean for pytorch', 'Failed to build pytorch', 'Installing collected packages: pytorch', '  Running setup.py install for pytorch: started', "    Running setup.py install for pytorch: finished with status 'error'"]
[pipenv.exceptions.InstallError]: ['ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' bdist_wheel -d /tmp/pip-wheel-f_h8w1pz --python-tag cp36:', '  ERROR: Traceback (most recent call last):', '    File "<string>", line 1, in <module>', '    File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 15, in <module>', '      raise Exception(message)', '  Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '  ----------------------------------------', '  ERROR: Failed building wheel for pytorch', '    ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch:', '    ERROR: Traceback (most recent call last):', '      File "<string>", line 1, in <module>', '      File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 11, in <module>', '        raise Exception(message)', '    Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '    ----------------------------------------', 'ERROR: Command "/home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch" failed with error code 1 in /tmp/pip-install-hix3yz6v/pytorch/']
ERROR: ERROR: Package installation failed...

Ошибка unreadle, понятия не имею, что пошло не так. Установка с помощью pip в среде работает нормально! Это действительно шоу-пробка. Возвращаемся к requirements.txt ...

Это обходной путь, который я использую сейчас:

export PIPENV_SKIP_LOCK=true

Тогда pipenv install foo не будет блокироваться, и вы можете заблокировать его вручную, когда у вас будет время, запустив pipenv lock .

@awhillas Совершенно уверен, что последняя строка говорит все, что вам нужно:

Вы пробовали установить "пыторч". Пакет, названный для PyTorch, называется "torch".

Блокировка зависимостей важна, поэтому я не думаю, что «пропустить блокировку» можно надолго. В то же время я просто не верю, что «зависимости блокировки» (что бы это ни могло повлечь за собой) максимально оптимизированы, как сейчас, и функционально требуют много минут или часов для завершения. Действительно, моя блокировка pipenv в течение нескольких минут выполнялась в файле Pipfile, который имеет смехотворные 5 зависимостей, прежде чем потерпел неудачу - стек прикреплен снизу - и за это время использовал только 10–15% доступного ЦП и небольшой глоток памяти.

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

pipenv version 2018.11.26

Для Pipfile:

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

[packages]

[dev-packages]
keras = "*"
tensorflow = "~=1.13"
setuptools = "*"
wheel = "*"
twine = "*"

[requires]
python_version = ">=3.6"

Pipfile.lock (63b275) out of date, updating to (5e165c)…
Locking [dev-packages] dependencies…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 109, in expect_loop
    return self.timeout()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.26', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/cli/command.py", line 254, in install
    editable_packages=state.installstate.editables,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1992, in do_install
    skip_lock=skip_lock,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1221, in do_init
    pypi_mirror=pypi_mirror,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1068, in do_lock
    lockfile=lockfile
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps
    c = resolve(cmd, sp)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 517, in resolve
    result = c.expect(u"\n", timeout=environments.PIPENV_INSTALL_TIMEOUT)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/delegator.py", line 215, in expect
    self.subprocess.expect(pattern=pattern, timeout=timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 341, in expect
    timeout, searchwindowsize, async_)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 369, in expect_list
    return exp.expect_loop(timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 119, in expect_loop
    return self.timeout(e)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

В качестве дополнения к предыдущему комментарию, запуск pip lock отдельности занял разумное количество времени, ~ 15 секунд, после первого запуска pip install --skip-lock . Так что, возможно, вызов блокировки после установки устарел или ошибочен. :)

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

Tensorflow - один из многих пакетов, из-за которых pipenv может стать бесполезным инструментом. Однако мне нравится предложение о групповом профилировании. Я думаю, что это отличная идея, чтобы начать решать эту проблему. Чтобы повторить итерацию, PEP 566 включил перечисление зависимости (через pypi) без загрузки всего источника, что может быть полезно: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

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

Как это проверить:

• Попробуйте создать новый Pipfile и установить в нем scipy (например) с включенной блокировкой
• Дождитесь завершения блокировки. (На моей машине занимает около 5 минут)
• удалить Pipfile.lock
• запустите pipenv lock - теперь блокировка займет очень мало времени (6 секунд на моей машине), потому что все пакеты уже загружены и хранятся в кеше Pipenv, который обычно находится в ~/.cache/pipenv

Вот Dockerfile, который я использовал для проверки:

FROM python:3.6
ENV WORKDIR=/work/
WORKDIR /work/
RUN python3 -m pip install --upgrade pip
RUN python3 -m pip install pipenv
RUN PIPENV_SKIP_LOCK=true pipenv install scipy
RUN date
RUN pipenv lock
RUN date
RUN rm Pipfile.lock
RUN pipenv lock
RUN date

@shtratos Да, это имеет смысл, и другие предположили, что в этой ветке выпуска. Скачивание и анализ зависимостей обходится дорого. Кажется, что некоторые из этих шагов могут быть устранены путем извлечения из API зависимостей pypi.

Для некоторых библиотек это, вероятно, не сработает из-за низкого качества и неправильной практики (без использования setup.py или requirements.txt). Но поскольку некоторые из основных нарушителей кажутся очень популярными библиотеками (tensorflow, numpy), реализация этого с откатом к сверхмедленному процессу может быть хорошим шагом вперед.

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

Я думаю, что https://github.com/pandas-dev/pandas/ может быть проблемой? Для меня это тоже общая черта со временем.

Хотя pytest тоже может быть проблемой: \

Я так не думаю, он отлично работает на моей машине, проблема кажется более общей, чем эта

В моем случае проблема, похоже, в pylint. Он всегда зависает при блокировке при простом запуске pipenv install pylint см. Https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

У меня одна и та же проблема во всех моих проектах.
Причина вроде бы в пилинте.
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...

Мы знаем, и у нас много проблем с отслеживанием этой темы. См. # 1785 # 1886 # 1891 и PR # 1896

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

Перехожу к рассмотрению других вопросов.

3 из 4 других проблем в настоящее время закрыты, а в отношении оставшейся проблемы с 2018 года не было никаких действий. Эта проблема все еще сохраняется, так что, может быть, ее повторное открытие было бы хорошей идеей?

Зависимости Python требуют от нас полностью загрузить и выполнить установочные файлы каждого пакета для разрешения и вычисления

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

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

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

FWIW Я удалил pipenv из всех своих проектов (это одна из основных причин, есть и другие).

virtualenv + pip (с requirements.txt ) теперь работают довольно хорошо, даже для развертываний Prod; и в любом случае в наши дни развертывается полностью сформированный контейнер; после того, как я действительно погрузился в pipenv, я больше не вижу в этом смысла.

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