Pip: Каждая команда из pip выполняется очень медленно

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

Нет, я не делал никаких обновлений. Windows 10 делает частые обновления, но я не могу понять, как это влияет на производительность с помощью pip внутри WSL2.

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

Не могли бы вы рассказать, сколько пакетов уже установлено (т.е. результат pip list )? Это могло быть связано с внутренней логикой pip [1], которая пыталась просмотреть все установленные пакеты перед любой обработкой вывода.

[1] Конструкция WorkingSet pkg_resources при загрузке, для тех, кому интересно, о чем я говорю

Та же проблема и со мной. Я выполнил команду pip3 list и мне потребовалось около 10+ секунд, чтобы вывести список пакетов. На данный момент я создаю виртуальную среду, используя pipenv что устраняет проблему. Я думаю, что это может мешать совместному использованию исполняемых файлов между wsl2 linux и Windows. Но я не уверен, в чем проблема!

Я думаю, что это может мешать совместному использованию исполняемых файлов между wsl2 linux и windows

Это звучит правдоподобно. Производительность файловой системы WSL2 ужасна, если вы обращаетесь к файловой системе Windows со стороны Linux. Какой Python связан с вашей командой pip3 ? Можете ли вы предоставить свои sys.path ? Произойдет ли это, если вы запустите pip3 в другом месте? Имеет ли значение, находится ли это место в файловой системе Linux или на стороне Windows?

Если мы запустим тот же pip3 list на Windows PowerShell, это произойдет мгновенно, и проблемы не возникнет.

Системный путь без активированной среды pipenv

['', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/<user>/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages']

Системный путь с активированной средой pipenv

['', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/<user>/.local/share/virtualenvs/myproj-SiazyaGz/lib/python3.8/site-packages']

Это может быть возможно, если sys-путь будет изменен на глобальный, тогда pip3 не будет мешать работе Windows One. Я не пробовал!

Хм, ни один из каталогов не кажется необычным. Вы случайно монтируете какие-нибудь каталоги Windows? Например, вы создаете символическую ссылку на свой домашний каталог (или что-нибудь, указанное в sys.path ) с каталогом Windows? Или вы запускаете команду в каталоге под /mnt ?

Я бы, вероятно, попытался временно переместить некоторые записи, перечисленные в sys.path (особенно ~/.local/lib one), и посмотреть, изменится ли что-нибудь. Или, может быть, вы можете просто вставить несколько профилировщиков в среду выполнения Python и посмотреть, что именно замедляет работу. Есть много уловок, которые помогут изолировать проблему. Это было бы намного полезнее, чем мне (или кому-либо, кто не имеет физического доступа к вашей машине), пытаясь устранить неполадки в разреженном воздухе.

Изменить: это может как-то быть связано с дисплеем? Замедление в значительной степени уходит (занимает 0,5 секунды), когда я запускаю сервер X11 (с использованием MobaXterm). Причина, по которой я обнаружил эту проблему, заключалась в том, что matplotlib был очень медленным, поэтому я попытался использовать pip для переустановки. Я забыл, что мне нужно запустить Xterm, чтобы использовать matplotlib.

Я также столкнулся с этой проблемой и получаю тот же результат от моего python sys.path что и piyushchauhan2011. У меня есть символическая ссылка в моем домашнем каталоге на каталог Windows, например
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Я разрабатываю пакет python, результаты которого нужно сравнить с программой, которая может работать только в среде unix. Я использую возвышенный тест для редактирования файлов в моем каталоге Windows и использую WSL2 для запуска кода тестирования этих файлов через символическую ссылку.

Я могу запустить следующие команды без замедления: check, show, config
Я использую pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Запуск pip3 list действительно возвращает результат, но занимает ~ 30 секунд.
У меня установлено около 100 пакетов.

Я безуспешно пробовал следующее
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
Я попытался запустить pip как внутри файловой системы WSL2, так и на стороне Windows, каждый из которых страдает одинаковым замедлением.

Я не на 100%, как лучше всего изменить sys.path , но вот моя попытка:
Я запустил ipython3, который начинается с sys.path :

'/usr/bin',
 '/usr/lib/python38.zip',
 '/usr/lib/python3.8',
 '/usr/lib/python3.8/lib-dynload',
 '',
 '/home/<user>/.local/lib/python3.8/site-packages',
 '/usr/local/lib/python3.8/dist-packages',
 '/usr/lib/python3/dist-packages',
 '/usr/lib/python3/dist-packages/IPython/extensions',
 '/home/<user>/.ipython']

Что я делаю резервную копию следующим образом backup = sys.path.copy()
На этом этапе я подтвердил, что если я использую run '/usr/bin/pip3' list я все равно столкнусь с замедлением.
Однако, когда после этого я устанавливаю sys.path = [] и снова запускаю, я получаю ModuleNotFoundError: No module named 'pyparsing' . Этот результат повторяется каждый раз, когда я снова бегаю. НО! Как только я установил sys.path = backup теперь run '/usr/bin/pip3' list чудесным образом работает!
Результат использования time :

CPU times: user 12.2 ms, sys: 426 µs, total: 12.6 ms
Wall time: 11.8 ms

Итак, очевидно, что с путями что-то не так.
После этого я снова могу установить sys.path =[] и run '/usr/bin/pip3' list по какой-то причине все еще работает.

Я не уверен, что это актуально, но я подумал, что упомянул бы об этом:
После использования команды run мой sys.path заполняется следующим образом (после установки в пустой список)

['/usr/share/python-wheels/idna-2.8-py2.py3-none-any.whl',
 '/usr/share/python-wheels/distlib-0.3.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/msgpack-0.6.2-py2.py3-none-any.whl',
 '/usr/share/python-wheels/lockfile-0.12.2-py2.py3-none-any.whl',
 '/usr/share/python-wheels/pytoml-0.1.21-py2.py3-none-any.whl',
 '/usr/share/python-wheels/retrying-1.3.3-py2.py3-none-any.whl',
 '/usr/share/python-wheels/requests-2.22.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/setuptools-44.0.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl',
 '/usr/share/python-wheels/chardet-3.0.4-py2.py3-none-any.whl',
 '/usr/share/python-wheels/webencodings-0.5.1-py2.py3-none-any.whl',
 '/usr/share/python-wheels/CacheControl-0.12.6-py2.py3-none-any.whl',
 '/usr/share/python-wheels/ipaddr-2.2.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/certifi-2019.11.28-py2.py3-none-any.whl',
 '/usr/share/python-wheels/urllib3-1.25.8-py2.py3-none-any.whl',
 '/usr/share/python-wheels/wheel-0.34.2-py2.py3-none-any.whl',
 '/usr/share/python-wheels/appdirs-1.4.3-py2.py3-none-any.whl',
 '/usr/share/python-wheels/packaging-20.3-py2.py3-none-any.whl',
 '/usr/share/python-wheels/html5lib-1.0.1-py2.py3-none-any.whl',
 '/usr/share/python-wheels/six-1.14.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/pip-20.0.2-py2.py3-none-any.whl',
 '/usr/share/python-wheels/colorama-0.4.3-py2.py3-none-any.whl',
 '/usr/share/python-wheels/progress-1.5-py2.py3-none-any.whl',
 '/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/pyparsing-2.4.6-py2.py3-none-any.whl',
 '/usr/share/python-wheels/contextlib2-0.6.0-py2.py3-none-any.whl',
 '/usr/share/python-wheels/distro-1.4.0-py2.py3-none-any.whl',
 '/usr/bin',
 '/usr/lib/python38.zip',
 '/usr/lib/python3.8',
 '/usr/lib/python3.8/lib-dynload',
 '',
 '/home/<user>/.local/lib/python3.8/site-packages',
 '/usr/local/lib/python3.8/dist-packages',
 '/usr/lib/python3/dist-packages',
 '/usr/lib/python3/dist-packages/IPython/extensions',
 '/home/<user>/.ipython']

Что по-прежнему страдает замедлением, пока sys.path не будет установлен в пустой список, а затем не вернется к исходному списку или этому списку.

Может это как-то связано с дисплеем? Замедление в значительной степени уходит (занимает 0,5 секунды), когда я запускаю сервер X11 (с использованием MobaXterm). Причина, по которой я обнаружил эту проблему, заключалась в том, что matplotlib был очень медленным, поэтому я попытался использовать pip для переустановки. Я забыл, что мне нужно запустить Xterm, чтобы использовать matplotlib.

Может быть…? Для меня этот вопрос очень странный. Если это проблема sys.path , не произойдет ли такое же замедление для всего импорта Python, а не только для pip? Я в тупике 😞

Здравствуйте, моя среда:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

С Python 3.6.9 и pip 9.0.1 и я могу подтвердить, что pip очень медленный с каждым command (особенно с install )

Мои pip3 list - это

asn1crypto (0.24.0)
attrs (17.4.0)
Automat (0.6.0)
chardet (3.0.4)
configobj (5.0.6)
constantly (15.1.0)
cryptography (2.1.4)
distro-info (0.18ubuntu0.18.04.1)
hyperlink (17.3.1)
idna (2.6)
incremental (16.10.1)
keyring (10.6.0)
keyrings.alt (3.0)
netifaces (0.10.4)
pip (9.0.1)
pyasn1 (0.4.2)
pyasn1-modules (0.2.1)
pycrypto (2.6.1)
pygobject (3.26.1)
pyOpenSSL (17.5.0)
python-apt (1.6.5+ubuntu0.3)
python-debian (0.1.32)
pyxdg (0.25)
PyYAML (3.12)
SecretStorage (2.3.1)
service-identity (16.0.0)
setuptools (39.0.1)
six (1.11.0)
Twisted (17.9.0)
ufw (0.36)
unattended-upgrades (0.1)
wheel (0.30.0)

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

@ngraymon это странно, но я попробую это временное исправление.
Благодаря!
Я обновлю эту проблему, как только попробую.

Просто чтобы подтвердить, что поведение остается прежним, я только что проверил:

Запуск time pip3 list внутри терминала Windows на WSL2:

После запуска MobaXterm и запуска time pip3 list в том же терминале:

@ngraymon Привет,
Я решил проблему, попробуйте выполнить следующие действия:

• Не запускайте команды pip с помощью sudo
• апт-обновление && апт-апгрейд
• Перезагрузите сервер / компьютер
• Сосредоточьтесь на докере, вчера вечером я заметил, что процесс python3 интенсивно используется роем.

@MattiaFailla
Я рад, что вы решили свою проблему.
Я попробовал ваши предложения, но это не помогло.
Я не запускаю pip с sudo, но я установил pip3 с помощью sudo apt install python3-pip , может быть, это актуально?
Я доволен тем, как обстоят дела у меня самого, поскольку мне в любом случае нужен X-сервер, поскольку я рисую с использованием matplotlib.

@ngraymon, не могли бы вы запустить python -m pip и посмотреть, медленно ли это?

Если это так, и у вас достаточно новая версия Python, предоставьте нам результат python -X importtime -m pip -v . Если замедлится импорт, это поможет нам узнать.

@pradyunsg
Здравствуйте,

Я запустил time python3 -m pip без какой-либо команды для pip, которая в это время отвечает сообщением справки

Однако, если я запустил time python3 -m pip list

Запуск time python3 -m pip check который не влияет / все еще не влияет замедление

Я выполнил следующее:

• python3 -X importtime -m pip -v и прикрепил это как out_1.txt

• python3 -X importtime -m pip -v list и прикрепил его как out_list.txt

• python3 -X importtime -m pip -v check и прикрепил его как out_check.txt

Похоже, виновником команды list является keyring.core ?
import time: 96023197 | 96029594 | keyring.core

Надеюсь, это поможет :)

Похоже, виновником команды list является keyring.core?

В сочетании со странной вещью, связанной с поддержкой X-сервера, мне интересно, зависит ли связка ключей от графического интерфейса, и есть ли там какой-то код, который пытается найти X и вызывает задержку, пока не решит, что его нет?

@pfmoore
Судя по их странице на pypi, кажется, что для этого требуется либо D-Bus, либо сервер X11?

Я попробовал python3 -m keyring --disable и export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring но, похоже, проблема не решилась.

jaraco / keyring # 434 кажется связанным, но совет по отключению указывает на документы, в которых указано, что вы уже пробовали.

У вас тоже возникла эта проблема, думаю, она началась после вчерашнего запуска подпрограммы sudo apt-get update && sudo apt-get upgrade . Это определенно как-то связано с связкой ключей и дисплеем. В дополнение к исправлению работы X-сервера я смог решить проблему, удалив строку, которая была в моем файле .bashrc, указывающая на IP-адрес WSL2. Речь идет о следующей строке:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

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

Похоже, что я смог навсегда решить проблему, обновив связку ключей с помощью pip3 install -U keyring и убедившись, что
[backend]
default-keyring=keyring.backends.null.Keyring
установлен в файле конфигурации связки ключей в ~/.config/python_keyring/keyringrc.cfg

Замечательно, предложение cjpellicci о pip3 install -U keyring сработало.
Мне также пришлось переместить ~/.local/share/python_keyring/keyringrc.cfg в ~/.config/share/python_keyring/keyringrc.cfg .
Запуск pip3 list теперь занимает 1/2 секунды вместо 90 секунд.
Это без запущенного X-сервера.

Вышесказанное, похоже, не работает для меня. Keyringrc.cfg отсутствует ни в ~ / .local / share / python_keyring /, ни в ~ / .config / share / python_keyring /.

Может ли это быть разным поведением между WSL Ubuntu и Ubuntu?

@peidaqi , после обновления ~/.config/python_keyring/ , а затем добавить в файл конфигурации следующее:
[backend]
default-keyring=keyring.backends.null.Keyring

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

Кстати: я тоже использую Ubuntu на WSL2.

Здравствуйте! Я столкнулся с более или менее той же проблемой: pip list работает медленно (~ 1 мин), включая любую команду pip install я пытался запустить (на wsl2). Однако я не уверен, было ли поведение точно таким же (список pip _did_ выводит пакеты, но команда вернется через ~ 1 мин).

В конечном итоге моя проблема была решена следующим образом: https://askubuntu.com/a/38468/938540 - я не уверен, что проблемы связаны, но симптомы были очень похожи. Надеюсь это поможет!

Добавление еще одной возможной точки данных:
pip list заняло около 90 секунд под WSL2.
Я устанавливал переменную среды DISPLAY на X-сервер, работающий под рабочим столом Windows. Очистка переменной среды DISPLAY или запуск моего X-сервера изменили время на 0,343 с.

Похоже, что я смог навсегда решить проблему, обновив связку ключей с помощью pip3 install -U keyring и убедившись, что
[backend]
default-keyring=keyring.backends.null.Keyring
установлен в файле конфигурации связки ключей в ~/.config/python_keyring/keyringrc.cfg

Это подходит для меня.

Ubuntu 18.04
Python 3.6.9
пункт 20.0.2

Похоже, что я смог навсегда решить проблему, обновив связку ключей с помощью pip3 install -U keyring и убедившись, что
[backend]
default-keyring=keyring.backends.null.Keyring
установлен в файле конфигурации связки ключей в ~/.config/python_keyring/keyringrc.cfg

Это подходит для меня.

Ubuntu 18.04
Python 3.6.9
пункт 20.0.2

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

Ubuntu 18.04
Python 3.6.8
пункт 20.2.3

Привет, ребята, нам не нужны дополнительные отчеты, подтверждающие, что отключение связки ключей ускорит работу пользователей. Мы были бы признательны, если бы кто-нибудь обратился за помощью с https://github.com/pypa/pip/issues/8719. :)

Это происходит у меня, когда я бегаю в Wayland на Fedora 33! Надеюсь, что это полезное дополнение даже в качестве моего комментария, поскольку все остальные, похоже, находятся на WSL.

Окружающая обстановка

• pip 20.2.2 из /usr/lib/python3.9/site-packages/pip (python 3.9)
• Python 3.9.0
• ОС: Fedora 33
• окружение рабочего стола: swaywm (Wayland tiling wm), запускается через gdm

выполнение по времени pip и pip list :

pip  0.11s user 0.01s system 99% cpu 0.122 total
pip list  0.24s user 0.03s system 1% cpu 25.285 total

$ python -m pip uninstall jrnl
^CTraceback (most recent call last):
  File "/usr/lib64/python3.9/site-packages/dbus/bus.py", line 177, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib64/python3.9/site-packages/dbus/bus.py", line 361, in get_name_owner
    return self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/usr/lib64/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: The name does not have an owner

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib64/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.9/site-packages/pip/__main__.py", line 26, in <module>
    sys.exit(_main())
  File "/usr/lib/python3.9/site-packages/pip/_internal/cli/main.py", line 73, in main
    command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
  File "/usr/lib/python3.9/site-packages/pip/_internal/commands/__init__.py", line 104, in create_command
    module = importlib.import_module(module_path)
  File "/usr/lib64/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/lib/python3.9/site-packages/pip/_internal/commands/uninstall.py", line 6, in <module>
    from pip._internal.cli.req_command import SessionCommandMixin
  File "/usr/lib/python3.9/site-packages/pip/_internal/cli/req_command.py", line 20, in <module>
    from pip._internal.network.session import PipSession
  File "/usr/lib/python3.9/site-packages/pip/_internal/network/session.py", line 26, in <module>
    from pip._internal.network.auth import MultiDomainBasicAuth
  File "/usr/lib/python3.9/site-packages/pip/_internal/network/auth.py", line 34, in <module>
    import keyring  # noqa
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/__init__.py", line 1, in <module>
    from .core import (
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/core.py", line 186, in <module>
    init_backend()
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/core.py", line 90, in init_backend
    filter(limit, backend.get_all_keyring()),
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/util/__init__.py", line 22, in wrapper
    func.always_returns = func(*args, **kwargs)
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/backend.py", line 214, in get_all_keyring
    return list(rings)
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/util/__init__.py", line 33, in suppress_exceptions
    for callable in callables:
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/util/properties.py", line 26, in __get__
    return self.fget.__get__(None, owner)()
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/backend.py", line 68, in viable
    cls.priority
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/util/properties.py", line 26, in __get__
    return self.fget.__get__(None, owner)()
  File "/home/daboross/.local/lib/python3.9/site-packages/keyring/backends/kwallet.py", line 50, in priority
    bus.get_object(cls.bus_name, cls.object_path)
  File "/usr/lib64/python3.9/site-packages/dbus/bus.py", line 241, in get_object
    return self.ProxyObjectClass(self, bus_name, object_path,
  File "/usr/lib64/python3.9/site-packages/dbus/proxies.py", line 250, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib64/python3.9/site-packages/dbus/bus.py", line 182, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib64/python3.9/site-packages/dbus/bus.py", line 277, in start_service_by_name
    return (True, self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/usr/lib64/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
  File "/usr/lib64/python3.9/site-packages/dbus/exceptions.py", line 47, in __init__
    def __init__(self, *args, **kwargs):
KeyboardInterrupt

Спасибо за отчеты. Теперь ясно, что это происходит из-за интеграции связки ключей pip. # 8687 значительно снизит вероятность того, что pip будет искать информацию в связке ключей, а # 8719 сделает это подпиской.

К сведению людей, импорт модуля связки ключей во что-либо может привести к длительным остановкам в нужной среде, независимо от того, вызывает ли код функции связки ключей явно или нет. Это можно увидеть по времени импорта: time python3 -c "import keyring" . Для меня это занимает около 25 секунд на машине Fedora 32, на которой я удаленно вошел в систему и на которой нет графического сеанса входа в систему.

Для меня прямая причина этого в том, что связка ключей запускает код при импорте, который в конечном итоге пытается установить соединение DBus с org.kde.kwalletd5, и это очень медленно терпит неудачу. Вы можете продублировать основной код (и воспроизвести стойло) с помощью:

>>> import dbus
>>> from dbus.mainloop.glib import DBusGMainLoop
>>> bus = dbus.SessionBus(mainloop=DBusGMainLoop())
>>> bus.get_object('org.kde.kwalletd5', '/modules/kwalletd5')

В самом связке ключей этот код находится в keyring / backends / kwallet.py, в методе priority() . Если kwalletd еще не запущен и не может быть запущен, это, по-видимому, требует длительного тайм-аута внутри самой DBus или библиотек Python DBus.

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

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

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

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

FWIW, обходной путь для пользователей, которые сталкиваются с этим, - это отключение связки ключей, как описано здесь: https://github.com/jaraco/keyring#dispting -keyring

Это было поднято как ошибка? я

Да: https://github.com/jaraco/keyring/issues/403