Pip: Jeder einzelne Befehl von pip läuft sehr langsam

Was meinst du mit "es war früher"? Tritt diese Verlangsamung aufgrund eines Pip-Upgrades oder eines System-Upgrades auf? Wenn es aus dem Nichts passiert, ist es sehr wahrscheinlich kein Pip-Problem, sondern etwas, das auf Ihrer speziellen Maschine passiert und über das Pip keine Kontrolle hat.

Nein, ich habe kein Pip-Upgrade durchgeführt. Windows 10 führt häufig Updates durch, aber ich kann nicht verstehen, wie sich dies auf die Leistung von pip in WSL2 auswirkt.

Ich hoffe, jemand könnte mir eine Richtung zeigen, wie ich dieses Problem überhaupt verfolgen kann. Im Moment gibt pip keine Fehlermeldungen aus, sodass Sie nicht wissen können, was los ist.

Können Sie uns mitteilen, wie viele Pakete bereits installiert sind (dh die Ausgabe von pip list )? Dies könnte mit der internen Logik von pip [1] zusammenhängen, die versucht hat, alle installierten Pakete vor einer Ausgabeverarbeitung zu überprüfen.

[1] Die WorkingSet-Konstruktion von pkg_resources unter Last für diejenigen, die sich fragen, wovon ich spreche

Gleiches Problem auch bei mir. Ich habe den Befehl pip3 list ausgeführt und es dauerte mehr als 10 Sekunden, um Pakete aufzulisten. Im Moment erstelle ich eine virtuelle Umgebung mit pipenv wodurch das Problem behoben wird. Ich denke, es könnte die gemeinsame Nutzung von ausführbaren Dateien zwischen wsl2 Linux und Windows stören. Ich bin mir nicht sicher, wo das Problem liegt!

Ich denke, es könnte die gemeinsame Nutzung von ausführbaren Dateien zwischen wsl2 Linux und Windows stören

Das klingt plausibel. Die Leistung des WSL2-Dateisystems ist schrecklich, wenn Sie auf der Linux-Seite auf das Windows-Dateisystem zugreifen. Was ist der Python, der Ihrem Befehl pip3 ? Können Sie seine sys.path angeben? Geschieht dies, wenn Sie pip3 an einem anderen Ort ausführen? Ist es wichtig, ob sich der Speicherort im Linux-Dateisystem oder auf der Windows-Seite befindet?

Wenn wir unter Windows Powershell dasselbe pip3 list ausführen, ist dies sofort der Fall und das Problem tritt nicht auf.

Systempfad ohne aktivierte Pipenv-Umgebung

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

Systempfad mit aktivierter Pipenv-Umgebung

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

Wenn der sys-Pfad für global geändert wird, kann es sein, dass pip3 Windows 1 nicht beeinträchtigt. Ich habe es nicht ausprobiert!

Hmm, keines der Verzeichnisse scheint ungewöhnlich zu sein. Mounten Sie zufällig eines der Windows-Verzeichnisse? Verknüpfen Sie beispielsweise Ihr Home-Verzeichnis (oder etwas, das in sys.path ) mit einem Windows-Verzeichnis? Oder führen Sie den Befehl in einem Verzeichnis unter /mnt ?

Ich würde wahrscheinlich versuchen, einige der in sys.path aufgeführten Einträge vorübergehend zu entfernen (insbesondere die ~/.local/lib eins) und zu prüfen, ob sich dadurch etwas ändert. Oder Sie können einfach ein paar Profiler in die Python-Laufzeit einfügen und sehen, was genau die Dinge verlangsamt. Es gibt viele Tricks, mit denen Sie das Problem eingrenzen können. Das wäre immens nützlicher als ich (oder jemand ohne physischen Zugang zu Ihrem Computer), der versucht, Fehler gegen Luft zu beheben.

Bearbeiten: Dies kann irgendwie mit der Anzeige verbunden sein? Die Verlangsamung verschwindet weitgehend (dauert 0,5 Sekunden), wenn ich einen X11-Server (mit MobaXterm) starte. Der Grund, warum ich dieses Problem fand, war, dass matplotlib sehr langsam war, also habe ich versucht, pip zur Neuinstallation zu verwenden. Ich habe vergessen, dass ich ein Xterm ausführen muss, um matplotlib zu verwenden.

Ich bin auch auf dieses Problem gestoßen und habe die gleiche Ausgabe von sys.path meines Pythons wie piyushchauhan2011. Ich habe einen Symlink in meinem Home-Verzeichnis zu einem Windows-Verzeichnis wie diesem
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Ich entwickle ein Python-Paket, dessen Ergebnisse mit einem Programm verglichen werden müssen, das nur in einer Unix-Umgebung ausgeführt werden kann. Ich verwende Sublime Test, um die Dateien in meinem Windows-Verzeichnis zu bearbeiten, und verwende die WSL2, um den Benchmark-Code für diese Dateien über den Symlink auszuführen.

Ich kann die folgenden Befehle ohne Verlangsamung ausführen: check, show, config
Ich benutze pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Das Ausführen von pip3 list gibt zwar ein Ergebnis zurück, dauert jedoch ~ 30 Sekunden.
Ich habe ungefähr 100 Pakete installiert.

Ich habe Folgendes ohne Erfolg versucht
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
Ich habe versucht, pip sowohl im WSL2-Dateisystem als auch auf der Windows-Seite auszuführen, wobei jeder von ihnen die gleiche Verlangsamung aufweist.

Ich bin nicht zu 100% der beste Weg, um die sys.path zu ändern, aber hier ist mein Versuch:
Ich habe ipython3 gestartet, das mit einem sys.path von beginnt:

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

Was ich wie folgt sichern backup = sys.path.copy()
Zu diesem Zeitpunkt bestätigte ich, dass ich bei Verwendung von run '/usr/bin/pip3' list immer noch auf die Verlangsamung stoße.
Wenn ich danach jedoch sys.path = [] setze und erneut starte, erhalte ich ModuleNotFoundError: No module named 'pyparsing' . Dieses Ergebnis wiederholt sich jedes Mal, wenn ich erneut laufe. ABER! Sobald ich sys.path = backup funktioniert run '/usr/bin/pip3' list wundersame Weise!
Die Ausgabe der Verwendung von time :

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

Es ist also klar, dass etwas mit den Pfaden nicht stimmt.
Danach kann ich wieder sys.path =[] einstellen und run '/usr/bin/pip3' list funktioniert aus irgendeinem Grund immer noch.

Ich bin mir nicht sicher, ob dies relevant ist, aber ich dachte, ich würde es erwähnen:
Nach Verwendung des Befehls run mein sys.path wie folgt gefüllt (nachdem eine leere Liste festgelegt wurde).

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

Die Verlangsamung leidet immer noch, bis der sys.path auf eine leere Liste gesetzt und dann auf die ursprüngliche Liste oder diese Liste zurückgesetzt wird.

Dies kann irgendwie mit dem Display verbunden sein? Die Verlangsamung verschwindet weitgehend (dauert 0,5 Sekunden), wenn ich einen X11-Server (mit MobaXterm) starte. Der Grund, warum ich dieses Problem fand, war, dass matplotlib sehr langsam war, also habe ich versucht, pip zur Neuinstallation zu verwenden. Ich habe vergessen, dass ich ein Xterm ausführen muss, um matplotlib zu verwenden.

Könnte sein…? Das Problem ist für mich sehr seltsam. Wenn dies ein sys.path -Problem ist, würde dann nicht bei allen Python-Importen die gleiche Verlangsamung auftreten, nicht nur bei Pip? Ich bin ziemlich ratlos 😞

Hallo, meine Umgebung ist:

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

Mit Python 3.6.9 und pip 9.0.1 kann ich bestätigen, dass Pip mit jedem command extrem langsam ist (insbesondere mit install ).

Mein pip3 list ist

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 Wenn Sie eine vorübergehende Korrektur wünschen, empfehle ich, einen X11-Server wie MobaXterm (oder ein anderes Äquivalent) warum , aber es hat mein Verlangsamungsproblem für alle Befehle behoben.

@ngraymon das ist seltsam, aber ich werde diese
Vielen Dank!
Ich werde dieses Problem aktualisieren, sobald ich es versucht habe.

Nur um zu bestätigen, dass das Verhalten immer noch dasselbe ist, habe ich es gerade überprüft:

Ausführen von time pip3 list in einem Windows-Terminal unter WSL2:

Nach dem Start von MobaXterm und dem Ausführen von time pip3 list im selben Terminal:

@ngraymon Hallo,
Ich habe das Problem behoben. Bitte versuchen Sie die folgenden Schritte:

• Führen Sie keine Pip-Befehle mit sudo aus
• apt-update && apt-upgrade
• Starten Sie den Server / Computer neu
• Achten Sie genau auf Docker. Letzte Nacht habe ich festgestellt, dass der Python3-Prozess vom Schwarm intensiv genutzt wird

@ MattiaFailla
Ich bin froh, dass Sie Ihr Problem gelöst haben.
Ich habe Ihre Vorschläge ausprobiert, aber das Problem wurde dadurch nicht gelöst.
Ich führe pip nicht mit sudo aus, aber ich habe pip3 mit sudo apt install python3-pip installiert. Vielleicht ist das relevant?
Ich bin zufrieden mit der Art und Weise, wie die Dinge für mich sind, da ich sowieso einen X-Server benötige, da ich mit matplotlib plotte.

@ngraymon könntest du python -m pip ausführen und sehen, ob das auch langsam ist?

Wenn dies der Fall ist und Sie eine ausreichend neue Python-Version haben, geben Sie uns bitte die Ausgabe von python -X importtime -m pip -v . Wenn die Verlangsamung bei den Importen liegt, hilft uns dies zu wissen.

@ Pradyunsg
Hallo,

Ich habe time python3 -m pip ohne Befehl für pip ausgeführt, der in dieser Zeit mit der Hilfemeldung antwortet

Wenn ich jedoch time python3 -m pip list laufen

Das Ausführen von time python3 -m pip check das von der Verlangsamung nicht / immer noch nicht betroffen ist

Ich habe folgendes ausgeführt:

• python3 -X importtime -m pip -v und als out_1.txt angehängt

• python3 -X importtime -m pip -v list und als out_list.txt angehängt

• python3 -X importtime -m pip -v check und als out_check.txt angehängt

Es scheint, dass der Schuldige für den Befehl list keyring.core ?
import time: 96023197 | 96029594 | keyring.core

Hoffentlich ist das hilfreich :)

Es scheint, dass der Schuldige für den Listenbefehl keyring.core ist?

In Kombination mit der seltsamen Sache, dass ein X-Server hilft, frage ich mich, ob der Schlüsselring von einer grafischen Benutzeroberfläche abhängt. Dort ist Code enthalten, der versucht, X zu finden, und eine Verzögerung verursacht, bis festgestellt wird, dass es keinen gibt.

@pfmoore
Basierend auf ihrer Seite bei pypi scheint es, dass es entweder D-Bus oder einen X11-Server erfordert?

Ich habe python3 -m keyring --disable und export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring ausprobiert, aber keiner schien das Problem zu beheben.

jaraco / keyring # 434 scheint verwandt zu sein, aber der Rat zum Deaktivieren verweist auf die Dokumente, in denen angegeben ist, was Sie bereits versucht haben.

Wenn Sie dieses Problem ebenfalls erleben, glauben Sie, dass es nach dem Ausführen einer Routine sudo apt-get update && sudo apt-get upgrade gestern begonnen hat. Es hängt definitiv irgendwie mit dem Schlüsselring und dem Display zusammen. Zusätzlich zu der Korrektur, dass ein X-Server ausgeführt wird, konnte ich das Problem beheben, indem ich die Zeile in meiner .bashrc-Datei entfernte, die die Anzeige auf die IP-Adresse von WSL2 zeigte. Die fragliche Zeile lautet:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

Nach dem Entfernen dieser Zeile aus .bashrc und dem Neustart von WSL2 verhält sich pip wie erwartet. Ich bin mir nicht ganz sicher, ob dies jemanden in die richtige Richtung weist, da ich nicht sicher bin, wie ich von hier aus vorgehen soll.

Es scheint, als ob ich das Problem dauerhaft beheben konnte, indem ich den Schlüsselring mit pip3 install -U keyring aktualisierte und dies sicherstellte
[backend]
default-keyring=keyring.backends.null.Keyring
wird in der Schlüsselring-Konfigurationsdatei auf ~/.config/python_keyring/keyringrc.cfg

Wunderbar, cjpelliccis Vorschlag von pip3 install -U keyring hat es geschafft.
Ich musste auch ~/.local/share/python_keyring/keyringrc.cfg auf ~/.config/share/python_keyring/keyringrc.cfg .
Das Ausführen von pip3 list dauert jetzt 1/2 Sekunde anstatt 90 Sekunden.
Dies ist ohne X-Server ausgeführt.

Das obige scheint bei mir nicht zu funktionieren. Es gibt weder in ~ / .local / share / python_keyring / noch in ~ / .config / share / python_keyring / einen keyringrc.cfg.

Könnte dies ein anderes Verhalten zwischen WSL Ubuntu und Ubuntu sein?

@peidaqi , nach dem Aktualisieren des Schlüsselbunds möchten Sie möglicherweise versuchen, die Konfigurationsdatei mit genau diesem Namen im Verzeichnis ~/.config/python_keyring/ zu erstellen und dann Folgendes in die Konfigurationsdatei aufzunehmen:
[backend]
default-keyring=keyring.backends.null.Keyring

Ich glaube, dass keyringrc.cfg kann, nachdem Sie die obigen Schritte ausgeführt haben, um den Schlüsselring durch Festlegen einer Umgebungsvariablen zu deaktivieren, aber ich könnte mich irren.

Übrigens: Ich verwende Ubuntu auch auf WSL2.

Hallo! Ich hatte mehr oder weniger das gleiche Problem mit pip list das langsam lief (~ 1 min), einschließlich aller pip install -Befehle, die ich ausführen wollte (auf wsl2). Ich bin mir jedoch nicht sicher, ob das Verhalten genau das gleiche war (pip list _did_ gab die Pakete aus, aber der Befehl würde nach ~ 1 min zurückkehren).

Was mein Problem schließlich löste, war Folgendes: https://askubuntu.com/a/38468/938540 - Ich bin nicht sicher, ob die Probleme zusammenhängen, aber die Symptome waren sehr ähnlich. Hoffe das hilft!

Hinzufügen eines weiteren möglichen Datenpunkts:
pip list dauerte unter WSL2 ungefähr 90 Sekunden.
Ich habe die Umgebungsvariable DISPLAY auf einen X-Server gesetzt, der unter dem Windows-Desktop ausgeführt wird. Durch Löschen der Umgebungsvariablen DISPLAY oder Starten meines X-Servers wurde die Zeit auf 0,343 Sekunden geändert.

Es scheint, als ob ich das Problem dauerhaft beheben konnte, indem ich den Schlüsselring mit pip3 install -U keyring aktualisierte und dies sicherstellte
[backend]
default-keyring=keyring.backends.null.Keyring
wird in der Schlüsselring-Konfigurationsdatei auf ~/.config/python_keyring/keyringrc.cfg

Das ist für mich in Ordnung.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Es scheint, als ob ich das Problem dauerhaft beheben konnte, indem ich den Schlüsselring mit pip3 install -U keyring aktualisierte und dies sicherstellte
[backend]
default-keyring=keyring.backends.null.Keyring
wird in der Schlüsselring-Konfigurationsdatei auf ~/.config/python_keyring/keyringrc.cfg

Das ist für mich in Ordnung.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Das zu bestätigen funktioniert auch bei mir.

Ubuntu 18.04
Python 3.6.8
pip 20.2.3

Hallo Leute, wir brauchen keine weiteren Berichte, die bestätigen, dass das Deaktivieren des Schlüsselbunds die Benutzer beschleunigen würde. Wir würden uns freuen, wenn sich jemand melden würde, um mit https://github.com/pypa/pip/issues/8719 zu helfen. :) :)

Dies tritt bei mir auf, wenn ich auf Fedora 33 in Wayland laufe! Ich hoffe, dies ist eine nützliche Ergänzung, auch als Kommentar von mir, da alle anderen auf der WSL zu sein scheinen.

Umgebung

• pip 20.2.2 von /usr/lib/python3.9/site-packages/pip (Python 3.9)
• Python 3.9.0
• OS: Fedora 33
• Desktop-Umgebung: swaywm (wayland tiling wm), gestartet über gdm

zeitgesteuerte Ausführung von pip und 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

Danke für die Berichte hier. Es ist jetzt klar, dass dies aufgrund der Schlüsselringintegration von pip geschieht. # 8687 würde die Wahrscheinlichkeit, dass Pip nach Dingen im Schlüsselring sucht, erheblich verringern, und # 8719 würde dies zu einem Opt-In machen.

Zur Information der Benutzer kann das Importieren des Schlüsselringmoduls in irgendetwas zu langen Verzögerungen in der richtigen Umgebung führen, unabhängig davon, ob Code jemals explizit Schlüsselringfunktionen aufruft oder nicht. Dies kann durch Timing eines Imports gesehen werden: time python3 -c "import keyring" . Für mich dauert dies ungefähr 25 Sekunden auf einem Fedora 32-Computer, bei dem ich remote angemeldet bin und der keine grafische Anmeldesitzung hat.

Für mich ist die direkte Ursache dafür, dass der Schlüsselring beim Import Code ausführt, der schließlich versucht, eine DBus-Verbindung zu org.kde.kwalletd5 herzustellen, und dies schlägt sehr langsam fehl. Sie können den Grundcode duplizieren (und den Stall reproduzieren) mit:

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

Im Schlüsselring selbst befindet sich dieser Code in der Methode priority() in keyring / backends / kwallet.py. Wenn kwalletd noch nicht ausgeführt wird und nicht gestartet werden kann, scheint dies eine lange Zeitüberschreitung in DBus selbst oder den Python-DBus-Bibliotheken zu erfordern.

Dies bedeutet, dass der gesamte Import des Schlüsselringmoduls von jedem Befehlszeilenflag abhängig gemacht und gesteuert werden muss, nicht nur von dessen Verwendung.

Zur Information der Leute kann der Import des Schlüsselringmoduls in irgendetwas zu langen Verzögerungen in der richtigen Umgebung führen

Danke für diese Information. Es klingt nach einem großen Problem mit dem Schlüsselringmodul selbst - Importe sollen billig sein. Wurde es dort als Fehler gemeldet? Ich denke, unser Plan für Pip reicht aus, um das Schlimmste dieses Verhaltens zu mildern, aber letztendlich denke ich, dass es den Betreuern des Schlüsselbunds obliegt, dies zu beheben.

Wenn jemand einen Link zu einem Fehlerbericht gegen Schlüsselbunde erstellen kann, wäre dies großartig, damit wir überwachen können, was er tut, und Pip-Benutzern Ratschläge geben können, die davon betroffen sind.

FWIW, eine Problemumgehung für Benutzer, die dies tun, ist das Deaktivieren des Schlüsselbunds, wie hier dokumentiert: https://github.com/jaraco/keyring#disabling -keyring

Wurde es dort als Fehler gemeldet? ich

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