Pip: Setiap perintah tunggal dari pip berjalan sangat lambat

Apa yang Anda maksud dengan "dulu"? Apakah perlambatan ini terjadi karena peningkatan pip atau peningkatan sistem? Jika terjadi tiba-tiba, kemungkinan besar itu bukan masalah pip, tetapi sesuatu terjadi pada mesin Anda, yang tidak dapat dikontrol oleh pip.

Tidak, saya tidak melakukan peningkatan pip apa pun. Windows 10 memang sering melakukan pembaruan tetapi saya tidak dapat memahami bagaimana ini memengaruhi kinerja dengan pip di dalam WSL2.

Saya berharap seseorang dapat mengarahkan saya tentang bagaimana saya bahkan dapat melacak masalah ini. Saat ini pip tidak menampilkan pesan kesalahan apa pun jadi tidak ada cara untuk mengetahui apa yang terjadi.

Bisakah Anda membagi berapa banyak paket yang telah diinstal (misalnya, keluaran pip list )? Ini mungkin terkait dengan logika internal pip [1] yang mencoba melihat semua paket yang diinstal sebelum pemrosesan keluaran.

[1] Konstruksi WorkingSet pkg_resources sedang dimuat, bagi mereka yang bertanya-tanya apa yang saya bicarakan

Masalah yang sama dengan saya juga. Saya menjalankan perintah pip3 list dan butuh sekitar 10+ detik untuk mendaftar paket. Untuk saat ini saya membuat lingkungan virtual menggunakan pipenv yang menghilangkan masalah. Saya pikir itu mungkin mengganggu berbagi executable antara wsl2 linux dan windows. Saya tidak yakin apa sumber masalahnya!

Saya pikir itu mungkin mengganggu berbagi executable antara wsl2 linux dan windows

Kedengarannya masuk akal. Kinerja sistem berkas WSL2 buruk jika Anda mengakses sistem berkas Windows dari sisi Linux. Apa Python yang terkait dengan perintah pip3 ? Bisakah Anda memberikan sys.path ? Apakah ini terjadi jika Anda menjalankan pip3 di lokasi yang berbeda? Apakah penting jika lokasinya ada di sistem file Linux atau di sisi Windows?

Jika kita menjalankan pip3 list di windows PowerShell, itu instan dan masalah tidak terjadi.

Jalur sys tanpa lingkungan pipenv diaktifkan

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

Jalur Sys dengan lingkungan pipenv diaktifkan

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

Bisa jadi jika jalur sys diubah untuk global, maka pip3 tidak akan mengganggu windows one. Saya belum mencobanya!

Hmm, tidak ada direktori yang tampak luar biasa. Apakah Anda kebetulan memasang direktori Windows? Misalnya, apakah Anda menghubungkan direktori home Anda (atau apapun yang terdaftar di sys.path ) ke direktori Windows? Atau apakah Anda menjalankan perintah dalam direktori di bawah /mnt ?

Saya mungkin akan mencoba untuk sementara memindahkan beberapa entri yang terdaftar di sys.path (terutama ~/.local/lib satu) dan melihat apakah itu mengubah sesuatu. Atau mungkin Anda bisa memasukkan beberapa profiler ke dalam runtime Python dan melihat apa sebenarnya yang memperlambat segalanya. Ada banyak trik yang bisa Anda lakukan untuk mengisolasi masalahnya. Itu akan jauh lebih berguna daripada saya (atau siapa pun tanpa akses fisik ke mesin Anda) mencoba memecahkan masalah dengan masalah udara tipis.

Sunting: Ini entah bagaimana dapat dihubungkan ke layar? Perlambatan sebagian besar hilang (membutuhkan 0,5 detik) ketika saya memulai server X11 (menggunakan MobaXterm). Alasan saya menemukan masalah ini adalah matplotlib sangat lambat jadi saya mencoba menggunakan pip untuk menginstal ulang. Saya lupa bahwa saya perlu menjalankan Xterm untuk menggunakan matplotlib.

Saya juga mengalami masalah ini dan memiliki output yang sama dari python sys.path sebagai piyushchauhan2011. Saya memiliki symlink di direktori home saya ke direktori Windows seperti itu
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

Saya sedang mengembangkan paket python yang hasilnya harus ditandai dengan program yang hanya dapat berjalan di lingkungan unix. Saya menggunakan uji luhur untuk mengedit file di direktori windows saya dan menggunakan WSL2 untuk menjalankan kode benchmark pada file tersebut melalui symlink.

Saya dapat menjalankan perintah berikut tanpa perlambatan apa pun: check, show, config
Saya menggunakan pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

Menjalankan pip3 list memang mengembalikan hasil tetapi membutuhkan ~ 30 detik.
Saya memiliki sekitar 100 paket yang diinstal.

Saya mencoba yang berikut ini tetapi tidak berhasil
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
Saya telah mencoba menjalankan pip baik di dalam sistem file WSL2 dan di sisi Windows masing-masing mengalami perlambatan yang sama.

Saya tidak 100% cara terbaik untuk mengubah sys.path tetapi inilah upaya saya:
Saya meluncurkan ipython3 yang dimulai dengan sys.path dari:

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

Yang saya backup sebagai berikut backup = sys.path.copy()
Pada titik ini saya menegaskan bahwa jika saya menggunakan run '/usr/bin/pip3' list saya masih mengalami perlambatan.
Namun, ketika setelah itu saya menetapkan sys.path = [] dan menjalankan lagi saya mendapatkan ModuleNotFoundError: No module named 'pyparsing' . Hasil ini berulang setiap kali saya menjalankan lagi. TAPI! Setelah saya menetapkan sys.path = backup sekarang run '/usr/bin/pip3' list bekerja secara ajaib!
Output dari menggunakan time :

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

Jadi jelas ada yang salah dengan jalannya.
Setelah itu saya dapat mengatur lagi sys.path =[] dan run '/usr/bin/pip3' list masih berfungsi karena beberapa alasan.

Saya tidak yakin apakah ini relevan tetapi saya pikir saya akan menyebutkannya:
Setelah menggunakan perintah run sys.path saya akan terisi sebagai berikut (setelah disetel ke daftar kosong)

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

Yang masih mengalami perlambatan hingga sys.path diatur ke daftar kosong dan kemudian reset kembali ke daftar asli atau daftar ini.

Ini entah bagaimana dapat dihubungkan ke layar? Perlambatan sebagian besar hilang (membutuhkan 0,5 detik) ketika saya memulai server X11 (menggunakan MobaXterm). Alasan saya menemukan masalah ini adalah matplotlib sangat lambat jadi saya mencoba menggunakan pip untuk menginstal ulang. Saya lupa bahwa saya perlu menjalankan Xterm untuk menggunakan matplotlib.

Mungkin…? Masalah sepenuhnya sangat aneh bagi saya. Jika ini adalah masalah sys.path , bukankah perlambatan yang sama akan terjadi untuk semua impor Python, bukan hanya pip? Saya cukup bingung 😞

Halo, lingkungan saya adalah:

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

Dengan Python 3.6.9 dan pip 9.0.1 dan saya dapat mengonfirmasi bahwa pip sangat lambat dengan setiap command (terutama dengan install )

pip3 list adalah

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 Jika Anda menginginkan perbaikan _ sementara_ saya sarankan menjalankan server X11 seperti MobaXterm (atau yang setara lainnya). Saya tidak mengerti mengapa , tetapi itu memperbaiki masalah perlambatan saya untuk semua perintah.

@ngraymon itu aneh tapi saya akan mencoba perbaikan suhu ini.
Terima kasih!
Saya akan memperbarui masalah ini setelah mencoba.

Hanya untuk mengonfirmasi bahwa perilakunya masih sama, saya baru saja memeriksa:

Menjalankan time pip3 list di dalam Terminal Windows di WSL2:

Setelah memulai MobaXterm dan menjalankan time pip3 list di terminal yang sama:

@jamur_kejang
Saya telah menyelesaikan masalah, coba langkah-langkah berikut:

• Jangan menjalankan perintah pip dengan sudo
• apt-update && apt-upgrade
• Mulai ulang server / komputer
• Perhatikan baik-baik buruh pelabuhan, tadi malam saya perhatikan bahwa proses python3 sedang gencar digunakan oleh gerombolan

@Bayu_joo
Saya senang Anda menyelesaikan masalah Anda.
Saya mencoba saran Anda tetapi tidak menyelesaikan masalah.
Saya tidak menjalankan pip dengan sudo, tetapi saya menginstal pip3 menggunakan sudo apt install python3-pip , mungkin itu relevan?
Saya senang dengan keadaan untuk diri saya sendiri karena saya memerlukan server X karena saya merencanakan menggunakan matplotlib.

@ngraymon dapatkah Anda menjalankan python -m pip, dan lihat apakah itu juga lambat?

Jika ya, dan Anda memiliki versi Python yang cukup baru, berikan output python -X importtime -m pip -v . Jika perlambatan terjadi pada impor, ini akan membantu kami mengetahui.

@tokopedia
Halo,

Saya menjalankan time python3 -m pip tanpa perintah apa pun untuk pip yang membalas dengan pesan bantuan saat ini

Namun jika saya menjalankan time python3 -m pip list

Menjalankan time python3 -m pip check yang belum / masih tidak terpengaruh oleh perlambatan

Saya menjalankan yang berikut ini:

• python3 -X importtime -m pip -v dan dilampirkan sebagai out_1.txt

• python3 -X importtime -m pip -v list dan dilampirkan sebagai out_list.txt

• python3 -X importtime -m pip -v check dan dilampirkan sebagai out_check.txt

Tampaknya penyebab perintah list adalah keyring.core ?
import time: 96023197 | 96029594 | keyring.core

Semoga bermanfaat :)

Tampaknya penyebab perintah list adalah keyring.core?

Dikombinasikan dengan hal aneh seputar memiliki X server yang membantu, saya bertanya-tanya apakah keyring bergantung pada GUI, dan ada beberapa kode di sana yang mencoba menemukan X dan menyebabkan penundaan sampai disimpulkan bahwa tidak ada?

@prima
Berdasarkan halaman mereka di pypi , sepertinya itu membutuhkan D-Bus atau server X11?

Saya mencoba python3 -m keyring --disable dan export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring tetapi tampaknya tidak ada yang dapat memperbaiki masalah.

jaraco / keyring # 434 tampaknya terkait, tetapi saran di sana tentang menonaktifkan poin ke dokumen yang menyatakan apa yang sudah Anda coba.

Mengalami masalah ini juga, percayalah ini dimulai setelah menjalankan rutinitas sudo apt-get update && sudo apt-get upgrade kemarin. Ini pasti terkait dengan keyring dan tampilan entah bagaimana. Selain perbaikan menjalankan X-Server, saya dapat memperbaiki masalah dengan menghapus baris yang saya miliki di file .bashrc saya yang mengarahkan Tampilan ke Alamat IP WSL2. Garis yang dimaksud adalah:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

Setelah menghapus baris ini dari .bashrc dan memulai ulang WSL2, pip berperilaku seperti yang diharapkan. Tidak begitu yakin apakah ini mengarahkan seseorang ke arah yang benar, karena saya tidak yakin bagaimana melanjutkan dari sini.

Tampaknya saya dapat memperbaiki masalah secara permanen dengan memperbarui keyring dengan pip3 install -U keyring dan memastikannya
[backend]
default-keyring=keyring.backends.null.Keyring
diatur dalam file konfigurasi keyring pada ~/.config/python_keyring/keyringrc.cfg

Hebat, saran cjpellicci tentang pip3 install -U keyring berhasil.
Saya juga harus memindahkan ~/.local/share/python_keyring/keyringrc.cfg ke ~/.config/share/python_keyring/keyringrc.cfg .
Menjalankan pip3 list membutuhkan 1/2 detik sekarang, bukan 90 detik.
Ini tanpa server X yang berjalan.

Hal di atas sepertinya tidak berhasil untuk saya. Tidak ada keyringrc.cfg di ~ / .local / share / python_keyring / atau ~ / .config / share / python_keyring /.

Mungkinkah ini perilaku yang berbeda antara WSL Ubuntu dan Ubuntu?

@peidaqi , setelah memperbarui keyring Anda mungkin ingin mencoba membuat file konfigurasi dengan nama yang sama persis di direktori ~/.config/python_keyring/ , lalu menambahkan berikut ini ke dalam file konfigurasi:
[backend]
default-keyring=keyring.backends.null.Keyring

Saya percaya bahwa keyringrc.cfg dapat dibuat setelah mengikuti langkah-langkah di atas untuk menonaktifkan keyring dengan mengatur variabel lingkungan, tetapi saya bisa saja salah.

BTW: Saya juga menjalankan Ubuntu di WSL2.

Halo! Saya menghadapi masalah yang kurang lebih sama dengan pip list berjalan lambat (~ 1 menit) termasuk perintah pip install saya coba jalankan (di wsl2). Namun, saya tidak yakin apakah perilakunya persis sama (pip list _did_ mengeluarkan paket tetapi perintah akan kembali setelah ~ 1 menit).

Apa yang akhirnya memecahkan masalah saya adalah ini: https://askubuntu.com/a/38468/938540 - Saya tidak yakin masalah tersebut terkait, tetapi gejalanya sangat mirip. Semoga ini membantu!

Menambahkan titik data lain yang mungkin:
pip list membutuhkan waktu sekitar 90 detik di bawah WSL2.
Saya sedang mengatur variabel lingkungan DISPLAY ke server X yang berjalan di bawah desktop windows. Menghapus variabel lingkungan DISPLAY atau meluncurkan server X saya mengubah waktu menjadi 0,343s.

Tampaknya saya dapat memperbaiki masalah secara permanen dengan memperbarui keyring dengan pip3 install -U keyring dan memastikannya
[backend]
default-keyring=keyring.backends.null.Keyring
diatur dalam file konfigurasi keyring pada ~/.config/python_keyring/keyringrc.cfg

Itu berhasil untuk saya.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Tampaknya saya dapat memperbaiki masalah secara permanen dengan memperbarui keyring dengan pip3 install -U keyring dan memastikannya
[backend]
default-keyring=keyring.backends.null.Keyring
diatur dalam file konfigurasi keyring pada ~/.config/python_keyring/keyringrc.cfg

Itu berhasil untuk saya.

Ubuntu 18.04
Python 3.6.9
pip 20.0.2

Mengonfirmasi ini juga berhasil untuk saya.

Ubuntu 18.04
Python 3.6.8
pip 20.2.3

Halo semua - kami tidak memerlukan lebih banyak laporan yang mengonfirmasi bahwa menonaktifkan keyring akan mempercepat pengguna. Kami akan menghargai jika seseorang bersedia membantu dengan https://github.com/pypa/pip/issues/8719. :)

Ini terjadi pada saya saat berlari di wayland di Fedora 33! Berharap ini adalah tambahan yang berguna bahkan sebagai komentar saya juga, karena semua yang lain tampaknya ada di WSL.

Lingkungan Hidup

• pip 20.2.2 dari /usr/lib/python3.9/site-packages/pip (python 3.9)
• Python 3.9.0
• OS: Fedora 33
• lingkungan desktop: swaywm (wayland tiling wm), dimulai melalui gdm

eksekusi berjangka waktu pip dan 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

Terima kasih atas laporannya di sini. Sudah jelas sekarang bahwa ini terjadi karena integrasi keyring pip. # 8687 akan membuat pip secara signifikan lebih kecil kemungkinannya untuk mencari barang-barang di keyring dan # 8719 akan membuatnya menjadi pilihan.

Untuk informasi orang-orang, mengimpor modul keyring ke dalam apapun dapat menyebabkan kemacetan lama di lingkungan yang tepat, baik kode secara eksplisit memanggil fungsi keyring atau tidak. Ini dapat dilihat dengan mengatur waktu impor: time python3 -c "import keyring" . Bagi saya ini membutuhkan 25 detik atau lebih pada mesin Fedora 32 yang saya masuki dari jarak jauh dan yang tidak memiliki sesi login grafis.

Bagi saya, penyebab langsung dari ini adalah keyring menjalankan kode pada impor yang akhirnya mencoba membuat koneksi DBus ke org.kde.kwalletd5 dan ini gagal sangat lambat. Anda dapat menggandakan kode dasar (dan mereproduksi kios) dengan:

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

Dalam keyring itu sendiri, kode ini ada di keyring / backends / kwallet.py, dalam metode priority() . Jika kwalletd belum berjalan dan tidak dapat dimulai, ini tampaknya memerlukan waktu tunggu yang lama di dalam DBus itu sendiri atau perpustakaan Python DBus.

Ini menyiratkan bahwa seluruh impor modul keyring harus bersyarat dan memiliki gerbang pada tanda baris perintah apa pun, tidak hanya menggunakannya.

Untuk informasi orang-orang, mengimpor modul keyring menjadi apa saja dapat menyebabkan kemacetan lama di lingkungan yang tepat

Terima kasih atas informasi ini. Kedengarannya seperti masalah besar dengan modul keyring itu sendiri - impor dimaksudkan agar murah. Apakah telah dibesarkan sebagai bug di sana? Saya pikir rencana pip kami cukup untuk mengurangi perilaku terburuk ini, tetapi pada akhirnya saya berpikir bahwa memperbaikinya tergantung pada pengelola keyring.

Jika seseorang dapat menautkan ke laporan bug terhadap keyring, itu akan sangat bagus sehingga kami dapat memantau apa yang mereka lakukan dan memberikan saran kepada pengguna pip yang terkena ini.

FWIW, solusi bagi pengguna yang menekan ini adalah menonaktifkan keyring, seperti yang didokumentasikan di sini: https://github.com/jaraco/keyring#disabling -keyring

Apakah telah dibesarkan sebagai bug di sana? saya

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