Pip: पाइप से हर एक कमांड सुपर स्लो चलती है

क्या आप "यह करने के लिए इस्तेमाल किया" द्वारा उल्लेख कर रहे हैं? क्या यह मंदी एक पाइप अपग्रेड या सिस्टम अपग्रेड के कारण होती है? यदि यह कहीं से भी निकलता है, तो यह पाइप की समस्या नहीं है, लेकिन आपकी विशेष मशीन पर कुछ ऐसा हो रहा है, जिस पर पाइप का नियंत्रण नहीं है।

नहीं, मैंने कोई पाइप अपग्रेड नहीं किया। विंडोज 10 बार-बार अपडेट करता है, लेकिन मैं यह नहीं कह सकता कि यह WSL2 के अंदर पाइप के साथ प्रदर्शन को कैसे प्रभावित करता है।

मुझे उम्मीद है कि कोई मुझे इस दिशा में संकेत दे सकता है कि मैं इस समस्या का पता कैसे लगा सकता हूं। अभी पाइप किसी भी त्रुटि संदेश का उत्पादन नहीं करता है, ताकि यह पता न चले कि क्या हो रहा है।

क्या आप साझा कर सकते हैं कि कितने पैकेज पहले से स्थापित हैं (यानी pip list का आउटपुट)? यह पाइप के आंतरिक तर्क से संबंधित हो सकता है [1] जिसने किसी भी आउटपुट प्रोसेसिंग से पहले सभी स्थापित पैकेजों को देखने की कोशिश की।

[१] pkg_resources का कार्यभार लोड पर निर्माण, उन लोगों के लिए जो सोच रहे हैं कि मैं किस बारे में बात कर रहा हूं

मेरे साथ भी यही मुद्दा है। मैं pip3 list कमांड चलाता था और पैकेजों को सूचीबद्ध करने में लगभग 10+ सेकंड लगते थे। अभी के लिए मैं pipenv का उपयोग करके आभासी वातावरण बनाता हूं जो समस्या को दूर करता है। मुझे लगता है कि यह wsl2 linux और windows के बीच निष्पादन योग्य वस्तुओं के बंटवारे में हस्तक्षेप कर सकता है। मुझे यकीन नहीं है कि हालांकि समस्या का स्रोत क्या है!

मुझे लगता है कि यह wsl2 लिनक्स और खिड़कियों के बीच निष्पादन योग्य वस्तुओं के बंटवारे में हस्तक्षेप कर सकता है

यह प्रशंसनीय लगता है। यदि आप Windows फ़ाइल सिस्टम को लिनक्स पक्ष में एक्सेस करते हैं तो WSL2 का फाइल सिस्टम प्रदर्शन भयानक है। पायथन आपके pip3 कमांड से क्या संबंधित है? क्या आप इसके sys.path प्रदान कर सकते हैं? यदि आप pip3 को किसी भिन्न स्थान पर चलाते हैं, तो क्या ऐसा होता है? क्या यह मायने रखता है कि स्थान लिनक्स फाइल सिस्टम या विंडोज साइड में है?

अगर हम विंडोज़ पॉवरशेल पर समान pip3 list चलाते हैं, तो यह तुरंत हो जाता है और समस्या नहीं होती है।

बिना पिपेनव पर्यावरण के एसवाईएस पथ सक्रिय

['', '/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/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 एक के साथ हस्तक्षेप नहीं करेगा। मैंने इसे आजमाया नहीं है!

हम्म, निर्देशिका में से कोई भी सामान्य से बाहर नहीं लगता है। क्या आप किसी भी विंडोज निर्देशिका को माउंट करने के लिए होते हैं? उदाहरण के लिए, क्या आप अपने घर निर्देशिका (या sys.path में सूचीबद्ध कुछ) को विंडोज निर्देशिका से सहानुभूति देते हैं? या आप /mnt तहत एक निर्देशिका में कमांड चलाते हैं?

मैं शायद sys.path में सूचीबद्ध कुछ प्रविष्टियों को अस्थायी रूप से स्थानांतरित करने का प्रयास करूंगा (जासूसी रूप से ~/.local/lib एक) और देखें कि क्या कुछ भी बदलता है। या हो सकता है कि आप सिर्फ पायथन रनटाइम में कुछ प्रोफाइलर्स डाल सकते हैं और देख सकते हैं कि वास्तव में क्या चीजें धीमी हो रही हैं। समस्या को अलग करने के लिए आप कई तरकीबें अपना सकते हैं। यह पतली हवा के खिलाफ समस्या निवारण के लिए मेरे (या आपकी मशीन के लिए भौतिक उपयोग के बिना) किसी की तुलना में बहुत अधिक उपयोगी होगा।

संपादित करें: यह किसी भी तरह प्रदर्शन से जुड़ा हो सकता है? जब मैं एक X11 सर्वर (MobaXterm का उपयोग) शुरू करता हूं, तो मंदी काफी हद तक दूर हो जाती है (0.5 सेकंड लगते हैं)। इस समस्या का कारण मुझे पता था कि matplotlib सुपर धीमा था इसलिए मैंने पुनः स्थापित करने के लिए पाइप का उपयोग करने की कोशिश की। मैं भूल गया कि मुझे matplotlib का उपयोग करने के लिए एक Xterm चलाने की आवश्यकता है।

मुझे भी इस समस्या का सामना करना पड़ा है और मेरे अजगर के sys.path piyushchauhan2011 के रूप में एक ही आउटपुट है। मेरे पास अपनी होम डायरेक्टरी में एक सिमिलिंक है जैसे कि विंडोज डायरेक्टरी में
test -> /mnt/c/Users/<user>/Documents/<git_project_folder>/

मैं एक अजगर पैकेज विकसित कर रहा हूं, जिसके परिणामों को एक प्रोग्राम के खिलाफ बेंच मार्क करने की आवश्यकता है जो केवल एक यूनिक्स वातावरण में चल सकता है। मैं अपनी विंडोज़ निर्देशिका में फ़ाइलों को संपादित करने के लिए उदात्त परीक्षण का उपयोग करता हूं और सिमिलिंक के माध्यम से उन फाइलों पर बेंचमार्क कोड को चलाने के लिए 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 फाइलसिस्टम के अंदर और विंडोज साइड में दोनों को चलाने की कोशिश की है और उनमें से प्रत्येक एक ही मंदी से पीड़ित है।

मैं 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 एक खाली सूची पर सेट नहीं हो जाता है और फिर मूल सूची या इस सूची में वापस आ जाता है।

यह किसी भी तरह डिस्प्ले से जुड़ा हो सकता है? जब मैं एक X11 सर्वर (MobaXterm का उपयोग) शुरू करता हूं, तो मंदी काफी हद तक दूर हो जाती है (0.5 सेकंड लगते हैं)। इस समस्या का कारण मुझे पता था कि matplotlib सुपर धीमा था इसलिए मैंने पुनः स्थापित करने के लिए पाइप का उपयोग करने की कोशिश की। मैं भूल गया कि मुझे matplotlib का उपयोग करने के लिए एक Xterm चलाने की आवश्यकता है।

शायद…? पूरी तरह से मुद्दा मेरे लिए बहुत अजीब है। यदि यह एक sys.path मुद्दा है, तो क्या सभी पायथन आयातों के लिए समान मंदी नहीं होगी, न कि केवल पाइप? मैं काफी स्टम्प्ड हूं ed

नमस्कार, मेरा पर्यावरण है:

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 अगर आपको MobaXterm (या कुछ अन्य समतुल्य) चलाने की सलाह देता हूं। मुझे समझ में क्यों नहीं आता

@ngraymon यह अजीब है, लेकिन मैं इस अस्थायी सुधार की कोशिश करूंगा।
धन्यवाद!
मैं एक बार कोशिश करने के बाद इस मुद्दे को अपडेट करूंगा।

बस यह पुष्टि करने के लिए कि व्यवहार अभी भी वही है जिसकी मैंने अभी जाँच की थी:

WSL2 पर Windows टर्मिनल के अंदर time pip3 list चल रहा है:

MobaXterm शुरू करने और एक ही टर्मिनल में time pip3 list चलाने के बाद:

@ngraymon नमस्ते,
मैंने समस्या का समाधान कर लिया है, कृपया निम्न चरणों का प्रयास करें:

• सूडो के साथ पाइप कमांड न चलाएं
• apt-update && एप्ट-अपग्रेड
• सर्वर / कंप्यूटर को रिबूट करें
• डॉकटर पर पूरा ध्यान रखें, कल रात मैंने देखा कि अजगर 3 प्रक्रिया को झुंड द्वारा तीव्रता से इस्तेमाल किया जा रहा था

@ मटियाफिला
मुझे खुशी है कि आपने अपना मुद्दा सुलझा लिया।
मैंने आपके सुझावों की कोशिश की लेकिन यह समस्या हल नहीं हुई।
मैं sudo के साथ पाइप नहीं चलाता, लेकिन मैंने pip3 को sudo apt install python3-pip का उपयोग करके स्थापित किया, शायद यह प्रासंगिक है?
मैं जिस तरह से अपने आप के लिए खुश हूँ के रूप में मैं एक एक्स सर्वर वैसे भी की जरूरत है क्योंकि मैं matplotlib का उपयोग कर साजिश रच रहा हूँ।

@ngraymon क्या आप पायथन-एम पाइप चला सकते हैं, और देखें कि क्या यह भी धीमा है?

यदि यह है, और आपके पास एक नया-पर्याप्त पायथन संस्करण है, तो कृपया हमें 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

उम्मीद है कि उपयोगी है :)

ऐसा प्रतीत होता है कि सूची कमांड के लिए अपराधी कीरिंग है।

एक एक्स सर्वर की मदद करने के आसपास अजीब बात के साथ संयुक्त, मुझे आश्चर्य है कि अगर कीरिंग एक जीयूआई पर निर्भर करता है, और वहाँ कुछ कोड है जो एक्स को खोजने की कोशिश करता है और देरी का कारण बनता है जब तक कि यह निष्कर्ष नहीं निकलता है कि एक नहीं है?

@pfmoore
Pypi में उनके पेज के आधार पर ऐसा लगता है कि इसके लिए D-Bus या X11 सर्वर की आवश्यकता है?

मैंने python3 -m keyring --disable और export PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring लेकिन न तो इस मुद्दे को ठीक करने के लिए लग रहा था।

जारको / कीरिंग # 434 संबंधित लगती है, लेकिन डॉक्स को अक्षम करने के बिंदुओं पर सलाह जो बताती है कि आपने पहले से ही क्या प्रयास किया है।

इस मुद्दे का अनुभव करने के साथ ही, यह मानना ​​है कि यह एक sudo apt-get update && sudo apt-get upgrade कल चलने के बाद शुरू हुआ। यह निश्चित रूप से कीरिंग और डिस्प्ले से संबंधित है। एक्स-सर्वर चलाने के फिक्स के अलावा, मैं अपने .bashrc फ़ाइल को WSL2 के आईपी एड्रेस को प्रदर्शित करने वाली लाइन को हटाकर समस्या को ठीक करने में सक्षम था। प्रश्न में पंक्ति है:
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

इस लाइन को .bashrc से हटाने और WSL2 को पुनरारंभ करने के बाद, पाइप अपेक्षित रूप से व्यवहार करता है। यकीन नहीं होता कि यह सही दिशा में किसी को इंगित करता है, क्योंकि मुझे यकीन नहीं है कि यहां से कैसे आगे बढ़ना है।

ऐसा प्रतीत होता है जैसे मैं pip3 install -U keyring साथ कीरिंग को अद्यतन करके और यह सुनिश्चित करके समस्या को स्थायी रूप से ठीक करने में सक्षम था
[backend]
default-keyring=keyring.backends.null.Keyring
कीरिंग विन्यास फाइल में ~/.config/python_keyring/keyringrc.cfg

pip3 install -U keyring अद्भुत, cjpellicci के सुझाव ने चाल चली।
मुझे ~/.local/share/python_keyring/keyringrc.cfg से ~/.config/share/python_keyring/keyringrc.cfg भी बढ़ना था।
pip3 list चलने में 90 सेकंड के बजाय 1/2 सेकंड लगता है।
यह बिना किसी एक्स सर्वर के चल रहा है।

उपरोक्त मेरे लिए काम नहीं करता है। कोई ~ ~ .local / share / python_keyring / या ~ / .config / share / python_keyring / में कोई भी keyringrc.cfg नहीं है।

यह WSL Ubuntu और Ubuntu के बीच एक अलग व्यवहार हो सकता है?

@peidaqi , कीरिंग को अपडेट करने के बाद आप ~/.config/python_keyring/ डायरेक्टरी में उस सटीक नाम के साथ कॉन्फ़िगर फ़ाइल बनाने का प्रयास कर सकते हैं, और फिर कॉन्फ़िगर फ़ाइल में निम्न जोड़ सकते हैं:
[backend]
default-keyring=keyring.backends.null.Keyring

मेरा मानना ​​है कि पर्यावरण चर सेट करके कीरिंग को निष्क्रिय करने के लिए ऊपर दिए गए चरणों का पालन करने के बाद keyringrc.cfg हो सकता है, लेकिन मैं गलत हो सकता था।

BTW: मैं UbuntuL WSL2 पर भी चला रहा हूं।

नमस्कार! मैं pip list धीमी (~ 1 मिनट) pip install कमांड के साथ (या wsl2 पर) चलाने की कोशिश कर रहा था, कमोबेश इसी मुद्दे का सामना कर रहा था। हालाँकि, मुझे यकीन नहीं है कि व्यवहार बिल्कुल समान था (पाइप सूची _did_ संकुल का उत्पादन करता है, लेकिन कमांड ~ 1 मिनट के बाद वापस आ जाएगा)।

आखिरकार मेरी समस्या का हल क्या था: https://askubuntu.com/a/38468/938540 - मुझे यकीन नहीं है कि मुद्दे संबंधित हैं, लेकिन लक्षण बहुत समान थे। उम्मीद है की यह मदद करेगा!

एक और संभावित डेटा बिंदु जोड़ना:
WSL2 के तहत pip list को लगभग 90 सेकंड का समय लगा।
मैं विंडोज़ डेस्कटॉप के तहत चल रहे एक्स सर्वर को डिस्प्ले पर्यावरण चर सेट कर रहा था। DISPLAY वातावरण चर को साफ़ करने या मेरे X सर्वर को लॉन्च करने का समय बदलकर 0.343 s कर दिया गया।

ऐसा प्रतीत होता है जैसे मैं pip3 install -U keyring साथ कीरिंग को अद्यतन करके और यह सुनिश्चित करके समस्या को स्थायी रूप से ठीक करने में सक्षम था
[backend]
default-keyring=keyring.backends.null.Keyring
कीरिंग विन्यास फाइल में ~/.config/python_keyring/keyringrc.cfg

ये मेरे लिए सही है।

उबुन्टु 18.04
अजगर 3.6.9
पाइप 20.0.2

ऐसा प्रतीत होता है जैसे मैं pip3 install -U keyring साथ कीरिंग को अद्यतन करके और यह सुनिश्चित करके समस्या को स्थायी रूप से ठीक करने में सक्षम था
[backend]
default-keyring=keyring.backends.null.Keyring
कीरिंग विन्यास फाइल में ~/.config/python_keyring/keyringrc.cfg

ये मेरे लिए सही है।

उबुन्टु 18.04
अजगर 3.6.9
पाइप 20.0.2

इस बात की पुष्टि करना मेरे लिए भी काम करता है।

उबुन्टु 18.04
अजगर 3.6.8
पाइप 20.2.3

हाय दोस्तों - हमें और अधिक रिपोर्ट की आवश्यकता नहीं है जो यह पुष्टि करती है कि कीरिंग को अक्षम करना उपयोगकर्ताओं को गति प्रदान करेगा। हम सराहना करेंगे अगर कोई https://github.com/pypa/pip/issues/8719 की मदद के लिए आगे आएगा। :)

यह मेरे लिए तब होता है जब फेडोरा 33 पर मार्ग में दौड़ते हुए! उम्मीद है कि यह मेरे लिए भी एक उपयोगी जोड़ के रूप में एक टिप्पणी है, क्योंकि अन्य सभी WSL पर लगते हैं।

वातावरण

• पाइप 20.2.2 से /usr/lib/python3.9/site-packages/pip (पाइरॉन)
• पायथन 3.9.0
• ओएस: फेडोरा 33
• डेस्कटॉप वातावरण: swaywm (वेन्डल टाइलिंग 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 इसे एक ऑप्ट-इन बना देगा।

लोगों की जानकारी के लिए, कीरिंग मॉड्यूल को किसी भी चीज़ में आयात करने से सही वातावरण में लंबे समय तक स्टॉल हो सकता है, चाहे कोड कभी स्पष्ट रूप से कीरिंग फ़ंक्शन को कॉल करता हो या नहीं। यह एक आयात समय के द्वारा देखा जा सकता है: time python3 -c "import keyring" । मेरे लिए यह फेडोरा 32 मशीन पर 25 सेकंड या इतने अधिक समय लगता है कि मैं दूरस्थ रूप से लॉग इन करता हूं और इसमें ग्राफिकल लॉगिन सत्र नहीं होता है।

मेरे लिए, इसका सीधा कारण यह है कि कीरिंग आयात पर कोड चलाता है जो अंततः org.kde.kwalletd5 के लिए एक DBus कनेक्शन बनाने का प्रयास करता है और यह बहुत धीरे-धीरे विफल हो जाता है। आप मूलभूत कोड को डुप्लिकेट कर सकते हैं (और स्टॉल को पुन: उत्पन्न कर सकते हैं):

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

कीरिंग में ही, यह कोड priority() पद्धति में कीरिंग / बैकएंड / kwallet.py में है। यदि क्वालाल्ट पहले से ही नहीं चल रहा है और शुरू नहीं किया जा सकता है, तो इसके लिए DBus या Python DBus पुस्तकालयों के अंदर एक लंबे समय की आवश्यकता होती है।

इसका मतलब यह है कि कीरिंग मॉड्यूल का पूरा आयात सशर्त और किसी भी कमांड लाइन के झंडे पर होना चाहिए, न कि केवल इसके उपयोग के लिए।

लोगों की जानकारी के लिए, कीरिंग मॉड्यूल को किसी भी चीज़ में आयात करने से सही वातावरण में लंबे समय तक स्टॉल हो सकता है

इस जानकारी के लिए धन्यवाद। यह कीरिंग मॉड्यूल के साथ एक प्रमुख मुद्दे की तरह लगता है - आयात सस्ते होने का मतलब है। क्या इसे वहां बग के रूप में उठाया गया है? मुझे लगता है कि पाइप के लिए हमारी योजना इस व्यवहार के सबसे बुरे को कम करने के लिए पर्याप्त है, लेकिन अंततः मुझे लगता है कि यह फिक्सिंग कीरिंग के अनुरक्षकों के लिए नीचे है।

यदि कोई कीरिंग के खिलाफ बग रिपोर्ट से लिंक कर सकता है, तो यह बहुत अच्छा होगा ताकि हम निगरानी रख सकें कि वे क्या करते हैं और इससे प्रभावित होने वाले उपयोगकर्ताओं को पाइप करने के लिए सलाह प्रदान करते हैं।

FWIW, इसे मारने वाले उपयोगकर्ताओं के लिए वर्कअराउंड कीरिंग को अक्षम कर रहा है, जैसा कि यहां पर दर्ज किया गया है: https://github.com/jaraco/keyring#diseable-keyring

क्या इसे वहां बग के रूप में उठाया गया है? मैं

हां: https://github.com/jaraco/keyring/issues/403