Pip: Cada comando do pip é executado muito lento

O que você está se referindo por “costumava”? Essa desaceleração acontece por causa de uma atualização de pip ou de sistema? Se acontecer do nada, muito provavelmente não é um problema de pip, mas algo acontecendo em sua máquina particular, sobre o qual o pip não tem controle.

Não, eu não fiz nenhuma atualização de pip. O Windows 10 faz atualizações frequentes, mas não consigo entender como isso afeta o desempenho com pip dentro do WSL2.

Espero que alguém possa me indicar como posso rastrear esse problema. No momento, o pip não exibe nenhuma mensagem de erro, portanto não há como saber o que está acontecendo.

Você poderia compartilhar quantos pacotes já estão instalados (ou seja, a saída de pip list )? Pode estar relacionado à lógica interna do pip [1] que tentou examinar todos os pacotes instalados antes de qualquer processamento de saída.

[1] Construção do WorkingSet de pkg_resources no carregamento, para aqueles que estão se perguntando do que estou falando

O mesmo problema comigo também. Executei o comando pip3 list e levou cerca de 10+ segundos para listar os pacotes. Por enquanto eu crio um ambiente virtual usando pipenv que remove o problema. Eu acho que pode estar interferindo no compartilhamento de executáveis ​​entre wsl2 linux e windows. Não tenho certeza de qual é a origem do problema!

Acho que pode estar interferindo no compartilhamento de executáveis ​​entre wsl2 linux e windows

Isso parece plausível. O desempenho do sistema de arquivos WSL2 é terrível se você acessar o sistema de arquivos do Windows no lado do Linux. Qual é o Python associado ao seu comando pip3 ? Você pode fornecer seu sys.path ? Isso acontece se você executar pip3 em um local diferente? Faz diferença se o local está no sistema de arquivos Linux ou no lado do Windows?

Se executarmos o mesmo pip3 list no windows powershell, será instantâneo e o problema não acontecerá.

Caminho Sys sem ambiente pipenv ativado

['', '/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']

Caminho Sys com ambiente pipenv ativado

['', '/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']

Pode ser possível se o caminho sys for alterado para global, então pip3 não interferirá no Windows um. Eu não experimentei!

Hmm, nenhum dos diretórios parece fora do comum. Você monta algum dos diretórios do Windows? Por exemplo, você vincula simbolicamente seu diretório inicial (ou qualquer coisa listada em sys.path ) a um diretório do Windows? Ou você executa o comando em um diretório em /mnt ?

Eu provavelmente tentaria mover temporariamente algumas das entradas listadas em sys.path (especialmente ~/.local/lib one) e ver se isso muda alguma coisa. Ou talvez você possa apenas inserir alguns criadores de perfil no tempo de execução do Python e ver o que exatamente está tornando as coisas mais lentas. Existem muitos truques que você pode fazer para isolar o problema. Isso seria imensamente mais útil do que eu (ou qualquer pessoa sem acesso físico à sua máquina) tentando solucionar problemas no ar.

Edit: Isso pode de alguma forma estar vinculado ao display? A lentidão desaparece em grande parte (leva 0,5 segundos) quando eu inicio um servidor X11 (usando MobaXterm). O motivo pelo qual encontrei esse problema é que o matplotlib era muito lento, então tentei usar o pip para reinstalar. Esqueci que precisava rodar um Xterm para usar matplotlib.

Eu também encontrei esse problema e tenho a mesma saída de sys.path do meu python que piyushchauhan2011. Eu tenho um link simbólico em meu diretório inicial para um diretório do Windows como este
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Estou desenvolvendo um pacote python cujos resultados precisam ser comparados a um programa que só pode ser executado em um ambiente unix. Eu uso o teste sublime para editar os arquivos no meu diretório do Windows e uso o WSL2 para executar o código de benchmark nesses arquivos por meio do link simbólico.

Posso executar os seguintes comandos sem lentidão: check, show, config
Estou usando pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Executar pip3 list retorna um resultado, mas leva cerca de 30 segundos.
Tenho cerca de 100 pacotes instalados.

Eu tentei o seguinte sem sucesso
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
Eu tentei executar o pip dentro do sistema de arquivos WSL2 e no lado do Windows, cada um deles sofrendo a mesma lentidão.

Não sou 100% qual seria a melhor maneira de mudar o sys.path , mas aqui está a minha tentativa:
Eu lancei o ipython3 que começa com sys.path de:

'/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']

Que eu faço backup da seguinte maneira backup = sys.path.copy()
Neste ponto, confirmei que, se usar run '/usr/bin/pip3' list , ainda encontro lentidão.
No entanto, quando depois disso eu defino sys.path = [] e corro novamente, recebo ModuleNotFoundError: No module named 'pyparsing' . Este resultado se repete cada vez que corro novamente. MAS! Depois de definir sys.path = backup agora run '/usr/bin/pip3' list funciona milagrosamente!
A saída de usar time :

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

É claro que há algo errado com os caminhos.
Depois, posso definir sys.path =[] novamente e run '/usr/bin/pip3' list ainda funciona por algum motivo.

Não tenho certeza se isso é relevante, mas pensei em mencioná-lo:
Depois de usar o comando run meu sys.path é preenchido da seguinte forma (após ter sido definido como uma lista vazia)

['/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']

Que ainda sofre a desaceleração até que o sys.path seja definido como uma lista vazia e então redefinido de volta para a lista original ou esta lista.

Isso pode de alguma forma estar ligado ao display? A lentidão desaparece em grande parte (leva 0,5 segundos) quando eu inicio um servidor X11 (usando MobaXterm). O motivo pelo qual encontrei esse problema é que o matplotlib era muito lento, então tentei usar o pip para reinstalar. Esqueci que precisava rodar um Xterm para usar matplotlib.

Talvez…? Todo o problema é muito estranho para mim. Se este for um problema de sys.path , a mesma desaceleração não aconteceria para todas as importações Python, não apenas pip? Estou bastante perplexo 😞

Olá, meu ambiente é:

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

Com Python 3.6.9 e pip 9.0.1 e posso confirmar que o pip é extremamente lento a cada command (especialmente com install )

Meu 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 Se você quiser uma correção _temporária_, recomendo executar um servidor X11 como o MobaXterm (ou algum outro equivalente). Não entendo por que , mas corrigiu meu problema de lentidão para todos os comandos.

@ngraymon, isso é estranho, mas vou tentar essa correção temporária.
Obrigado!
Vou atualizar este problema assim que tentar.

Só para confirmar que o comportamento ainda é o mesmo que verifiquei agora:

Executando time pip3 list dentro de um Terminal Windows em WSL2:

Depois de iniciar o MobaXterm e executar time pip3 list no mesmo terminal:

@ngraymon Olá,
Resolvi o problema, tente os seguintes passos:

• Não execute comandos pip com sudo
• apt-update && apt-upgrade
• Reinicialize o servidor / computador
• Fique atento ao docker, ontem à noite percebi que o processo python3 estava sendo intensamente usado pelo enxame

@MattiaFailla
Estou feliz por você ter resolvido seu problema.
Tentei suas sugestões, mas não resolveu o problema.
Não executo o pip com o sudo, mas instalei o pip3 usando sudo apt install python3-pip , talvez isso seja relevante?
Estou feliz com a forma como as coisas são para mim, pois preciso de um servidor X de qualquer maneira, já que estou plotando usando matplotlib.

@ngraymon, você poderia executar python -m pip e ver se isso também fica lento?

Se for, e você tiver uma versão Python nova o suficiente, forneça-nos o resultado de python -X importtime -m pip -v . Se a desaceleração for nas importações, isso vai nos ajudar a saber.

@pradyunsg
Olá,

Eu executei time python3 -m pip sem qualquer comando para pip que responde com a mensagem de ajuda neste momento

No entanto, se eu executar time python3 -m pip list

Executando time python3 -m pip check que não foi / ainda não foi afetado pela desaceleração

Eu corri o seguinte:

• python3 -X importtime -m pip -v e anexado como out_1.txt

• python3 -X importtime -m pip -v list e anexado como out_list.txt

• python3 -X importtime -m pip -v check e anexado como out_check.txt

Parece que o culpado pelo comando list é keyring.core ?
import time: 96023197 | 96029594 | keyring.core

Espero que seja útil :)

Parece que o culpado pelo comando list é keyring.core?

Combinado com a coisa estranha de ter um servidor X ajudando, eu me pergunto se o chaveiro depende de uma GUI, e há algum código lá que tenta encontrar o X e causa um atraso até concluir que não há um?

@pfmoore
Com base em sua página em pypi , parece que ele requer D-Bus ou um servidor X11?

Tentei python3 -m keyring --disable e export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring mas nenhum dos dois resolveu o problema.

jaraco / keyring # 434 parece relacionado, mas o conselho sobre a desativação aponta para a documentação que afirma o que você já tentou.

Tendo este problema também, acredito que começou depois de executar uma rotina sudo apt-get update && sudo apt-get upgrade ontem. Ele está definitivamente relacionado ao chaveiro e à tela de alguma forma. Além da correção de ter um X-Server em execução, fui capaz de corrigir o problema removendo a linha que eu tinha no meu arquivo .bashrc apontando o visor para o endereço IP do WSL2. A linha em questão é:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

Depois de remover essa linha de .bashrc e reiniciar o WSL2, pip se comporta conforme o esperado. Não tenho certeza se isso aponta alguém na direção certa, pois não tenho certeza de como proceder a partir daqui.

Parece que consegui corrigir o problema permanentemente atualizando o chaveiro com pip3 install -U keyring e garantindo que
[backend]
default-keyring=keyring.backends.null.Keyring
está definido no arquivo de configuração do chaveiro em ~/.config/python_keyring/keyringrc.cfg

Maravilhoso, a sugestão de cjpellicci de pip3 install -U keyring resolveu o problema.
Eu também tive que mover ~/.local/share/python_keyring/keyringrc.cfg para ~/.config/share/python_keyring/keyringrc.cfg .
Executar pip3 list leva ½ segundo agora, em vez de 90 segundos.
Isso sem nenhum servidor X em execução.

O texto acima não parece funcionar para mim. Não há keyringrc.cfg em ~ / .local / share / python_keyring / ou ~ / .config / share / python_keyring /.

Isso poderia ser um comportamento diferente entre WSL Ubuntu e Ubuntu?

@peidaqi , depois de atualizar o chaveiro, você pode tentar criar o arquivo de configuração com esse nome exato no diretório ~/.config/python_keyring/ e adicionar o seguinte ao arquivo de configuração:
[backend]
default-keyring=keyring.backends.null.Keyring

Acredito que keyringrc.cfg pode ser feito após seguir os passos acima para desabilitar o chaveiro ao definir uma variável de ambiente, mas posso estar errado.

BTW: também estou executando o Ubuntu no WSL2.

Olá! Eu estava enfrentando mais ou menos o mesmo problema com pip list executando lentamente (~ 1 min) incluindo qualquer comando pip install eu estava tentando executar (no wsl2). No entanto, não tenho certeza se o comportamento foi exatamente o mesmo (pip list _did_ saída dos pacotes, mas o comando retornaria após cerca de 1 minuto).

O que finalmente resolveu meu problema foi o seguinte: https://askubuntu.com/a/38468/938540 - Não tenho certeza se os problemas estão relacionados, mas os sintomas eram muito semelhantes. Espero que isto ajude!

Adicionando outro ponto de dados possível:
pip list levou cerca de 90 segundos no WSL2.
Eu estava configurando a variável de ambiente DISPLAY para um servidor X em execução na área de trabalho do Windows. Limpar a variável de ambiente DISPLAY ou iniciar meu servidor X mudou o tempo para 0,343s.

Parece que consegui corrigir o problema permanentemente atualizando o chaveiro com pip3 install -U keyring e garantindo que
[backend]
default-keyring=keyring.backends.null.Keyring
está definido no arquivo de configuração do chaveiro em ~/.config/python_keyring/keyringrc.cfg

Isso funciona para mim.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Parece que consegui corrigir o problema permanentemente atualizando o chaveiro com pip3 install -U keyring e garantindo que
[backend]
default-keyring=keyring.backends.null.Keyring
está definido no arquivo de configuração do chaveiro em ~/.config/python_keyring/keyringrc.cfg

Isso funciona para mim.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Confirmar isso funciona para mim também.

Ubuntu 18.04
Python 3.6.8
pip 20.2.3

Olá pessoal - não precisamos de mais relatórios confirmando que a desativação do chaveiro aumentaria a velocidade dos usuários. Agradeceríamos se alguém se apresentasse para ajudar com https://github.com/pypa/pip/issues/8719. :)

Isso ocorre para mim ao executar o wayland no Fedora 33! Esperando que esta seja uma adição útil, mesmo como um comentário "eu também", já que todos os outros parecem estar na WSL.

Meio Ambiente

• pip 20.2.2 de /usr/lib/python3.9/site-packages/pip (python 3.9)
• Python 3.9.0
• SO: Fedora 33
• ambiente de trabalho: swaywm (wayland tiling wm), iniciado via gdm

execução cronometrada de pip e 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

Obrigado pelos relatórios aqui. Está claro agora que isso acontece devido à integração do chaveiro de pip. # 8687 tornaria o pip significativamente menos propenso a pesquisar coisas no chaveiro e # 8719 tornaria isso um opt-in.

Para informação das pessoas, importar o módulo do chaveiro para qualquer coisa pode causar longas paralisações no ambiente certo, quer o código chame explicitamente ou não as funções do chaveiro. Isso pode ser visto cronometrando uma importação: time python3 -c "import keyring" . Para mim, isso leva cerca de 25 segundos em uma máquina Fedora 32 na qual estou conectado remotamente e que não tem uma sessão de login gráfica.

Para mim, a causa direta disso é que o chaveiro executa o código na importação que, eventualmente, tenta fazer uma conexão DBus com org.kde.kwalletd5 e isso falha muito lentamente. Você pode duplicar o código fundamental (e reproduzir a tenda) com:

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

No próprio chaveiro, este código está em keyring / backends / kwallet.py, no método priority() . Se o kwalletd ainda não estiver em execução e não puder ser iniciado, isso parece exigir um longo tempo limite dentro do próprio DBus ou nas bibliotecas DBus do Python.

Isso significa que toda a importação do módulo do chaveiro deve ser condicional e controlada em qualquer sinalizador de linha de comando, não apenas em seu uso.

Para informação das pessoas, importar o módulo do chaveiro para qualquer coisa pode causar longas paradas no ambiente certo

Obrigado por esta informação. Parece um grande problema com o próprio módulo de chaveiro - as importações são feitas para ser baratas. Foi criado como um bug lá? Acho que nosso plano para o pip é suficiente para mitigar o pior desse comportamento, mas, no final das contas, acho que consertar isso depende dos mantenedores do chaveiro.

Se alguém puder fazer um link para um relatório de bug contra o chaveiro, isso seria ótimo para que possamos monitorar o que eles fazem e fornecer conselhos aos usuários do pip sendo atingidos por isso.

FWIW, uma solução alternativa para os usuários que acertam isso é desativar o chaveiro, conforme documentado aqui: https://github.com/jaraco/keyring#disabling -keyring

Foi criado como um bug lá? Eu

Sim: https://github.com/jaraco/keyring/issues/403