Pipenv: Команда `pipenv install XYZ` иногда зависает на неопределенный срок в разделе «Блокировка зависимостей [пакетов]».

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

@uranusjr Пожалуйста, найдите прилагаемый отчет с информацией об оборудовании.
hardinfo_report.txt

Это происходит постоянно? Попробуйте pipenv lock —verbose —clear

@techalchemy , я запустил pipenv lock --verbose --clear , и результаты аналогичны:

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

                          ROUND 1                           
Current constraints:

Finding the best candidates:

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

Locking [packages] dependencies…

Он оставался зависшим на «Блокировка зависимостей [пакетов]».

Удачно воспроизвести это на вашей машине? В частности, с тензорным потоком это происходит каждый раз для меня.

РЕДАКТИРОВАТЬ: я проверил это на компьютере друга. Он работает под управлением Ubuntu 17.10, и у него не было проблем. Оба компьютера находятся в одной сети. Одно из различий между его компьютером и моим заключается в том, что он установил только pipenv, а не pipenv и virtualenvwrapper. Я запущу виртуальную машину, чтобы посмотреть, связано ли это каким-то образом с virtualenvwrapper и/или заданными мной переменными среды, которые являются общими для обоих (например, $WORKON_HOME).

В настоящее время я вижу ту же проблему; мой вывод pipenv lock --verbose --clear выглядит точно так же, как @MarenstainBear . Я использую Ubuntu и использую pyenv для управления virtualenvs.

hardinfo_report.txt

Я вижу, вы установили Pipenv против системного Python. У вас случайно не установлен pyopenssl (или что-то еще, связанное с SSL, честно говоря, я не помню, это часть requests[security] ) в той же среде? Известно, что это делает операции чрезвычайно медленными.

Я установил requests[security] и pyopenssl внутри virtualenv, просто чтобы убедиться, но он все еще висит. Продолжая отладку, я обнаружил, что он зависает внутри venv_resolve_deps во второй раз, особенно в строке 376, c = delegator.run(cmd, block=True) .

Что еще более странно, так это то, что если я запускаю эту команду напрямую ( python resolver.py ) из командной строки, она работает отлично.

Да, похоже, что да, но только для моего python 2, а не для python 3 (и мой экземпляр pipenv был установлен через версию pip для python 2):

mary<strong i="6">@marvel</strong>:~$ /usr/bin/python2.7 -m pip freeze | grep -i ssl
pyOpenSSL==17.5.0
mary<strong i="7">@marvel</strong>:~$ /usr/bin/python3 -m pip freeze | grep -i ssl
mary<strong i="8">@marvel</strong>:~$ 

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

EDIT: удалено несколько абзацев о другой проблеме, которую я видел. Это была моя ошибка - на самом деле я был в подкаталоге, но не осознавал этого, потому что без моей обычной конфигурации zsh, отключенной для целей тестирования, у меня больше не было визуального индикатора в моем приглашении моего cwd. Как правильно заметил @uranusjr , «но Pipenv много определяет среду и, как известно, странно работает в неправильно настроенной оболочке». ... Я действительно на мгновение неправильно настроил свою оболочку.

@uranusjr
РЕДАКТИРОВАТЬ 2: я проверил это на виртуальной машине с настройкой, довольно похожей на мою хост-машину (включая установку pipenv в среде python 2.7.12, содержащей модуль pyOpenSSL), и на этой машине все работает отлично, как и ожидалось. Это заставляет меня сомневаться, что проблема здесь в pyOpenSSL. (Я заметил, что версия pipenv выше на моей виртуальной машине, поэтому я думаю, что обновлю pipenv локально, чтобы увидеть, имеет ли это значение.)

Версия Pipenv: '11.9.0'

Местоположение Pipenv: '/home/mary/.local/lib/python2.7/site-packages/pipenv'

Местоположение Python: '/usr/bin/python'

Другие установки Python в PATH :

• 2.7 : /usr/bin/python2.7
• 2.7 : /usr/bin/python2.7
• 3.5 : /usr/bin/python3.5m

• 3.5 : /usr/bin/python3.5

• 2.7.12 : /usr/bin/python

• 2.7.12 : /usr/bin/python2
• 3.5.2 : /usr/bin/python3

Информация о PEP 508:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.13.0-36-generic',
 'platform_system': 'Linux',
 'platform_version': '#40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018',
 'python_full_version': '2.7.12',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

Переменные системной среды:

• XDG_GREETER_DATA_DIR
• GNOME_DESKTOP_SESSION_ID
• PYTHONDONTWRITEBYTECODE
• LESSOPEN
• XDG_SESSION_TYPE
• QT_IM_MODULE
• LOGNAME
• USER
• PROMPT_COMMAND
• HOME
• XDG_VTNR
• PATH
• PYTHONUNBUFFERED
• DISPLAY
• SSH_AGENT_PID
• LANG
• TERM
• SHELL
• XDG_SESSION_PATH
• QT_STYLE_OVERRIDE
• LANGUAGE
• SESSION_MANAGER
• SHLVL
• QT_LINUX_ACCESSIBILITY_ALWAYS_ON
• GTK_CSD
• QT_ACCESSIBILITY
• XMODIFIERS
• GIO_LAUNCHED_DESKTOP_FILE_PID
• XDG_SESSION_DESKTOP
• GIO_LAUNCHED_DESKTOP_FILE
• XDG_RUNTIME_DIR
• SSH_AUTH_SOCK
• VTE_VERSION
• GDMSESSION
• XDG_SEAT_PATH
• LESSCLOSE
• GSETTINGS_SCHEMA_DIR
• XDG_CURRENT_DESKTOP
• XDG_SESSION_ID
• DBUS_SESSION_BUS_ADDRESS
• _
• XAUTHORITY
• DESKTOP_SESSION
• XDG_CONFIG_DIRS
• GTK_MODULES
• GDM_LANG
• PANTHEON_TERMINAL_ID
• XDG_DATA_DIRS
• PWD
• PIP_PYTHON_PATH
• XDG_MENU_PREFIX
• LS_COLORS
• XDG_SEAT

Переменные окружения Pipenv:

Переменные среды, специфичные для отладки:

• PATH : /home/mary/bin:/home/mary/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
• SHELL : /bin/bash
• LANG : en_US.UTF-8
• PWD : /home/mary

@MarenstainBear В какой Python вы устанавливаете Pipenv? Или вы устанавливаете Pipenv на другом Python или внутри virtualenv? (Не ваш проект, а сам Pipenv.)

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

@roddds resolver.py принимает зависимости, которые он хочет разрешить, как переменную среды. Без установки $PIPENV_PACKAGES перед его запуском он просто разрешал бы пустой список — молниеносно, как и должно быть, потому что нечего разрешать.

Попробуйте сначала установить PIPENV_PACKAGES (формат аналогичен requirements.txt ) и посмотрите, что произойдет.

+1 Я вижу ту же проблему, пытаясь установить numpy на MacOS. Подтверждено, что я не вижу этой проблемы при установке boto3.

% uname -a
Darwin f45c898a1d21.ant.amazon.com 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64

@uranusjr вот что я получаю при проверке PIPENV_PACKAGES с тем же значением, которое было установлено внутри venv_resolve_deps :

 $ PIPENV_PACKAGES=='django -i https://pypi.python.org/simple\ngraphene -i https://pypi.python.org/simple\ngraphene-django -i https://pypi.python.org/ простой\npsycopg2 -i https://pypi.python.org/simple\npsycopg2-binary -i https://pypi.python.org/simple\nipython -i https://pypi.python.org/simple\ndjango -manifold==0.1.6 -i https://pypi.python.org/simple\nscipy -i https://pypi.python.org/simple\npython-dateutil -i https://pypi.python.org /simple\ndjango-extensions -i https://pypi.python.org/simple' python /home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv /resolver.py

 Traceback (последний последний вызов):
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", строка 92, в __init__
 req = ТРЕБОВАНИЕ.parseString(requirement_string)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1617, в parseString
 поднять отл.
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1607, в parseString
 loc, токены = self._parse(instring, 0)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1379, в _parseNoCache
 loc,tokens = self.parseImpl(instring, preloc, doActions)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 3376, в parseImpl
 loc, exprtokens = e._parse(instring, loc, doActions)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1379, в _parseNoCache
 loc,tokens = self.parseImpl(instring, preloc, doActions)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 3698, в parseImpl
 вернуть self.expr._parse(instring, loc, doActions, callPreParse=False)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1379, в _parseNoCache
 loc,tokens = self.parseImpl(instring, preloc, doActions)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 3359, в parseImpl
 loc, resultlist = self.exprs[0]._parse(instring, loc, doActions, callPreParse=False)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 1383, в _parseNoCache
 loc,tokens = self.parseImpl(instring, preloc, doActions)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", строка 2670, в parseImpl
 поднять ParseException (instring, loc, self.errmsg, self)
 pip9._vendor.pyparsing.ParseException: ожидается W:(abcd...) (в символе 0), (строка:1, столбец:1)

 Во время обработки вышеупомянутого исключения произошло другое исключение:

 Traceback (последний последний вызов):
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", строка 82, в __init__
 требуется = требование (требуется)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", строка 96, в __init__
 требование_строка[e.loc:e.loc + 8]))
 pip9._vendor.packaging.requirements.InvalidRequirement: недопустимое требование, ошибка синтаксического анализа в "'=django'"

 Во время обработки вышеупомянутого исключения произошло другое исключение:

 Traceback (последний последний вызов):
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", строка 83, в
 главный()
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", строка 71, в основном
 очистить = сделать_очистить,
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/resolver.py", строка 63, в разрешении
 многословный = многословный,
 Файл "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", строка 426, в resolve_deps
 до,
 Файл "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", строка 294, в fact_resolve_reps
 c для c в req.parse_requirements(t, session=pip_requests)
 Файл "/home/rodrigo/.pyenv/versions/val/lib/python3.6/site-packages/pipenv/utils.py", строка 294, в
 c для c в req.parse_requirements(t, session=pip_requests)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", строка 93, в parse_requirements
 для запроса в req_iter:
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", строка 158, в process_line
 изолированный=изолированный, options=req_options, wheel_cache=wheel_cache
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", строка 235, в from_line
 wheel_cache=wheel_cache, ограничение=ограничение)
 Файл "/home/rodrigo/.pyenv/versions/3.6.4/envs/val/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", строка 91, в __init__
 "Недопустимое требование: '%s'\n%s" % (req, add_msg))
 pip9.exceptions.InstallationError: Недопустимое требование: '= django'
 = не является допустимым оператором. Вы имели в виду == ?

 [[источник]]
 URL-адрес = "https://pypi.python.org/simple"
 Verify_SSL = Истина
 имя = "пипи"

 [пакеты]
 Джанго = "*"
 графен = "*"
 графен-джанго = "*"
 "псикопг2" = "*"
 "psycopg2-двоичный" = "*"
 ипитонов = "*"
 Джанго-многообразие = "== 0.1.6"
 scipy = "*"
 Python-dateutil = "*"
 Джанго-расширения = "*"

 [dev-пакеты]

 [требует]
 версия_python = "3.6"

@roddds У вас есть лишние = в окружении. Это

$ PIPENV_PACKAGES='django -i [too long, snipped]

Но у тебя было

$ PIPENV_PACKAGES=='django ...

Второй = объединился с django после него, что привело к синтаксической ошибке, которую вы видели.

Я думал, что вижу ту же проблему при новой установке Mac (macOS 10.12, Homebrew Python 3), и обнаружил несколько проблем, связанных здесь.

Это мощная машина, у меня хороший доступ в Интернет — не знаю, почему это занимает так много времени, но в итоге файл блокировки был записан примерно через три минуты.

То же самое. Каждый раз, когда я запускаю pipenv install xxx , это занимает очень много времени (2-3 минуты) сразу после того, как он печатает Locking [packages] dependencies…

Блокировка просто занимает много времени, ребята. Из-за управления зависимостями Python мы должны загрузить каждый пакет и запустить setup.py , чтобы получить зависимости по мере необходимости. Для таких библиотек, как tensorflow и numpy, вы можете получить sdist, что означает, что вы строите из исходного кода. Это медленно. Я видел, что это занимает 10 минут. Это происходит быстрее, если вы нагреваете кеш.

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

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

Мы рассматриваем способы улучшения этого процесса

Я бы предложил напечатать сообщение, информирующее пользователя о том, что $something выполняется, что может «занять несколько минут». Прямо сейчас кажется, что процесс зависает, что, я думаю, заставляет людей отправлять отчеты об ошибках или +1 по этим (не-) проблемам.

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

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

@ Виктор-Саву, как я уже говорил. компиляция чего-то вроде numpy или tensorflow.

@techalchemy Мой процесс, насколько я могу судить, на самом деле зависает. Я оставил его на пять часов, прежде чем убить. Глядя на top , я не увидел никаких признаков того, что что-то действительно обрабатывается. Напротив, когда я устанавливаю tensorflow в свою виртуальную среду с помощью pip вместо pipenv, это занимает всего несколько секунд.

Как вы можете видеть на этом снимке моего терминала, моей системе потребовалось 12,25 секунды, чтобы запустить новую виртуальную среду python3 и использовать pip для установки tensorflow с помощью команды /usr/bin/time -v pipenv run pip install tensorflow .

Если вместо этого я запускаю команду /usr/bin/time -v pipenv install tensorflow , процесс кажется зависшим на неопределенный срок в «Блокировка зависимостей [пакетов] ...» после того, как установка уже прошла успешно.

На этом изображении видно, что примерно через 59 секунд активных действий подпроцесс, связанный с resolver.py, перестает активно использовать системные ресурсы и, насколько я могу судить, никогда не завершится. Когда я сделал этот снимок экрана, процесс выполнялся уже 16 минут.

@MarenstainBear Pipenv порождает подпроцесс внутри virtualenv для выполнения блокировки. Не могли бы вы проверить, работает ли подпроцесс (virtualenv python , работающий с pipenv/resolver.py , когда Pipenv застрял? Мне интересно, застрял ли он внутри распознавателя, после возврата распознавателя или во время delegator.run …

(еще в идеале вы можете попытаться выяснить, достигает ли преобразователь своего конца)

@uranusjr Я вставил несколько операторов записи в код resolver.py и, похоже, завис где-то в вызове pipenv.utils.resolve_deps в этой строке .

Другими словами, resolver.py не достигает своего конца.

@MarenstainBear Это приятно (?) слышать, по крайней мере, это означает, что это можно отладить. Как далеко ему удалось проникнуть внутрь resolve_deps ? Это довольно длинная функция…

Да и как долго он работал? Для меня это по-прежнему звучит так же, как я сказал раньше — разрешение медленного графа зависимостей.

@techalchemy @uranusjr В эти выходные я собираюсь разобраться, что происходит с функцией resolve_deps. А пока вот результаты процесса, который я начал вчера. Через 24 часа он не разрешился и действительно не использовал системные ресурсы, поэтому я думаю, что он не пытался разрешить зависимости, а просто зависал. (Я убил процесс, чтобы увидеть вывод команды time .)

Команда завершилась с ненулевым статусом 1
Время выполнения команды: «pipenv install tensorflow»
Время пользователя (секунды): 13,63
Системное время (секунды): 1,99
Процент ЦП, полученный этой работой: 0%
Прошедшее (настенные часы) время (ч:мм:сс или м:сс): 25:45:02
Средний размер общего текста (кбайт): 0
Средний размер нераспределенных данных (кбайт): 0
Средний размер стека (кбайт): 0
Средний общий размер (кбайт): 0
Максимальный размер резидентного набора (кбайт): 297772
Средний размер резидентного набора (кбайт): 0
Основные (требующие ввода-вывода) ошибки страницы: 0
Незначительные (восстановление кадра) ошибки страницы: 467309
Произвольные переключения контекста: 15781
Непроизвольные переключения контекста: 207
Свопы: 0
Входы файловой системы: 0
Выходы файловой системы: 1654976
Отправлено сообщений через сокет: 0
Получено сообщений через сокет: 0
Доставлено сигналов: 0
Размер страницы (байт): 4096
Статус выхода: 1

@techalchemy , что значит «нагреть кеш»?

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

@techalchemy Я установил с мастера при фиксации 8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d (от 31 марта 01:13:26 2018 -0400). Моя проблема была _не_ решена. В версии 11.9.1 я видел то же поведение, что и в 11.9.0.

Я кратко попробовал другой способ отладки этой проблемы, используя strace. Команда strace pipenv install tensorflow зависла на poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) . Когда я искал эти файловые дескрипторы, не было ничего интересного, кроме подтверждения того, что система ожидает ввода-вывода.

mary<strong i="10">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428937     
pipenv     8474                  mary    5r     FIFO               0,12       0t0    1428937 pipe
sh         8543                  mary    1w     FIFO               0,12       0t0    1428937 pipe
python     8544                  mary    1w     FIFO               0,12       0t0    1428937 pipe

mary<strong i="11">@marvel</strong>:/proc/8471/fd
> lsof -n -P | grep 1428938
pipenv     8474                  mary    7r     FIFO               0,12       0t0    1428938 pipe
sh         8543                  mary    2w     FIFO               0,12       0t0    1428938 pipe
python     8544                  mary    2w     FIFO               0,12       0t0    1428938 pipe

Примечание. Было бы очень полезно, если бы мы могли каким-то образом передавать вывод из
преобразователь, а не блокировать до тех пор, пока преобразователь не вернется (просто чтобы сделать его
проще использовать подробные сведения для отладки, где происходит зависание)
Вс, 1 апреля 2018 г., 17:21
написал:

Я установил с мастера при фиксации 8a67a21
https://github.com/pypa/pipenv/commit/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d
(от 31 марта 01:13:26 2018 -04:00). Моя проблема не была решена. я
видел то же поведение в версии 11.9.1, что и в 11.9.0.

Я кратко попробовал другой способ отладки этой проблемы, используя strace. То
команда strace pipenv install tensorflow зависла при опросе([{fd=5,
события=ОПРОС}, {fd=7, события=ОПРОС}], 2, -1). Когда я посмотрел эти
файловых дескрипторов, не было ничего интересного, кроме
подтверждение того, что система ожидает ввода/вывода.

mary@marvel :/proc/8471/fd

lsof -n -P | группа 1428937
pipenv 8474 mary 5r FIFO 0,12 0t0 1428937 труба
ш 8543 мэр 1w FIFO 0,12 0t0 1428937 труба
python 8544 mary 1w FIFO 0,12 0t0 1428937 труба

mary@marvel :/proc/8471/fd

lsof -n -P | группа 1428938
pipenv 8474 mary 7r FIFO 0,12 0t0 1428938 труба
ш 8543 мэри 2w FIFO 0,12 0t0 1428938 труба
python 8544 mary 2w FIFO 0,12 0t0 1428938 труба

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

У меня такая же проблема. Раньше он зависал на неопределенный срок, но в прошлый раз почему-то закончился исключением. Может быть, это поможет. (Версия 11.9.0)

❯ pipenv install Pipfile.lock not found, creating… Locking [dev-packages] dependencies… Locking [packages] dependencies… y", line 63, in resolve verbose=verbose, File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 494, in resolve_deps list(resolver.resolve_hashes([result]).items())[0][1] File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in resolve_hashes return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 72, in <dictcomp> return {ireq: self.repository.get_hashes(ireq) for ireq in ireqs} File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in get_hashes for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 276, in <setcomp> for candidate in matching_candidates File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in _get_file_hash for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 282, in <lambda> for chunk in iter(lambda: fp.read(8096), b""): File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 324, in read flush_decoder = True File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/requests/packages/urllib3/response.py", line 237, in _error_catcher raise ReadTimeoutError(self._pool, None, 'Read timed out.') pip9._vendor.requests.packages.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='pypi.python.org', port=443): Read timed out.

@MarenstainBear Спасибо, что вы прикладываете столько усилий для решения этой проблемы.

После того, как установка текущей версии пакета tensorflow-gpu много раз не удалась описанным способом, мне удалось завершить его установку, закрепив его на версии 1.5.

pipenv install tensorflow-gpu==1.5

Несмотря на то, что это не объясняет сбои установки NumPy и других пакетов, это может иметь какое-то отношение к тому факту, что начиная с версии 1.6 двоичные файлы tensorflow используют инструкции AVX. В любом случае, версия 1.5 устанавливается очень быстро и прекрасно работает.

@paraschas Я попробовал ваш совет, и, к сожалению, он не сработал. Но спасибо, что подсказали! :-)

@MarenstainBear это может быть легко связано с утечкой файловых дескрипторов pipenv где-то по цепочке, а затем ожиданием их ... Во время установки мы обычно разветвляем кучу подпроцессов для обработки одновременных загрузок и тому подобного. Что произойдет, если вы используете pipenv install --sequential ? Спасибо, что были с нами, не стесняйтесь заходить на наш слабый канал (ссылка: https://pyslackers.com/ => зарегистрируйтесь и присоединяйтесь к #pipenv), если вы хотите публиковать больше вещей в режиме реального времени.

@techalchemy Из того, что я могу сказать, когда он зависает, он никогда не выходит из этого блока try:
@ techhttps://github.com/pypa/pipenv/blob/8a67a21d61a2383253fe0dd5e7a8d79d51d30d2d/pipenv/utils.py#L491 -L494

Этот код вызывает обратный вызов в resolver.py, поэтому я посмотрю, что там происходит в методе resolve_hashes() .

PS - Я присоединился к слабому каналу. Спасибо за приглашение!

Я столкнулся с той же проблемой здесь. Питон 3.6.4, пипенв 11.9.0.
Он не зависает, если я устанавливаю с помощью --skip-lock .

@techalchemy @uranusjr

Я смог использовать ipdb, чтобы значительно сузить круг моей проблемы...

Из исходного кода pypi.py здесь , если я добавлю две строки, как показано ниже, то мой pipenv больше не будет сломан .

1. Первая строка alt_session = PipSession() создает ванильный объект PipSession.
2. А вторая строка self.session.adapters["https://"] = alt_session.adapters["https://"] захватывает адаптер https из этого ванильного сеанса и перезаписывает адаптер https PyPIRepository. Это означает, что вместо pip9._vendor.cachecontrol.adapter.CacheControlAdapter используется pip9._vendor.requests.adapters.HTTPAdapter .

def _get_file_hash(self, location):
    h = hashlib.new(FAVORITE_HASH)
    alt_session = PipSession()
    self.session.adapters["https://"] = alt_session.adapters["https://"]
    with open_local_or_remote_file(location, self.session) as fp:
        for chunk in iter(lambda: fp.read(8096), b""):
            h.update(chunk)
    return ":".join([FAVORITE_HASH, h.hexdigest()])

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

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

@uranusjr На самом деле все наоборот. Исходный код использует кешированный адаптер — кешированный адаптер — это тот, который у меня НЕ работает. Обычный HTTP-адаптер работает, когда я его использую.

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

Возможно, я не знаю (внутренний пип очень сложный). кеш pip по умолчанию равен ~/.cache/pip , но, возможно, есть и другие кеши. Я честно не знаю.

@uranusjr @techalchemy @jtratner

Святые ведра, Бэтмен! Это сработало!

mary<strong i="10">@marvel</strong>:~
> sudo rm ~/.cache/pip* -rf
[sudo] password for mary: 

mary<strong i="11">@marvel</strong>:~
> mktmpenv 
Using base prefix '/usr'
New python executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python3
Also creating executable in /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/preactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/postactivate
virtualenvwrapper.user_scripts creating /home/mary/Development/.virtualenvs/tmp-60224356c1829db/bin/get_env_details
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-60224356c1829db) 
mary<strong i="12">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> pipenv install protobuf
Creating a Pipfile for this project…
Installing protobuf…
Collecting protobuf
  Downloading protobuf-3.5.2.post1-cp35-cp35m-manylinux1_x86_64.whl (6.4MB)
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf)
Collecting six>=1.9 (from protobuf)
  Downloading six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf
Successfully installed protobuf-3.5.2.post1 six-1.11.0

Adding protobuf to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (735738)!
Installing dependencies from Pipfile.lock (735738)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 2/2 — 00:00:00
(tmp-60224356c1829db) 
mary<strong i="13">@marvel</strong>:~/Development/.virtualenvs/tmp-60224356c1829db
> 

Давайте посмотрим, работает ли это решение для некоторых других людей, сообщающих о той же проблеме.
@roddds @jlhood @roveo @claytonaalves Если вы все еще можете воспроизвести зависание pipenv на неопределенное время в «Заблокировать... [пакеты] зависимости», попробуйте очистить кеш pip (и pipenv?) в ~/.cache/.pip и сообщить об этом. назад о том, решило ли это проблему с зависанием pipenv. :-)

Итак, ваша подсказка говорит @marvel , но вы цитируете Робина… хм 😏

лол ... так что очистка вашего кеша пипсов исправила это ... жизнь забавна ...

Я столкнулся с той же проблемой с последними версиями Python, pip и pipenv при установке маятника, и, к сожалению, очистка кеша pip и pipenv с помощью команды `sudo rm ~/.cache/pip* -rf' не решает проблему.

Так что проблема, по крайней мере для меня, все еще актуальна.

@paraschas , вы можете дать нам pipfile и вывод python -m pipenv.help

Содержимое Pipfile:

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

[packages]
pandas = "*"
"h5py" = "*"
Keras = "*"
tensorflow-gpu = "==1.5"
sklearn = "*"
pendulum = "*"

[dev-packages]

[requires] = "3.6"

И вывод python -m pipenv.help прилагается:

pipenv.help.txt

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

Можете ли вы запустить pipenv-resolver —debug pendulum

Вот он, не уверен, почему он терпит неудачу:

pipenv-resolver_pendulum.txt

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

Я скопировал команду, которую теперь вижу, включает тире вместо двух дефисов.

Теперь я запустил pipenv-resolver --debug pendulum , который работает правильно и дает следующие результаты:
pipenv-resolver_pendulum.txt

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

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

Мне удалось установить маятник с помощью pipenv, но пропустить генерацию файла блокировки. Через день и при новой загрузке он также правильно сгенерировал файл блокировки, а версия маятника - «== 1.5.1».

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

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

У меня была такая же проблема при установке pandas. Поскольку у меня были проблемы с pandas и последней версией pip, я решил понизить версию pip до 9.0.3, и проблема с pipenv также была решена.
Проверьте эту проблему для справки: https://github.com/pandas-dev/pandas/issues/20666

pipenv установить скрап
висит более 10 минут

питон --версия
3.6.5
пип --версия
10.0.1

кот пипфайл

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

[packages]
scrapy = "*"

[dev-packages]

[requires]
python_version = "3.6"

Я была такая же проблема. Вот где она у меня висела:

$ pipenv lock -vv
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…

$ pipenv-resolver --debug requests
DEBUG:pip9.vcs:Registered VCS backend: git
DEBUG:pip9.vcs:Registered VCS backend: hg
DEBUG:pip9.vcs:Registered VCS backend: svn
DEBUG:pip9.vcs:Registered VCS backend: bzr
DEBUG:notpip.index:2 location(s) to search for versions of requests:
DEBUG:notpip.index:* https://pypi.python.org/simple/requests/
DEBUG:notpip.index:* https://pypi.boughtbymany.com/5c0a44cd-ec93-412c-b3a9-c3dfb72c22ee/requests/
DEBUG:notpip.index:Getting page https://pypi.python.org/simple/requests/
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.python.org/simple/requests/" in the cache
DEBUG:pip9._vendor.cachecontrol.controller:Returning cached "301 Moved Permanently" response (ignoring date and etag information)
DEBUG:pip9._vendor.cachecontrol.controller:Looking up "https://pypi.org/simple/requests/" in the cache
WARNING:pip9._vendor.cachecontrol.controller:Cache entry deserialization failed, entry ignored
DEBUG:pip9._vendor.urllib3.connectionpool:Starting new HTTPS connection (1): pypi.org
DEBUG:pip9._vendor.urllib3.connectionpool:https://pypi.org:443 "GET /simple/requests/ HTTP/1.1" 200 16346
DEBUG:pip9._vendor.cachecontrol.controller:Updating cache with response from "https://pypi.org/simple/requests/"
DEBUG:pip9._vendor.cachecontrol.controller:Caching due to etag

Проблема заключалась в том, что pip пытался что-то записать в свой кеш. Я смог решить эту проблему, очистив кеш пипсов, который для пользователей Mac составляет rm -rf ~/Library/Caches/pip .

Спасибо всем участникам этого выпуска!

У меня тоже сработала очистка кеша pip ! Большое спасибо @MarenstainBear @uranusjr @techalchemy @jtratner за вашу работу!

Здесь то же самое, pip env висит на Mac OS. Я пытался создать простой pipenv install flask в новой папке только для тестирования. Он завис, но я заметил, что он использует не каталог кеша pip, а свой собственный:

Building wheels for collected packages: itsdangerous, MarkupSafe
  Running setup.py bdist_wheel for itsdangerous: started
  Running setup.py bdist_wheel for itsdangerous: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/2c/4a/61/5599631c1554768c6290b08c02c72d7317910374ca602ff1e5
  Running setup.py bdist_wheel for MarkupSafe: started
  Running setup.py bdist_wheel for MarkupSafe: finished with status 'done'
  Stored in directory: /Users/renzo/Library/Caches/pipenv/wheels/33/56/20/ebe49a5c612fffe1c5a632146b16596f9e64676768661e4e46

Итак, что сработало для меня, было

rm -rf ~/Library/Caches/pipenv

Действительно странное поведение. Обнаружено такое поведение после обновления Python с 3.6.3 до 3.7.0.

pipenv --clear сделает это за вас

Ошибка: нет такой опции: --clear

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

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

@techalchemy
Он определенно еще не выпущен, так как у меня последняя версия 2018.7.1 и у меня нет опции --clear.

Для этой конкретной проблемы pipenv lock --clear должно быть достаточно.

pipenv lock --clear работает. Спасибо!

по-прежнему НЕ работает на меня за pipenv lock --clear

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

Надеюсь исправить это зависание Locking [packages] dependencies... навсегда как можно скорее

@crifan Я обнаружил, что pipenv lock --clear не работает из-за ошибки (https://github.com/pypa/pipenv/issues/2628).

Попробуйте вручную очистить кеши - я использую rm -r ~/Library/Caches/pip* .

Происходит в этом Dockerfile на основе alpine linux (дочерний элемент):

FROM frolvlad/alpine-python3

RUN pip install pipenv

COPY ./app /app
COPY Pipfile /app/
WORKDIR /app

RUN pipenv install

С этим пипфайлом:

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

[dev-packages]

[packages]
numpy = "*"
pandas = "*"
tensorflow = "*"
flask = "*"

[requires]
python_version = "3.6"

~/devel/dopper:fixes: pipenv lock --clear --verbose
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

висит навсегда.

Пипфайл:

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

[packages]
proto = {editable = true, path = "."}
halt = {editable = true, path = "/home/carlos/devel/halt"}
gcd = {editable = true, path = "/home/carlos/devel/gcd"}

[dev-packages]

[requires]
python_version = "3.6"

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

Это простые проекты зависимостей, которые я могу легко установить вручную, запустив pip install -e . на каждом из них, но запуск pipenv install -e . в основном проекте зависает на неопределенный срок, поэтому я обнаружил эту проблему и попробовал pipenv lock --clear который тоже висит. Я понимаю, что без дополнительной информации мало что можно сделать, но, по крайней мере, это свидетельствует о том, что вещи, которые работали по-старому, зависают с pipenv и что предлагаемое решение работает не везде. Извините, я не могу предоставить больше информации. Возможно, если бы режим --verbose действительно был здесь многословным.

Может быть, это могло бы пролить свет:

~/devel/dopper:fixes: pipenv --rm
Removing virtualenv (/home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s)...
~/devel/dopper:fixes: rm -rf Pipfile 
~/devel/dopper:fixes: pipenv --three
Creating a virtualenv for this project...
Pipfile: /home/carlos/devel/dopper/Pipfile
Using /usr/bin/python3 (3.6.6) to create virtualenv...
⠋Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python3
Also creating executable in /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s/bin/python
Installing setuptools, pip, wheel...done.
Setting project for dopper-0v9QQl0s to /home/carlos/devel/dopper

Virtualenv location: /home/carlos/.local/share/virtualenvs/dopper-0v9QQl0s
Creating a Pipfile for this project...
~/devel/dopper:fixes: pipenv install numpy
Installing numpy...
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Ожидание навсегда ...

Предположим, это проблема с сетью, почему тогда это работает? :

~:: pip install --force --upgrade --user numpy
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/88/29/f4c845648ed23264e986cdc5fbab5f8eace1be5e62144ef69ccc7189461d/numpy-1.15.0-cp36-cp36m-manylinux1_x86_64.whl (13.9MB)
    100% |████████████████████████████████| 13.9MB 386kB/s 
Installing collected packages: numpy
  Found existing installation: numpy 1.15.0
    Uninstalling numpy-1.15.0:
      Successfully uninstalled numpy-1.15.0
Successfully installed numpy-1.15.0

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

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

Хорошо, если вы считаете, что невозможность установить numpy в чистой среде — это
случайная проблема, я знаю, что рискую при использовании pipenv, спасибо за
головы вверх, и я заткну рот.

В среду, 25 июля 2018 г., в 18:27, Дэн Райан, [email protected] написал:

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

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pipenv/issues/1816#issuecomment-407901419 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACtq-WfYHCgtRnbIu_yljQV7m0JvwxA7ks5uKOKqgaJpZM4S0kt-
.

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

Пока что мы знаем:

1. Ничего о вашем окружении
2. Ничего о каких-либо дополнительных обстоятельствах, связанных с вашей системой.
3. Преувеличенное утверждение, что вы «ждали вечность», но без дополнительной информации о том, делал ли процесс что-либо, существовала ли среда с чем-либо в ней, какую версию pipenv вы используете, происходит ли это с вещами, кроме numpy, как вы установили python, на что похоже ваше оборудование, какова конфигурация вашей системы, я мог бы продолжить.

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

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

Я действительно не хочу продолжать эту дискуссию из-за того, что другие люди подписались на ветку, я отвечу на этот, а затем вы скажете последнее высказывание, если хотите. Я опубликовал несколько анекдотических свидетельств, я сразу понял, что это не более чем это, и попытался устранить наиболее условные аспекты, установив локальные зависимости другими способами и проверив, что с ними нет проблем, и, наконец, полностью удалив все зависимости, запустив env с нуля и установив просто numpy. Эти шаги (создание env и установка numpy) воспроизводимы, мне искренне жаль, что я не могу предоставить вам более полезную информацию, потому что я сам не могу найти какой-либо шаблон, как я заметил при перечислении моих попыток (и я не могу прикрепите iso всей моей установки). Таким образом, в конце концов, я предложил связь с рядом проблем, слишком похожих, о которых сообщалось и которые были закрыты, тем самым признав, что мое первое впечатление было ошибочным. Я понимаю, что воспроизводимый лучше, но я даже не могу опубликовать подробный вывод, потому что команда просто показывает тот минимальный вывод, который я (выборочно или случайным образом или что-то еще) опубликовал. Вначале я думал, что моя проблема может быть связана с этой проблемой, и после моих безуспешных попыток найти какую-то закономерность теперь я склонен полагать, что это связано со «слишком медленной блокировкой». Причина, по которой я не создал новую проблему, заключается в том, что многие из них закрыты по той же причине, по которой вы наверняка закрыли бы мою, если бы я ее опубликовал. Теперь, я думаю, это важная проблема, я не могу последовательно установить популярный пакет в основном стандартной настройке, дело не в том, что шрифт эмодзи змеи не работает на моем новом эмуляторе хипстерского терминала, и, хотя я понимаю вашу позицию , Я не могу отделаться от ощущения, что вы были слишком суровы. Тем не менее, я очень ценю ваше подробное объяснение после моего последнего гневного комментария. Между прочим, заявление о том, что я «ждал вечность», помимо того, что это фигура речи, действительно было смягчено мной, иронизируя, определив вечность как предел моего терпения, но я все же предоставил информацию о том, что она превышает несколько минут. ; поскольку мы говорим о чем-то, что должно было занять самое большее несколько секунд здесь, единственное значение моей неточности состоит в том, что вы истолковали это как ранний симптом моих злых намерений, которых не было с самого начала. Мои извинения всем остальным здесь, по крайней мере, всем, у кого хватило терпения дочитать до этого момента.

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