Pip: Chaque commande de pip tourne très lentement

À quoi faites-vous référence par «il a l'habitude de»? Ce ralentissement se produit-il en raison d'une mise à niveau de pip ou d'une mise à niveau du système? Si cela arrive de nulle part, ce n'est probablement pas un problème de pip, mais quelque chose qui se passe sur votre machine en particulier, sur lequel pip n'a pas de contrôle.

Non, je n'ai fait aucune mise à niveau de pip. Windows 10 effectue des mises à jour fréquentes, mais je ne peux pas comprendre comment cela affecte les performances avec pip à l'intérieur de WSL2.

J'espère que quelqu'un pourra m'indiquer comment je peux même retracer ce problème. Pour le moment, pip ne génère aucun message d'erreur, donc aucun moyen de savoir ce qui se passe.

Pourriez-vous partager combien de paquets sont déjà installés (c'est-à-dire la sortie de pip list )? Cela pourrait être lié à la logique interne de pip [1] qui a essayé de regarder tous les paquets installés avant tout traitement de sortie.

[1] Construction WorkingSet de pkg_resources en charge, pour ceux qui se demandent de quoi je parle

Même problème avec moi aussi. J'ai exécuté la commande pip3 list et il a fallu environ 10 secondes pour lister les packages. Pour l'instant, je crée un environnement virtuel en utilisant pipenv qui supprime le problème. Je pense que cela pourrait interférer avec le partage d'exécutables entre wsl2 linux et windows. Je ne sais pas quelle est la source du problème!

Je pense que cela pourrait interférer avec le partage d'exécutables entre wsl2 linux et Windows

Cela semble plausible. Les performances du système de fichiers de WSL2 sont terribles si vous accédez au système de fichiers Windows du côté Linux. Quel est le Python associé à votre commande pip3 ? Pouvez-vous fournir ses sys.path ? Cela se produit-il si vous exécutez pip3 à un emplacement différent? Est-ce important que l'emplacement se trouve dans le système de fichiers Linux ou du côté Windows?

Si nous exécutons le même pip3 list sur Windows PowerShell, c'est instantané et le problème ne se produit pas.

Chemin système sans environnement pipenv activé

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

Chemin système avec environnement pipenv activé

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

Cela pourrait être possible si le chemin sys est changé pour global, alors pip3 n'interférera pas avec Windows One. Je ne l'ai pas essayé!

Hmm, aucun des répertoires ne semble inhabituel. Montez-vous l'un des répertoires Windows? Par exemple, créez-vous un lien symbolique entre votre répertoire personnel (ou tout élément répertorié dans sys.path ) vers un répertoire Windows? Ou exécutez-vous la commande dans un répertoire sous /mnt ?

J'essaierais probablement de déplacer temporairement certaines des entrées listées dans sys.path (en particulier le ~/.local/lib un) et voir si cela change quelque chose. Ou peut-être que vous pouvez simplement insérer quelques profileurs dans le runtime Python et voir exactement ce qui ralentit les choses. Il existe de nombreuses astuces que vous pouvez faire pour isoler le problème. Ce serait immensément plus utile que moi (ou quiconque sans accès physique à votre machine) essayant de dépanner contre le vide.

Edit: Cela peut en quelque sorte être lié à l'affichage? Le ralentissement disparaît en grande partie (prend 0,5 seconde) lorsque je démarre un serveur X11 (en utilisant MobaXterm). La raison pour laquelle j'ai trouvé ce problème était que matplotlib était très lent, j'ai donc essayé d'utiliser pip pour réinstaller. J'ai oublié que je devais exécuter un Xterm pour utiliser matplotlib.

J'ai également rencontré ce problème et j'ai la même sortie de sys.path de mon python que piyushchauhan2011. J'ai un lien symbolique dans mon répertoire personnel vers un répertoire Windows comme celui-ci
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Je développe un package python dont les résultats doivent être comparés à un programme qui ne peut fonctionner que dans un environnement unix. J'utilise sublime test pour modifier les fichiers dans mon répertoire Windows et j'utilise WSL2 pour exécuter le code de référence sur ces fichiers via le lien symbolique.

Je peux exécuter les commandes suivantes sans aucun ralentissement: check, show, config
J'utilise pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Lancer pip3 list renvoie un résultat mais cela prend ~ 30 secondes.
J'ai environ 100 packages installés.

J'ai essayé ce qui suit sans succès
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
J'ai essayé d'exécuter pip à la fois à l'intérieur du système de fichiers WSL2 et du côté Windows, chacun d'eux souffrant du même ralentissement.

Je ne suis pas à 100% la meilleure façon de changer le sys.path mais voici ma tentative:
J'ai lancé ipython3 qui commence par un 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 je sauvegarde comme suit backup = sys.path.copy()
À ce stade, j'ai confirmé que si j'utilise run '/usr/bin/pip3' list je rencontre toujours le ralentissement.
Cependant, après avoir défini sys.path = [] et exécuté à nouveau, j'obtiens un ModuleNotFoundError: No module named 'pyparsing' . Ce résultat se répète à chaque fois que je cours à nouveau. MAIS! Une fois que j'ai mis sys.path = backup maintenant run '/usr/bin/pip3' list fonctionne miraculeusement!
La sortie de l'utilisation de time :

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

Il y a donc clairement quelque chose qui cloche dans les chemins.
Ensuite, je peux à nouveau définir sys.path =[] et run '/usr/bin/pip3' list fonctionne toujours pour une raison quelconque.

Je ne sais pas si cela est pertinent mais j'ai pensé que je le mentionnerais:
Après avoir utilisé la commande run mon sys.path est rempli comme suit (après avoir été défini sur une liste vide)

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

Ce qui souffre encore du ralentissement jusqu'à ce que le sys.path soit défini sur une liste vide, puis réinitialisé à la liste d'origine ou à cette liste.

Cela peut en quelque sorte être lié à l'affichage? Le ralentissement disparaît en grande partie (prend 0,5 seconde) lorsque je démarre un serveur X11 (en utilisant MobaXterm). La raison pour laquelle j'ai trouvé ce problème était que matplotlib était très lent, j'ai donc essayé d'utiliser pip pour réinstaller. J'ai oublié que je devais exécuter un Xterm pour utiliser matplotlib.

Peut être…? Le problème est tout à fait étrange pour moi. S'il s'agit d'un problème sys.path , le même ralentissement ne se produirait-il pas pour toutes les importations Python, pas seulement pour pip? Je suis assez perplexe 😞

Bonjour, mon environnement est:

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

Avec Python 3.6.9 et pip 9.0.1 et je peux confirmer que pip est extrêmement lent avec chaque command (surtout avec install )

Mon pip3 list est

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 vous voulez un correctif _temporaire_, je vous recommande d'exécuter un serveur X11 tel que MobaXterm (ou un autre équivalent). Je ne comprends pas pourquoi , mais cela a résolu mon problème de ralentissement pour toutes les commandes.

@ngraymon c'est étrange mais je vais essayer ce correctif temporaire.
Merci!
Je mettrai à jour ce problème une fois essayé.

Juste pour confirmer que le comportement est toujours le même que je viens de vérifier:

Exécution de time pip3 list dans un terminal Windows sur WSL2:

Après avoir démarré MobaXterm et exécuté time pip3 list dans le même terminal:

@ngraymon Bonjour,
J'ai résolu le problème, veuillez essayer les étapes suivantes:

• N'exécutez pas de commandes pip avec sudo
• apt-update && apt-upgrade
• Redémarrez le serveur / l'ordinateur
• Gardez une attention particulière à docker, la nuit dernière, j'ai remarqué que le processus python3 était intensément utilisé par l'essaim

@MattiaFailla
Je suis content que vous ayez résolu votre problème.
J'ai essayé vos suggestions mais cela n'a pas résolu le problème.
Je ne lance pas pip avec sudo, mais j'ai installé pip3 en utilisant sudo apt install python3-pip , peut-être est-ce pertinent?
Je suis content de la façon dont les choses se passent pour moi car j'ai besoin d'un serveur X de toute façon depuis que je trace en utilisant matplotlib.

@ngraymon pourriez-vous exécuter python -m pip et voir si cela est également lent?

Si c'est le cas, et que vous avez une version Python suffisamment nouvelle, veuillez nous fournir la sortie de python -X importtime -m pip -v . Si le ralentissement concerne les importations, cela nous aidera à le savoir.

@pradyunsg
Bonjour,

J'ai exécuté time python3 -m pip sans aucune commande pour pip qui répond avec le message d'aide à ce moment

Cependant si je lance time python3 -m pip list

Exécution de time python3 -m pip check qui n'a pas / n'est toujours pas affecté par le ralentissement

J'ai couru ce qui suit:

• python3 -X importtime -m pip -v et joint comme out_1.txt

• python3 -X importtime -m pip -v list et joint comme out_list.txt

• python3 -X importtime -m pip -v check et joint comme out_check.txt

Il semble que le coupable de la commande list soit keyring.core ?
import time: 96023197 | 96029594 | keyring.core

J'espère que cela sera utile :)

Il semble que le coupable de la commande list soit keyring.core?

Combiné avec la chose étrange d'avoir un serveur X aidant, je me demande si le trousseau de clés dépend d'une interface graphique, et il y a du code là-dedans qui essaie de trouver X et provoque un retard jusqu'à ce qu'il conclue qu'il n'y en a pas?

@pfmoore
Sur la base de leur page sur pypi, il semble que cela nécessite un serveur D-Bus ou X11?

J'ai essayé python3 -m keyring --disable et export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring mais aucun des deux n'a semblé résoudre le problème.

jaraco / keyring # 434 semble lié, mais les conseils sur la désactivation pointent vers la documentation qui indique ce que vous avez déjà essayé.

Vous rencontrez également ce problème, croyez qu'il a commencé après l'exécution d'une routine sudo apt-get update && sudo apt-get upgrade hier. C'est définitivement lié au trousseau de clés et à l'affichage. En plus du correctif d'avoir un serveur X en cours d'exécution, j'ai pu résoudre le problème en supprimant la ligne que j'avais dans mon fichier .bashrc pointant l'affichage vers l'adresse IP de WSL2. La ligne en question est:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

Après avoir supprimé cette ligne de .bashrc et redémarré WSL2, pip se comporte comme prévu. Je ne sais pas si cela oriente quelqu'un dans la bonne direction, car je ne sais pas comment procéder à partir de là.

Il semble que j'ai pu résoudre définitivement le problème en mettant à jour le trousseau de clés avec pip3 install -U keyring et en m'assurant que
[backend]
default-keyring=keyring.backends.null.Keyring
est défini dans le fichier de configuration du trousseau de clés à ~/.config/python_keyring/keyringrc.cfg

Merveilleux, la suggestion de cjpellicci de pip3 install -U keyring fait l'affaire.
J'ai également dû déplacer ~/.local/share/python_keyring/keyringrc.cfg vers ~/.config/share/python_keyring/keyringrc.cfg .
Lancer pip3 list prend maintenant 1/2 seconde au lieu de 90 secondes.
Ceci sans aucun serveur X en cours d'exécution.

Ce qui précède ne semble pas fonctionner pour moi. Il n'y a pas de keyringrc.cfg dans ~ / .local / share / python_keyring / ou ~ / .config / share / python_keyring /.

Cela pourrait-il être un comportement différent entre WSL Ubuntu et Ubuntu?

@peidaqi , après la mise à jour du trousseau de clés, vous voudrez peut-être essayer de créer le fichier de configuration avec ce nom exact dans le répertoire ~/.config/python_keyring/ , puis ajouter ce qui suit dans le fichier de configuration:
[backend]
default-keyring=keyring.backends.null.Keyring

Je crois que keyringrc.cfg peut être fait après avoir suivi les étapes ci-dessus pour désactiver le trousseau de clés en définissant une variable d'environnement, mais je peux me tromper.

BTW: J'exécute également Ubuntu sur WSL2.

salut! J'étais plus ou moins confronté au même problème avec pip list fonctionnant lentement (~ 1 min), y compris toute commande pip install que j'essayais d'exécuter (sur wsl2). Cependant, je ne suis pas sûr que le comportement soit exactement le même (pip list _did_ sort les packages mais la commande reviendrait après ~ 1 min).

Voici ce qui a finalement résolu mon problème: https://askubuntu.com/a/38468/938540 - Je ne suis pas sûr que les problèmes soient liés, mais les symptômes étaient très similaires. J'espère que cela t'aides!

Ajout d'un autre point de données possible:
pip list pris environ 90 secondes sous WSL2.
Je définissais la variable d'environnement DISPLAY sur un serveur X fonctionnant sous le bureau Windows. La suppression de la variable d'environnement DISPLAY ou le lancement de mon serveur X a changé l'heure à 0,343 s.

Il semble que j'ai pu résoudre définitivement le problème en mettant à jour le trousseau de clés avec pip3 install -U keyring et en m'assurant que
[backend]
default-keyring=keyring.backends.null.Keyring
est défini dans le fichier de configuration du trousseau de clés à ~/.config/python_keyring/keyringrc.cfg

Ça marche pour moi.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Il semble que j'ai pu résoudre définitivement le problème en mettant à jour le trousseau de clés avec pip3 install -U keyring et en m'assurant que
[backend]
default-keyring=keyring.backends.null.Keyring
est défini dans le fichier de configuration du trousseau de clés à ~/.config/python_keyring/keyringrc.cfg

Ça marche pour moi.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Confirmer cela fonctionne aussi pour moi.

Ubuntu 18.04
Python 3.6.8
pip 20.2.3

Salut les gens - nous n'avons pas besoin de plus de rapports confirmant que la désactivation du trousseau de clés donnerait aux utilisateurs une accélération. Nous apprécierions que quelqu'un se présente pour vous aider avec https://github.com/pypa/pip/issues/8719. :)

Cela se produit pour moi lorsque je cours Wayland sur Fedora 33! En espérant que ce soit un ajout utile même en tant que commentaire moi aussi, puisque tous les autres semblent être sur WSL.

Environnement

• pip 20.2.2 de /usr/lib/python3.9/site-packages/pip (python 3.9)
• Python 3.9.0
• Système d'exploitation: Fedora 33
• environnement de bureau: swaywm (wayland tiling wm), démarré via gdm

exécution chronométrée de pip et 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

Merci pour les rapports ici. Il est clair maintenant que cela se produit en raison de l'intégration du trousseau de clés de pip. # 8687 rendrait pip beaucoup moins susceptible de rechercher des éléments dans le trousseau de clés et # 8719 en ferait un opt-in.

Pour l'information des gens, l'importation du module de trousseau de clés dans n'importe quoi peut provoquer de longs arrêts dans le bon environnement, que le code appelle ou non explicitement des fonctions de trousseau de clés. Cela peut être vu en chronométrant une importation: time python3 -c "import keyring" . Pour moi, cela prend environ 25 secondes sur une machine Fedora 32 à laquelle je suis connecté à distance et qui n'a pas de session de connexion graphique.

Pour moi, la cause directe de ceci est que le trousseau de clés exécute du code à l'importation qui tente finalement d'établir une connexion DBus à org.kde.kwalletd5 et cela échoue très lentement. Vous pouvez dupliquer le code fondamental (et reproduire le décrochage) avec:

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

Dans le trousseau de clés lui-même, ce code se trouve dans keyring / backends / kwallet.py, dans la méthode priority() . Si kwalletd n'est pas déjà en cours d'exécution et ne peut pas être démarré, cela semble nécessiter un long délai dans DBus lui-même ou dans les bibliothèques Python DBus.

Cela implique que l'importation entière du module de trousseau de clés doit être conditionnelle et fermée sur n'importe quel indicateur de ligne de commande, pas seulement sur son utilisation.

Pour l'information des gens, l'importation du module de trousseau de clés dans n'importe quoi peut provoquer de longues interruptions dans le bon environnement

Merci pour cette information. Cela ressemble à un problème majeur avec le module porte-clés lui-même - les importations sont censées être bon marché. Cela a-t-il été soulevé comme un bug là-bas? Je pense que notre plan pour pip est suffisant pour atténuer le pire de ce comportement, mais en fin de compte, je pense que la résolution de ce problème incombe aux responsables du trousseau de clés.

Si quelqu'un peut créer un lien vers un rapport de bogue contre le trousseau de clés, ce serait génial pour que nous puissions surveiller ce qu'ils font et fournir des conseils aux utilisateurs de pip qui sont touchés par cela.

FWIW, une solution de contournement pour les utilisateurs qui le rencontrent consiste à désactiver le trousseau de clés, comme indiqué ici: https://github.com/jaraco/keyring#disabling -keyring

Cela a-t-il été soulevé comme un bug là-bas? je

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