Pip: كل أمر واحد من النقطة يعمل ببطء شديد

ما الذي تشير إليه بعبارة "اعتادت على"؟ هل يحدث هذا التباطؤ بسبب ترقية النقطة أو ترقية النظام؟ إذا حدث ذلك من العدم ، فمن المحتمل جدًا ألا تكون مشكلة نقطة ، ولكن شيئًا ما يحدث على جهازك الخاص ، والذي لا تتحكم النقطة فيه.

لا ، لم أقم بأي ترقية للنقطة. يقوم Windows 10 بإجراء تحديثات متكررة ولكن لا يمكنني أن أفهم كيف يؤثر ذلك على الأداء باستخدام نقطة داخل WSL2.

آمل أن يوجهني أحدهم اتجاهًا حول كيفية تتبع هذه المشكلة. في الوقت الحالي ، لا تُخرج النقطة أي رسائل خطأ ، لذا لا توجد طريقة لمعرفة ما يحدث.

هل يمكنك مشاركة عدد الحزم المثبتة بالفعل (أي ناتج pip list )؟ قد يكون مرتبطًا بمنطق النقطة الداخلي [1] الذي حاول إلقاء نظرة على جميع الحزم المثبتة قبل أي معالجة إخراج.

[1] بناء مجموعة العمل pkg_resources عند التحميل ، لأولئك الذين يتساءلون عما أتحدث عنه

نفس المشكلة معي ايضا قمت بتشغيل الأمر pip3 list واستغرق الأمر حوالي 10 ثوانٍ لإدراج الحزم. في الوقت الحالي ، أقوم بإنشاء بيئة افتراضية باستخدام pipenv مما يزيل المشكلة. أعتقد أنه قد يتداخل مع مشاركة الملفات التنفيذية بين wsl2 linux و windows. لست متأكدًا من مصدر المشكلة رغم ذلك!

أعتقد أنه قد يتداخل مع مشاركة الملفات التنفيذية بين wsl2 linux و windows

هذا يبدو معقولاً. يكون أداء نظام ملفات WSL2 سيئًا إذا قمت بالوصول إلى نظام ملفات Windows من جانب Linux. ما هي لغة Python المرتبطة بأمر pip3 ؟ هل يمكنك تقديم sys.path ؟ هل يحدث هذا إذا قمت بتشغيل pip3 في موقع مختلف؟ هل يهم ما إذا كان الموقع في نظام ملفات Linux أو في جانب Windows؟

إذا قمنا بتشغيل نفس pip3 list على windows powerhell ، فهو فوري ولا تحدث المشكلة.

مسار Sys بدون تنشيط بيئة pipenv

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

تم تنشيط مسار Sys مع بيئة pipenv

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

قد يكون من الممكن إذا تم تغيير مسار sys للعامة ، فلن يتداخل pip3 مع windows one. أنا لم أجربها!

حسنًا ، لا يبدو أي من الدلائل خارج عن المألوف. هل تصادف تحميل أي من أدلة Windows؟ على سبيل المثال ، هل تقوم بربط الدليل الرئيسي الخاص بك (أو أي شيء مدرج في sys.path ) بدليل Windows؟ أو هل تقوم بتشغيل الأمر في دليل تحت /mnt ؟

ربما أحاول مؤقتًا نقل بعض الإدخالات المدرجة في sys.path بعيدًا (خاصة ~/.local/lib واحد) ومعرفة ما إذا كان هذا يغير أي شيء. أو ربما يمكنك فقط إدخال بعض المحولات في وقت تشغيل Python ومعرفة ما الذي يبطئ الأمور بالضبط. هناك العديد من الحيل التي يمكنك القيام بها لعزل المشكلة. سيكون ذلك أكثر فائدة مني (أو أي شخص ليس لديه وصول مادي إلى جهازك) في محاولة استكشاف الأخطاء وإصلاحها ضد الهواء.

تحرير: قد يتم ربط هذا بطريقة ما بالشاشة؟ يختفي التباطؤ إلى حد كبير (يستغرق 0.5 ثانية) عند بدء تشغيل خادم X11 (باستخدام MobaXterm). السبب في أنني وجدت هذه المشكلة هو أن matplotlib كان بطيئًا للغاية لذا حاولت استخدام pip لإعادة التثبيت. لقد نسيت أنني بحاجة إلى تشغيل Xterm لاستخدام matplotlib.

لقد واجهت أيضًا هذه المشكلة ولدي نفس الناتج من sys.path مثل piyushchauhan2011. لدي ارتباط رمزي في دليلي الرئيسي إلى دليل Windows مثل ذلك
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

أنا أقوم بتطوير حزمة بايثون يجب أن يتم تقييم نتائجها مقابل برنامج لا يمكن تشغيله إلا في بيئة يونكس. أستخدم اختبارًا ساميًا لتحرير الملفات الموجودة في دليل windows واستخدم WSL2 لتشغيل رمز الاختبار على تلك الملفات من خلال الارتباط الرمزي.

يمكنني تشغيل الأوامر التالية بدون أي تباطؤ: check, show, config
أنا أستخدم pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

يؤدي تشغيل pip3 list إرجاع نتيجة ولكن يستغرق حوالي 30 ثانية.
لدي حوالي 100 حزمة مثبتة.

حاولت ما يلي دون أي نجاح
python3 -m pip --retries 2 --timeout 5 --no-cache-dir --isolated --verbose list
لقد حاولت تشغيل النقطة داخل نظام ملفات WSL2 وعلى جانب Windows يعاني كل منهما من نفس التباطؤ.

لست 100٪ أفضل طريقة لتغيير sys.path لكن هذه هي محاولتي:
لقد أطلقت ipython3 الذي يبدأ بـ sys.path من:

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

الذي احتفظ بنسخة احتياطية منه على النحو التالي backup = sys.path.copy()
في هذه المرحلة ، أكدت أنه إذا استخدمت run '/usr/bin/pip3' list ما زلت أواجه التباطؤ.
ومع ذلك ، عندما قمت بعد ذلك بتعيين sys.path = [] وتشغيلها مرة أخرى ، أحصل على ModuleNotFoundError: No module named 'pyparsing' . تتكرر هذه النتيجة في كل مرة أركض فيها مرة أخرى. لكن! بمجرد تعيين sys.path = backup الآن run '/usr/bin/pip3' list يعمل بأعجوبة!
ناتج استخدام time :

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

لذلك من الواضح أن هناك خطأ ما في المسارات.
بعد ذلك يمكنني تعيين sys.path =[] و run '/usr/bin/pip3' list لا يزال يعمل لسبب ما.

لست متأكدًا مما إذا كان هذا مناسبًا ولكني اعتقدت أنني سأذكره:
بعد استخدام الأمر run يتم ملء sys.path الخاص بي على النحو التالي (بعد تعيينه على قائمة فارغة)

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

الذي لا يزال يعاني من التباطؤ حتى يتم تعيين sys.path على قائمة فارغة ثم إعادة تعيينه إلى القائمة الأصلية أو هذه القائمة.

قد يتم ربط هذا بطريقة ما بالشاشة؟ يختفي التباطؤ إلى حد كبير (يستغرق 0.5 ثانية) عند بدء تشغيل خادم X11 (باستخدام MobaXterm). السبب في أنني وجدت هذه المشكلة هو أن matplotlib كان بطيئًا للغاية لذا حاولت استخدام pip لإعادة التثبيت. لقد نسيت أنني بحاجة إلى تشغيل Xterm لاستخدام matplotlib.

يمكن…؟ القضية تماما غريبة جدا بالنسبة لي. إذا كانت هذه مشكلة sys.path ، ألن يحدث نفس التباطؤ لجميع واردات Python ، وليس مجرد نقطة؟ أنا محتار جدا 😞

مرحبًا ، بيئتي هي:

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

باستخدام Python 3.6.9 و pip 9.0.1 ويمكنني أن أؤكد أن النقطة بطيئة للغاية مع كل command (خاصة مع install )

pip3 list هو

asn1crypto (0.24.0)
attrs (17.4.0)
Automat (0.6.0)
chardet (3.0.4)
configobj (5.0.6)
constantly (15.1.0)
cryptography (2.1.4)
distro-info (0.18ubuntu0.18.04.1)
hyperlink (17.3.1)
idna (2.6)
incremental (16.10.1)
keyring (10.6.0)
keyrings.alt (3.0)
netifaces (0.10.4)
pip (9.0.1)
pyasn1 (0.4.2)
pyasn1-modules (0.2.1)
pycrypto (2.6.1)
pygobject (3.26.1)
pyOpenSSL (17.5.0)
python-apt (1.6.5+ubuntu0.3)
python-debian (0.1.32)
pyxdg (0.25)
PyYAML (3.12)
SecretStorage (2.3.1)
service-identity (16.0.0)
setuptools (39.0.1)
six (1.11.0)
Twisted (17.9.0)
ufw (0.36)
unattended-upgrades (0.1)
wheel (0.30.0)

MattiaFailla إذا كنت تريد إصلاحًا مؤقتًا ، فإنني أوصي بتشغيل خادم X11 مثل MobaXterm (أو أي ما يعادله). لا أفهم السبب ، لكنه أصلح مشكلة تباطؤي لجميع الأوامر.

ngraymon هذا غريب لكنني سأحاول هذا الإصلاح المؤقت.
شكر!
سوف أقوم بتحديث هذه المشكلة بمجرد المحاولة.

فقط لتأكيد أن السلوك لا يزال هو نفسه الذي راجعته للتو:

تشغيل time pip3 list داخل Windows Terminal على WSL2:

بعد بدء MobaXterm وتشغيل time pip3 list في نفس المحطة:

ngraymon مرحبا ،
لقد قمت بحل المشكلة ، يرجى تجربة الخطوات التالية:

• لا تقم بتشغيل أوامر النقطة باستخدام sudo
• تحديث apt && apt-Upgrade
• أعد تشغيل الخادم / الكمبيوتر
• انتبه جيدًا إلى عامل الميناء ، لاحظت الليلة الماضية أن عملية python3 كانت تستخدم بشكل مكثف من قبل السرب

تضمين التغريدة
أنا سعيد لأنك حللت مشكلتك.
لقد جربت اقتراحاتكم لكنها لم تحل المشكلة.
لا أقوم بتشغيل النقطة باستخدام sudo ، لكنني قمت بتثبيت pip3 باستخدام sudo apt install python3-pip ، فربما يكون ذلك مناسبًا؟
أنا سعيد بالطريقة التي تسير بها الأمور بنفسي حيث أحتاج إلى خادم X على أي حال لأنني أخطط باستخدام matplotlib.

ngraymon هل يمكنك تشغيل python -m pip ، ومعرفة ما إذا كان ذلك بطيئًا أيضًا؟

إذا كان الأمر كذلك ، وكان لديك إصدار جديد كافٍ من Python ، فيرجى تزويدنا بإخراج python -X importtime -m pip -v . إذا كان التباطؤ في الواردات ، فسيساعدنا ذلك على معرفة ذلك.

تضمين التغريدة
مرحبا،

قمت بتشغيل time python3 -m pip بدون أي أمر للنقطة والذي يرد برسالة المساعدة في هذا الوقت

ومع ذلك ، إذا قمت بتشغيل time python3 -m pip list

تشغيل time python3 -m pip check الذي لم يتأثر / لا يزال غير متأثر بالبطء

قمت بتشغيل ما يلي:

• python3 -X importtime -m pip -v والمرفق ذلك كـ out_1.txt

• python3 -X importtime -m pip -v list والمرفق ذلك كـ out_list.txt

• python3 -X importtime -m pip -v check والمرفق ذلك كـ out_check.txt

يبدو أن سبب الأمر list هو keyring.core ؟
import time: 96023197 | 96029594 | keyring.core

نأمل أن يكون هذا مفيدًا :)

يبدو أن الجاني لأمر القائمة هو keyring.core؟

بالاقتران مع الشيء الغريب حول وجود خادم X يساعد ، أتساءل عما إذا كانت حلقة المفاتيح تعتمد على واجهة المستخدم الرسومية ، وهناك بعض الكود الذي يحاول العثور على X ويسبب تأخيرًا حتى يخلص إلى عدم وجود واحد؟

تضمين التغريدة
استنادًا إلى صفحتهم في

لقد جربت python3 -m keyring --disable و export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring ولكن لا يبدو أن أيًا منهما يصلح المشكلة.

jaraco / keyring # 434 يبدو مرتبطًا ، لكن النصيحة هناك بشأن تعطيل النقاط في المستندات والتي تنص على ما جربته بالفعل.

تواجه هذه المشكلة أيضًا ، أعتقد أنها بدأت بعد تشغيل روتين sudo apt-get update && sudo apt-get upgrade أمس. إنه مرتبط بالتأكيد بحلقة المفاتيح والعرض بطريقة ما. بالإضافة إلى إصلاح تشغيل X-Server ، تمكنت من إصلاح المشكلة عن طريق إزالة السطر الذي كان لدي في ملف .bashrc الخاص بي الذي يوجه العرض إلى عنوان IP الخاص بـ WSL2. السطر المعني هو:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

بعد إزالة هذا الخط من .bashrc وإعادة تشغيل WSL2 ، تتصرف النقطة كما هو متوقع. لست متأكدًا تمامًا مما إذا كان هذا يشير إلى أي شخص في الاتجاه الصحيح ، لأنني لست متأكدًا من كيفية المضي قدمًا من هنا.

يبدو كما لو أنني تمكنت من إصلاح المشكلة بشكل دائم عن طريق تحديث keyring بـ pip3 install -U keyring والتأكد من ذلك
[backend]
default-keyring=keyring.backends.null.Keyring
تم تعيينه في ملف تهيئة حلقة المفاتيح على ~/.config/python_keyring/keyringrc.cfg

رائع ، اقتراح cjpellicci لـ pip3 install -U keyring أفلح.
اضطررت أيضًا إلى نقل ~/.local/share/python_keyring/keyringrc.cfg إلى ~/.config/share/python_keyring/keyringrc.cfg .
يستغرق تشغيل pip3 list نصف ثانية الآن بدلاً من 90 ثانية.
هذا بدون تشغيل أي خادم X.

ما ورد أعلاه لا يبدو أنه يعمل بالنسبة لي. لا يوجد keyringrc.cfg إما في ~ / .local / share / python_keyring / أو ~ / .config / share / python_keyring /.

هل يمكن أن يكون هذا سلوكًا مختلفًا بين WSL Ubuntu و Ubuntu؟

peidaqi ، بعد تحديث keyring ، قد ترغب في محاولة إنشاء ملف التكوين بهذا الاسم الدقيق في الدليل ~/.config/python_keyring/ ، ثم إضافة ما يلي إلى ملف التكوين:
[backend]
default-keyring=keyring.backends.null.Keyring

أعتقد أن keyringrc.cfg قد يتم إجراؤه بعد اتباع الخطوات المذكورة أعلاه لتعطيل keyring عن طريق تعيين متغير بيئة ، ولكن قد أكون مخطئًا.

راجع للشغل: أنا أقوم بتشغيل Ubuntu على WSL2 أيضًا.

مرحبا! كنت أواجه نفس المشكلة تقريبًا مع بطء تشغيل pip list (حوالي دقيقة واحدة) بما في ذلك أي أمر pip install كنت أحاول تشغيله (على wsl2). ومع ذلك ، لست متأكدًا مما إذا كان السلوك هو نفسه تمامًا (قائمة pip _did_ إخراج الحزم ولكن الأمر سيعود بعد دقيقة واحدة تقريبًا).

ما حل مشكلتي أخيرًا هو: https://askubuntu.com/a/38468/938540 - لست متأكدًا من أن المشكلات مرتبطة ، لكن الأعراض كانت متشابهة جدًا. أتمنى أن يساعدك هذا!

إضافة نقطة بيانات أخرى محتملة:
استغرق pip list حوالي 90 ثانية في WSL2.
كنت أقوم بتعيين متغير بيئة العرض إلى خادم X يعمل تحت سطح مكتب Windows. أدى مسح متغير بيئة العرض أو بدء تشغيل خادم X إلى تغيير الوقت إلى 0.343 ثانية.

يبدو كما لو أنني تمكنت من إصلاح المشكلة بشكل دائم عن طريق تحديث keyring بـ pip3 install -U keyring والتأكد من ذلك
[backend]
default-keyring=keyring.backends.null.Keyring
تم تعيينه في ملف تهيئة حلقة المفاتيح على ~/.config/python_keyring/keyringrc.cfg

هذا يناسبني.

نظام التشغيل Ubuntu 18.04
بايثون 3.6.9
نقطة 20.0.2

يبدو كما لو أنني تمكنت من إصلاح المشكلة بشكل دائم عن طريق تحديث keyring بـ pip3 install -U keyring والتأكد من ذلك
[backend]
default-keyring=keyring.backends.null.Keyring
تم تعيينه في ملف تهيئة حلقة المفاتيح على ~/.config/python_keyring/keyringrc.cfg

هذا يناسبني.

نظام التشغيل Ubuntu 18.04
بايثون 3.6.9
نقطة 20.0.2

التأكيد على هذا يعمل بالنسبة لي أيضًا.

نظام التشغيل Ubuntu 18.04
بايثون 3.6.8
نقطة 20.2.3

مرحبًا يا رفاق - لسنا بحاجة إلى مزيد من التقارير التي تؤكد أن تعطيل حلقة المفاتيح سيعطي المستخدمين تسريعًا. سنكون ممتنين إذا تقدم شخص ما للمساعدة في https://github.com/pypa/pip/issues/8719. :)

يحدث هذا بالنسبة لي عند الجري في wayland على Fedora 33! آمل أن تكون هذه إضافة مفيدة حتى لو كنت أعلق أيضًا ، حيث يبدو أن جميع الآخرين موجودون على WSL.

بيئة

• نقطة 20.2.2 من /usr/lib/python3.9/site-packages/pip (python 3.9)
• بايثون 3.9.0
• نظام التشغيل: Fedora 33
• بيئة سطح المكتب: swaywm (wayland tiling wm) ، بدأ عبر gdm

التنفيذ الموقوت لـ pip و 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

شكرا للتقارير هنا. من الواضح الآن أن هذا يحدث بسبب تكامل سلسلة مفاتيح النقطة. # 8687 من شأنه أن يجعل النقطة أقل احتمالاً للبحث عن الأشياء في حلقة المفاتيح ، بينما # 8719 سيجعل ذلك اختيارًا.

بالنسبة لمعلومات الأشخاص ، يمكن أن يتسبب استيراد وحدة keyring إلى أي شيء في توقف طويل في البيئة المناسبة ، سواء أكان الرمز يستدعي وظائف keyring أم لا. يمكن ملاحظة ذلك من خلال توقيت الاستيراد: time python3 -c "import keyring" . بالنسبة لي ، يستغرق هذا 25 ثانية أو ما إلى ذلك على جهاز Fedora 32 الذي قمت بتسجيل الدخول إليه عن بُعد ولا يحتوي على جلسة تسجيل دخول رسومية.

بالنسبة لي ، السبب المباشر لذلك هو أن حلقة المفاتيح تقوم بتشغيل التعليمات البرمجية عند الاستيراد والتي تحاول في النهاية إجراء اتصال DBus بـ org.kde.kwalletd5 وهذا يفشل ببطء شديد. يمكنك نسخ الكود الأساسي (وإعادة إنتاج الكشك) باستخدام:

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

في keyring نفسه ، يكون هذا الرمز في keyring / backends / kwallet.py ، في طريقة priority() . إذا لم يكن kwalletd قيد التشغيل بالفعل ولا يمكن بدء تشغيله ، يبدو أن هذا يتطلب مهلة طويلة داخل DBus نفسه أو مكتبات Python DBus.

هذا يعني أن الاستيراد الكامل لوحدة حلقة المفاتيح يجب أن يكون مشروطًا وبوابة على أي علامة سطر أوامر ، وليس فقط استخدامها.

لمعلومات الأشخاص ، يمكن أن يتسبب استيراد وحدة keyring في أي شيء في توقف طويل في البيئة المناسبة

شكرا لهذه المعلومات. يبدو أنه مشكلة كبيرة في وحدة keyring نفسها - من المفترض أن تكون الواردات رخيصة. هل أثير على أنه حشرة هناك؟ أعتقد أن خطتنا للنقطة كافية للتخفيف من أسوأ ما في هذا السلوك ، ولكن في النهاية أعتقد أن إصلاح هذا يرجع إلى المشرفين على سلسلة المفاتيح.

إذا تمكن شخص ما من الارتباط بتقرير خطأ ضد حلقة المفاتيح ، فسيكون ذلك رائعًا حتى نتمكن من مراقبة ما يفعله وتقديم المشورة لمستخدمي النقطة الذين يصطدمون بهذا.

FWIW ، الحل البديل للمستخدمين الذين يقومون بضرب هذا هو تعطيل keyring ، كما هو موثق هنا: https://github.com/jaraco/keyring#disopped -keyring

هل أثير على أنه حشرة هناك؟ أنا

نعم: https://github.com/jaraco/keyring/issues/403