Pip: Cada comando de pip funciona muy lento

¿A qué te refieres con "solía"? ¿Esta desaceleración ocurre debido a una actualización de pip o una actualización del sistema? Si sucede de la nada, es muy probable que no sea un problema de pip, sino algo que esté sucediendo en su máquina en particular, sobre lo que pip no tiene control.

No, no hice ninguna actualización de pip. Windows 10 realiza actualizaciones frecuentes, pero no puedo comprender cómo esto afecta el rendimiento con pip dentro de WSL2.

Espero que alguien pueda señalarme una dirección sobre cómo puedo rastrear este problema. En este momento, pip no muestra ningún mensaje de error, por lo que no hay forma de saber qué está pasando.

¿Podría compartir cuántos paquetes ya están instalados (es decir, la salida de pip list )? Puede estar relacionado con la lógica interna de pip [1] que intentó ver todos los paquetes instalados antes de cualquier procesamiento de salida.

[1] Construcción WorkingSet de pkg_resources en carga, para aquellos que se preguntan de qué estoy hablando

El mismo problema conmigo también. Ejecuté el comando pip3 list y me llevó más de 10 segundos enumerar los paquetes. Por ahora creo un entorno virtual usando pipenv que elimina el problema. Creo que podría estar interfiriendo con el intercambio de ejecutables entre wsl2 linux y Windows. ¡Sin embargo, no estoy seguro de cuál es la fuente del problema!

Creo que podría estar interfiriendo con el intercambio de ejecutables entre wsl2 linux y windows

Esto suena plausible. El rendimiento del sistema de archivos de WSL2 es terrible si accede al sistema de archivos de Windows en el lado de Linux. ¿Cuál es el Python asociado a su comando pip3 ? ¿Puede proporcionar su sys.path ? ¿Sucede esto si ejecuta pip3 en una ubicación diferente? ¿Importa si la ubicación está en el sistema de archivos de Linux o en el lado de Windows?

Si ejecutamos el mismo pip3 list en Windows powershell, es instantáneo y el problema no ocurre.

Ruta del sistema sin entorno pipenv activado

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

Ruta del sistema con el entorno pipenv activado

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

Podría ser posible si la ruta del sistema se cambia por global, entonces pip3 no interferirá con Windows One. ¡No lo he probado!

Hmm, ninguno de los directorios parece fuera de lo común. ¿Ha montado alguno de los directorios de Windows? Por ejemplo, ¿enlaza simbólicamente su directorio de inicio (o cualquier cosa que aparezca en sys.path ) a un directorio de Windows? ¿O ejecuta el comando en un directorio bajo /mnt ?

Probablemente intentaría mover temporalmente algunas de las entradas enumeradas en sys.path (especialmente el ~/.local/lib uno) y ver si eso cambia algo. O tal vez pueda insertar algunos perfiladores en el tiempo de ejecución de Python y ver qué es exactamente lo que ralentiza las cosas. Hay muchos trucos que puede hacer para aislar el problema. Eso sería inmensamente más útil que yo (o cualquier persona sin acceso físico a su máquina) tratando de solucionar problemas contra el aire.

Editar: ¿Esto puede estar vinculado de alguna manera a la pantalla? La desaceleración desaparece en gran medida (toma 0.5 segundos) cuando inicio un servidor X11 (usando MobaXterm). La razón por la que encontré este problema fue que matplotlib era muy lento, así que intenté usar pip para reinstalar. Olvidé que necesitaba ejecutar un Xterm para usar matplotlib.

También encontré este problema y tengo la misma salida de sys.path de mi python que piyushchauhan2011. Tengo un enlace simbólico en mi directorio de inicio a un directorio de Windows como ese
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Estoy desarrollando un paquete de Python cuyos resultados deben compararse con un programa que solo se puede ejecutar en un entorno Unix. Utilizo la prueba sublime para editar los archivos en mi directorio de Windows y uso WSL2 para ejecutar el código de referencia en esos archivos a través del enlace simbólico.

Puedo ejecutar los siguientes comandos sin ralentización: check, show, config
Estoy usando pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Ejecutar pip3 list devuelve un resultado, pero tarda ~ 30 segundos.
Tengo instalados unos 100 paquetes.

Intenté lo siguiente sin éxito
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
He intentado ejecutar pip tanto dentro del sistema de archivos WSL2 como en el lado de Windows, cada uno de ellos sufriendo la misma desaceleración.

No soy 100% cuál sería la mejor manera de cambiar sys.path , pero aquí está mi intento:
Lancé ipython3 que comienza con 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 hago una copia de seguridad de la siguiente manera backup = sys.path.copy()
En este punto, confirmé que si uso run '/usr/bin/pip3' list todavía encuentro la desaceleración.
Sin embargo, cuando después de eso configuro sys.path = [] y vuelvo a ejecutar, obtengo un ModuleNotFoundError: No module named 'pyparsing' . Este resultado se repite cada vez que corro de nuevo. ¡PERO! Una vez que configuré sys.path = backup ahora run '/usr/bin/pip3' list ¡funciona milagrosamente!
El resultado de usar time :

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

Así que claramente hay algo mal en los caminos.
Luego, puedo volver a configurar sys.path =[] y run '/usr/bin/pip3' list todavía funciona por alguna razón.

No estoy seguro de si esto es relevante, pero pensé que lo mencionaría:
Después de usar el comando run mi sys.path se completa de la siguiente manera (después de haber sido configurado en una lista vacía)

['/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 todavía sufre la desaceleración hasta que sys.path se establece en una lista vacía y luego se restablece a la lista original o esta lista.

Esto puede estar relacionado de alguna manera con la pantalla. La desaceleración desaparece en gran medida (toma 0.5 segundos) cuando inicio un servidor X11 (usando MobaXterm). La razón por la que encontré este problema fue que matplotlib era muy lento, así que intenté usar pip para reinstalar. Olvidé que necesitaba ejecutar un Xterm para usar matplotlib.

Tal vez…? Todo el problema me resulta muy extraño. Si esto es un problema de sys.path , ¿no ocurriría la misma desaceleración para todas las importaciones de Python, no solo para pip? Estoy bastante perplejo 😞

Hola, mi entorno es:

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

Con Python 3.6.9 y pip 9.0.1 y puedo confirmar que pip es extremadamente lento con cada command (especialmente con install )

Mi pip3 list es

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 Si desea una solución _temporary_, le recomiendo ejecutar un servidor X11 como MobaXterm (o algún otro equivalente). No entiendo por qué , pero solucionó mi problema de desaceleración para todos los comandos.

@ngraymon eso es extraño, pero intentaré este arreglo temporal.
¡Gracias!
Actualizaré este problema una vez que lo intente.

Solo para confirmar que el comportamiento sigue siendo el mismo, lo verifiqué hace un momento:

Ejecutando time pip3 list dentro de una Terminal de Windows en WSL2:

Después de iniciar MobaXterm y ejecutar time pip3 list en la misma terminal:

@ngraymon Hola,
Resolví el problema, intente los siguientes pasos:

• No ejecute comandos pip con sudo
• apt-update && apt-upgrade
• Reinicie el servidor / computadora
• Preste mucha atención a la ventana acoplable, anoche noté que el enjambre estaba utilizando intensamente el proceso de python3

@MattiaFailla
Me alegra que hayas resuelto tu problema.
Probé tus sugerencias pero no resolvió el problema.
No ejecuto pip con sudo, pero instalé pip3 usando sudo apt install python3-pip , ¿tal vez eso sea relevante?
Estoy contento con la forma en que están las cosas para mí, ya que necesito un servidor X de todos modos, ya que estoy trazando usando matplotlib.

@ngraymon, ¿ podrías ejecutar python -m pip y ver si eso también es lento?

Si es así, y tiene una versión de Python suficientemente nueva, por favor envíenos el resultado de python -X importtime -m pip -v . Si la ralentización está en las importaciones, esto nos ayudará a saberlo.

@pradyunsg
Hola,

Ejecuté time python3 -m pip sin ningún comando para pip que responde con el mensaje de ayuda en este momento

Sin embargo, si ejecuto time python3 -m pip list

Ejecutando time python3 -m pip check que no se ha visto / todavía no se ve afectado por la ralentización

Ejecuté lo siguiente:

• python3 -X importtime -m pip -v y adjunto eso como out_1.txt

• python3 -X importtime -m pip -v list y adjunto eso como out_list.txt

• python3 -X importtime -m pip -v check y lo adjunto como out_check.txt

Parece que el culpable del comando list es keyring.core ?
import time: 96023197 | 96029594 | keyring.core

Con suerte, eso es útil :)

Parece que el culpable del comando list es keyring.core?

Combinado con lo extraño de tener un servidor X ayudando, me pregunto si el llavero depende de una GUI, y hay algún código allí que intenta encontrar X y causa un retraso hasta que concluye que no hay uno.

@pfmoore
Según su página en pypi , parece que requiere D-Bus o un servidor X11.

Intenté python3 -m keyring --disable y export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring pero ninguno pareció solucionar el problema.

jaraco / keyring # 434 parece relacionado, pero el consejo sobre la desactivación apunta a los documentos que indican lo que ya ha probado.

Al experimentar este problema también, crea que comenzó después de ejecutar una rutina sudo apt-get update && sudo apt-get upgrade ayer. Definitivamente está relacionado con el llavero y la pantalla de alguna manera. Además de la solución de tener un servidor X en ejecución, pude solucionar el problema eliminando la línea que tenía en mi archivo .bashrc que apuntaba a la pantalla a la dirección IP de WSL2. La línea en cuestión es:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

Después de eliminar esta línea de .bashrc y reiniciar WSL2, pip se comporta como se esperaba. No estoy seguro de si esto apunta a alguien en la dirección correcta, ya que no estoy seguro de cómo proceder a partir de aquí.

Parece que pude solucionar permanentemente el problema actualizando el llavero con pip3 install -U keyring y asegurándome de que
[backend]
default-keyring=keyring.backends.null.Keyring
se establece en el archivo de configuración del llavero en ~/.config/python_keyring/keyringrc.cfg

Maravillosa, la sugerencia de cjpellicci de pip3 install -U keyring funcionó.
También tuve que mover ~/.local/share/python_keyring/keyringrc.cfg a ~/.config/share/python_keyring/keyringrc.cfg .
Ejecutar pip3 list toma 1/2 segundo en lugar de 90 segundos.
Esto es sin ningún servidor X en ejecución.

Lo anterior no parece funcionar para mí. No hay keyringrc.cfg en ~ / .local / share / python_keyring / o ~ / .config / share / python_keyring /.

¿Podría ser este un comportamiento diferente entre WSL Ubuntu y Ubuntu?

@peidaqi , después de actualizar el llavero, puede intentar crear el archivo de configuración con ese nombre exacto en el directorio ~/.config/python_keyring/ , y luego agregar lo siguiente en el archivo de configuración:
[backend]
default-keyring=keyring.backends.null.Keyring

Creo que keyringrc.cfg se puede hacer después de seguir los pasos anteriores para deshabilitar el llavero configurando una variable de entorno, pero podría estar equivocado.

Por cierto: también estoy ejecutando Ubuntu en WSL2.

¡Hola! Me enfrentaba más o menos al mismo problema con pip list corriendo lento (~ 1 min), incluido cualquier comando pip install que estaba tratando de ejecutar (en wsl2). Sin embargo, no estoy seguro de si el comportamiento fue exactamente el mismo (pip list _did_ muestra los paquetes, pero el comando volvería después de ~ 1 min).

Lo que finalmente resolvió mi problema fue esto: https://askubuntu.com/a/38468/938540 - No estoy seguro de que los problemas estén relacionados, pero los síntomas eran muy similares. ¡Espero que esto ayude!

Añadiendo otro posible punto de datos:
pip list tomó alrededor de 90 segundos bajo WSL2.
Estaba configurando la variable de entorno DISPLAY en un servidor X que se ejecutaba en el escritorio de Windows. Borrar la variable de entorno DISPLAY o iniciar mi servidor X cambió el tiempo a 0.343s.

Parece que pude solucionar permanentemente el problema actualizando el llavero con pip3 install -U keyring y asegurándome de que
[backend]
default-keyring=keyring.backends.null.Keyring
se establece en el archivo de configuración del llavero en ~/.config/python_keyring/keyringrc.cfg

Funciona para mi.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Parece que pude solucionar permanentemente el problema actualizando el llavero con pip3 install -U keyring y asegurándome de que
[backend]
default-keyring=keyring.backends.null.Keyring
se establece en el archivo de configuración del llavero en ~/.config/python_keyring/keyringrc.cfg

Funciona para mi.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Confirmar esto también funciona para mí.

Ubuntu 18.04
Python 3.6.8
pip 20.2.3

Hola amigos, no necesitamos más informes que confirmen que la desactivación del llavero aumentaría la velocidad de los usuarios. Agradeceríamos si alguien se acercara para ayudar con https://github.com/pypa/pip/issues/8719. :)

¡Esto me ocurre cuando corro en wayland en Fedora 33! Espero que esto sea una adición útil incluso como un comentario yo también, ya que todos los demás parecen estar en WSL.

Medio ambiente

• pip 20.2.2 de /usr/lib/python3.9/site-packages/pip (python 3.9)
• Python 3.9.0
• SO: Fedora 33
• entorno de escritorio: swaywm (wayland tiling wm), iniciado a través de gdm

ejecución programada de pip y 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

Gracias por los informes aquí. Ahora está claro que esto sucede debido a la integración del llavero de pip. # 8687 haría que pip fuera significativamente menos propenso a buscar cosas en el llavero y # 8719 lo convertiría en un opt-in.

Para información de la gente, importar el módulo de llavero en cualquier cosa puede causar paradas prolongadas en el entorno adecuado, ya sea que el código alguna vez llame explícitamente a funciones de llavero. Esto se puede ver cronometrando una importación: time python3 -c "import keyring" . Para mí, esto toma aproximadamente 25 segundos en una máquina Fedora 32 en la que estoy conectado de forma remota y que no tiene una sesión de inicio de sesión gráfica.

Para mí, la causa directa de esto es que el llavero ejecuta código en la importación que eventualmente intenta hacer una conexión DBus a org.kde.kwalletd5 y esto falla muy lentamente. Puede duplicar el código fundamental (y reproducir el bloqueo) con:

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

En el llavero en sí, este código está en keyring / backends / kwallet.py, en el método priority() . Si kwalletd aún no se está ejecutando y no se puede iniciar, esto parece requerir un tiempo de espera prolongado dentro de DBus o en las bibliotecas de Python DBus.

Esto implica que toda la importación del módulo de llavero debe ser condicional y cerrada en cualquier marca de línea de comando, no solo en su uso.

Para información de las personas, importar el módulo de llavero en cualquier cosa puede causar paradas prolongadas en el entorno adecuado.

Gracias por esta información. Parece un problema importante con el módulo de llavero en sí: las importaciones deben ser baratas. ¿Se ha planteado como un error allí? Creo que nuestro plan para pip es suficiente para mitigar lo peor de este comportamiento, pero, en última instancia, creo que arreglarlo depende de los responsables del keyring.

Si alguien puede vincular a un informe de error contra el llavero, sería genial para que podamos monitorear lo que hacen y brindar consejos a los usuarios de pip que se ven afectados por esto.

FWIW, una solución para los usuarios que golpean esto es deshabilitar el llavero, como se documenta aquí: https://github.com/jaraco/keyring#disabling -keyring

¿Se ha planteado como un error allí? yo

Sí: https://github.com/jaraco/keyring/issues/403