Pip: नया रिज़ॉल्वर पूरा होने में बहुत लंबा समय लेता है

मैं इस मुद्दे का उपयोग उन स्थितियों की आने वाली रिपोर्टों को केंद्रीकृत करने के लिए करने जा रहा हूं जो प्रतीत होता है कि लंबे समय तक चलती हैं, बजाय इसके कि हर एक का अपना मुद्दा खत्म हो जाए या इधर-उधर बिखर जाए।

@jcrist ने https://github.com/pypa/pip/issues/8664#issuecomment -735961391 में कहा

_नोट: मुझे यहां ट्विटर से हमारे अनुभव के बारे में टिप्पणी करने का आग्रह किया गया था।_

हम ( प्रीफेक्ट ) नए रिज़ॉल्वर के परीक्षण में थोड़ी देर कर रहे हैं (केवल 20.3 रिलीज के साथ इसके आसपास हो रहा है)। हम पा रहे हैं कि इंस्टॉल करने का समय अब ​​20+ मिनट की सीमा में है (मैंने वास्तव में कभी एक फिनिश नहीं किया है), पहले यह अधिकतम एक या दो मिनट था। यहां समस्या बड़े खोज स्थान में प्रतीत होती है (प्रीफेक्ट में वैकल्पिक निर्भरताओं का भार है, सीआई और कुछ डॉकर छवियों के लिए हम उन सभी को स्थापित करते हैं) बैकट्रैकिंग के साथ मिलकर।

मैंने वर्बोज़ लॉग को यह पता लगाने की कोशिश करने के लिए सक्षम किया कि आपत्तिजनक पैकेज क्या थे, लेकिन उनमें से अधिक समझ में नहीं आया। मैं setuptools के विभिन्न संस्करणों के साथ-साथ boto3 के विभिन्न संस्करणों के साथ कुछ निर्भरताओं के लिए बहुत सारे पुनर्प्रयास देख रहा हूं। हमारे सीआई/डॉकर बिल्ड के लिए हम चीजों को गति देने के लिए बाधाओं को जोड़ सकते हैं (जैसा कि यहां सुझाया गया है), लेकिन हम अपने setup.py में बाधाओं को बढ़ाने के लिए अनिच्छुक हैं क्योंकि हम डाउनस्ट्रीम उपयोगकर्ताओं को ओवरकंस्ट्रक्शन नहीं करना चाहते हैं। साथ ही, हमारे पास बहुत से नौसिखिए उपयोगकर्ता हैं जो pip install prefect[all_extras] करने के आदी हैं - उन्हें यह बताना कि उन्हें उचित समय में इसे पूरा करने के लिए अतिरिक्त बाधाओं को जोड़ने की आवश्यकता है, अप्रिय लगता है। मुझे यकीन नहीं है कि यहां आगे का सबसे अच्छा रास्ता क्या है।

मैंने यहां एक रन से वर्बोज़ लॉग अपलोड किए हैं (बैकट्रैकिंग के कई मिनटों के बाद मारे गए)। अगर लोग खुद इसे आजमाना चाहते हैं, तो आप दौड़ सकते हैं:

pip install "git+https://github.com/PrefectHQ/prefect.git#egg=prefect[all_extras]"

यहां कोई भी सलाह मददगार होगी - अभी के लिए हम पाइप को 20.2.4 पर पिन कर रहे हैं, लेकिन उपरोक्त का समाधान निकालने के बाद हम अपग्रेड करना चाहेंगे। अधिक लॉग प्रदान करने या आवश्यकतानुसार सुझावों को आज़माने में प्रसन्नता हो रही है।

पाइप और पीपा पर आप सभी के लिए धन्यवाद!

इन्हें https://github.com/pypa/pip/issues/9185 . द्वारा हल किया जा सकता है

धन्यवाद, @dstufft।

मैं यहां दस्तावेज़ीकरण से कुछ उपयोगी समाधान युक्तियों का उल्लेख करूंगा - विशेष रूप से, पहला और तीसरा बिंदु उन लोगों के लिए सहायक हो सकता है जो यहां समाप्त होते हैं:

• यदि पैकेज को स्थापित करने में पाइप को अधिक समय लग रहा है, तो डिपेंडेंसी रिजॉल्यूशन बैकट्रैकिंग पढ़ें ताकि समय को कम करने के तरीकों के लिए पिप डिपेंडेंसी कॉन्फ्लिक्ट्स के कारण बैकट्रैकिंग खर्च करे।

• यदि आप नहीं चाहते कि पाइप वास्तव में निर्भरताओं को हल करे, तो --no-deps विकल्प का उपयोग करें। यह तब उपयोगी होता है जब आपके पास पैकेज संस्करणों का एक सेट होता है जो वास्तविकता में एक साथ काम करते हैं, भले ही उनका मेटाडेटा कहता है कि वे संघर्ष करते हैं। दीर्घकालिक सुधार पर मार्गदर्शन के लिए, परस्पर विरोधी निर्भरताओं को ठीक करना पढ़ें।

• यदि आप समाधान त्रुटियों में भाग लेते हैं और उनके मूल कारणों को ठीक करते समय समाधान की आवश्यकता होती है, तो आप ध्वज का उपयोग करके पुराने समाधानकर्ता व्यवहार को चुन सकते हैं --use-deprecated=legacy-resolver । यह तब तक काम करेगा जब तक हम पाइप 21.0 जारी नहीं करते (देखें डिप्रेशन टाइमलाइन )।

मेरे मामले के लिए, समस्याग्रस्त व्यवहार को pip install 'google-cloud-translate==3.0.0' 'requests==2.20.0' 'setuptools==36.0.1' के साथ बहुत तेज़ी से पुन: प्रस्तुत किया जा सकता है, इसलिए ऐसा लगता है कि #9185 इसे सुधार सकता है।

लीगेसी रिज़ॉल्वर इस पर शीघ्रता से राहत देता है: google-auth 1.23.0 requires setuptools>=40.3.0, but you'll have setuptools 36.0.1 which is incompatible. ।

इसके प्रति एक अन्य विचार है, 100 बैकट्रैक (या कुछ) के बाद एक संदेश के साथ रुकना "अरे, पीआईपी $ पैकेज पर संघर्षों के कारण बैकट्रैकिंग कर रहा है"।

मुझे आश्चर्य है कि रिज़ॉल्वर में वास्तव में होने वाले बनाम डाउनलोड करने और अनज़िप करने में कितना समय लगता है?

मुझे आश्चर्य है कि रिज़ॉल्वर में वास्तव में होने वाले बनाम डाउनलोड करने और अनज़िप करने में कितना समय लगता है?

इसमें से अधिकांश, पिछली बार मैंने जाँच की थी। जब तक हम कुछ बहुत खराब ग्राफ स्थिति को नहीं मार रहे हैं, उस स्थिति में ...: श्रग: उपयोगकर्ता पिप को पिन देने से बेहतर हैं।

मैं अपने कर्मचारियों को उस Google फ़ॉर्म को भर रहा हूं जहां वे कर सकते हैं, लेकिन मैं केवल यह उल्लेख करना चाहता हूं कि हमारे सभी निर्माण इसके साथ समस्याओं का सामना कर रहे हैं। जिन चीजों ने ठीक काम किया और लगभग 90 सेकंड का निर्माण समय था, अब हमारे सीआई बिल्ड का समय समाप्त हो रहा है। सिद्धांत रूप में हम टाइमआउट बढ़ा सकते हैं, लेकिन हम इन मशीनों के लिए मिनट का भुगतान कर रहे हैं, इसलिए हमारे सभी निर्माणों में बहुत अधिक समय लगता है, यह एक दर्दनाक विकल्प है। हमने अभी के लिए अपने सभी बिल्ड पर लीगेसी रिज़ॉल्वर को लागू करने के लिए स्विच किया है।

इस पृष्ठ पर पहुंचने वाले उपयोगकर्ताओं के लिए एक सामान्य नोट के रूप में, कृपया https://pip.pypa.io/en/stable/user_guide/#dependency -resolution-backtracking पढ़ें।

मुझे ट्विटर से कुछ और विवरण जोड़ने के लिए कहा गया था, इसलिए यहां कुछ अतिरिक्त विचार दिए गए हैं। अभी इस समस्या के चार समाधान हैं:

1. बस इसके खत्म होने की प्रतीक्षा करें
2. बाधाओं का उपयोग करके चेक किए गए संस्करणों को कम करने के लिए परीक्षण और त्रुटि विधियों का उपयोग करें
3. उन परीक्षण त्रुटि विधियों को एक नई "constraints.txt" फ़ाइल में रिकॉर्ड और पुन: उपयोग करें
4. "विकास के दौरान" समर्थित संस्करणों की संख्या कम करें

इसकी प्रतीक्षा करना वस्तुतः विचार करने के लिए बहुत महंगा है

ऐसा लगता है कि यह समाधान पैकेजों के एक महाकाव्य टन को डाउनलोड करने पर निर्भर करता है। बादल के युग में इसका अर्थ है-

• अतिरिक्त पैकेजों को संग्रहीत करने के लिए बड़ी हार्डड्राइव की आवश्यकता होती है
• इन पैकेजों को डाउनलोड करने में अधिक बैंडविड्थ की खपत होती है
• इन छवियों को डीकंप्रेस करने की आवश्यकता के कारण सब कुछ संसाधित करने में अधिक समय लगता है

इन सभी में पैसा खर्च होता है, हालांकि सटीक संतुलन पैकेज पर निर्भर करेगा (टेंसरफ़्लो जैसे जानवर से जूझ रहे लोग हार्ड ड्राइव और बैंडविड्थ पर घुट सकते हैं, जबकि छोटे पैकेज वाले लोगों को बिल्ड समय के लिए बिल मिलता है)।

इससे भी अधिक महंगी बात यह है कि एक ऑपरेशन के दौरान डेवलपर का समय बर्बाद होता है जो (शाब्दिक रूप से) 90 के दशक में होता था जिसमें अब 20 मिनट से अधिक समय लगता है (इसमें अधिक समय लग सकता है लेकिन यह हमारे सीआई सिस्टम पर समय समाप्त हो जाता है)।

हम सचमुच इस निर्भरता समाधान प्रणाली का उपयोग करने का जोखिम नहीं उठा सकते हैं।

परीक्षण और त्रुटि बाधाएं अत्यंत बोझिल हैं

यह हर किसी के विकास चक्र में प्रक्रियाओं का एक नया सेट जोड़ता है जहां न केवल उन्हें सामान्य देव कार्य करना होता है, बल्कि अब उन्हें इस रिज़ॉल्वर के ब्लैक बॉक्स को अनुकूलित करने की आवश्यकता होती है। यहां तक ​​​​कि पृष्ठ पर सलाह अत्यंत परीक्षण और त्रुटि है, मूल रूप से पहले पैकेज से शुरू करने के लिए कह रही है जिससे आपको परेशानी हो रही है और जब तक आपका निर्माण समय उचित नहीं है तब तक पुनरावृत्ति जारी रखें।

अधिक कॉन्फ़िगरेशन फ़ाइलें जोड़ना जटिल और पहले से ही जटिल पारिस्थितिकी तंत्र को जोड़ता है।

अभी हमें setup.py , requirements.txt , setup.cfg , pyproject.toml के बीच अंतर को नेविगेट करना होगा, और अब constraints.txt में जोड़ना बस जोड़ता है अजगर पैकेज को बनाए रखने पर और भी अधिक बोझ (और भ्रम)।

विकास के दौरान जाँचे गए संस्करणों को कम करने का पैमाना नहीं है

विकास के दौरान संस्करणों को प्रतिबंधित करना लेकिन उन बाधाओं के बिना पैकेज जारी करने का मतलब है कि उस पैकेज के उपयोगकर्ताओं को विकास के दौरान उन बाधाओं को खुद को फिर से बनाना होगा। यदि मैं एक लोकप्रिय पैकेज स्थापित करता हूं तो मेरे निर्माण समय में विस्फोट हो सकता है जब तक कि मैं उनके प्रयासों की नकल नहीं करता। कॉपी/पेस्ट विधियों के अलावा उन बाधाओं को साझा करने का कोई तरीका नहीं है, जो रखरखाव के बोझ को जोड़ता है।

आखिरकार इसका परिणाम यह होगा कि लोग बाधाओं का उपयोग बिल्कुल नहीं कर रहे हैं, इसके बजाय निर्भरता संस्करणों को सीधे वास्तविक संगतता के आधार पर सीमित नहीं कर रहे हैं बल्कि संगतता और निर्माण समय का मिश्रण हैं। इससे लंबी अवधि में छोटे पैकेजों का समर्थन करना कठिन हो जाएगा।

इसमें से अधिकांश, पिछली बार मैंने जाँच की थी।

प्राथमिकता देने का एक अच्छा कारण हो सकता है https://github.com/pypa/warehouse/issues/8254

पाइपा/वेयरहाउस को प्राथमिकता देने का एक अच्छा कारण हो सकता है#8254

निश्चित रूप से। और जब पीईपी 643 स्वीकृत और कार्यान्वित किया जाता है तो एक sdist समतुल्य।

ऐसा लगता है कि यह समाधान पैकेजों के एक महाकाव्य टन को डाउनलोड करने पर निर्भर करता है

यह सीधे डाउनलोडिंग पर निर्भर नहीं करता है, लेकिन यह पैकेज के लिए मेटाडेटा जानने पर निर्भर करता है, और विभिन्न ऐतिहासिक कारणों से, उस डेटा को प्राप्त करने का एकमात्र तरीका वर्तमान में डाउनलोड करना है (और स्रोत वितरण, निर्माण के मामले में) पैकेज .

यह एक बड़ा ओवरहेड है, हालांकि पीआईपी का डाउनलोड कैश यहां बहुत मदद करता है (हो सकता है कि आप अपने सीआई सेटअप में पीआईपी के कैश को जारी रख सकें?) प्लस साइड पर, यह केवल उन मामलों में कड़ी मेहनत करता है जहां बहुत अधिक निर्भरता प्रतिबंध हैं (जहां " स्पष्ट" पैकेज के नवीनतम संस्करण की पसंद किसी अन्य पैकेज से निर्भरता द्वारा अवरुद्ध है), और यह केवल उन मामलों में वास्तव में महत्वपूर्ण है जहां वैसे भी कोई वैध समाधान नहीं है (हालांकि यह हमेशा तुरंत स्पष्ट नहीं होता है - पुराना रिज़ॉल्वर होगा पैकेज के अमान्य सेट को खुशी से स्थापित करें, इसलिए समस्या "पुराने रिज़ॉल्वर ने काम किया, नया विफल हो गया" जैसा दिखता है, जहां यह वास्तव में "पुराना एक चुपचाप टूटा हुआ सामान है, इसके बजाय नया स्थापित करने में विफल रहता है")।

यह आपको समस्या का समाधान करने में मदद नहीं करता है, मुझे पता है, लेकिन उम्मीद है कि यह कुछ पृष्ठभूमि देता है कि नया रिज़ॉल्वर ऐसा क्यों व्यवहार कर रहा है।

@tedivm कृपया परिनियोजन से अलग चरण के रूप में निर्भरता समाधान करने के लिए pip-tools का उपयोग करने पर ध्यान दें। यह अनिवार्य रूप से बिंदु 4 है - "स्थानीय" निर्भरता संकल्प केवल पिन किए गए संस्करणों को देखकर परिनियोजन के साथ।

दरअसल, यह देखना एक दिलचस्प प्रयोग होगा। ये पैथोलॉजिकल मामले जो लोग। के साथ प्रयोग कर रहे हैं, अगर वे रिज़ॉल्वर को एक बार पूरा करने देते हैं, कैश जारी रखते हैं, और फिर पुनः प्रयास करते हैं, तो क्या यह तेज़ है? यदि कैश के साथ भी यह अभी भी घंटों लंबा है, तो यह सुझाव देता है कि पीपा/वेयरहाउस # 8254 ज्यादा मदद नहीं करेगा।

मुझे नहीं पता कि हम अभी क्या कर रहे हैं, लेकिन मुझे यह भी आश्चर्य है कि क्या एक निश्चित बिंदु के बाद संस्करणों को पूरी तरह से खोजना बंद करना समझ में आता है। यह मूल रूप से यह कहने का एक व्यापार होगा कि हम समय के साथ निर्भरता कैसे विकसित होते हैं, इस बारे में धारणा बनाना शुरू कर रहे हैं। मुझे लगता है कि हम वर्तमान में मूल रूप से नवीनतम संस्करण से शुरू कर रहे हैं, और एक समय में एक संस्करण को पीछे की ओर पुनरावृत्त कर रहे हैं, क्या यह सही है? यदि हां, तो क्या होगा यदि हमने कुछ ऐसा किया:

1. जब तक हम संकल्प X बार विफल नहीं हो जाते, तब तक एक बार में एक संस्करण को पीछे की ओर पुनरावृत्त करें।
2. एक द्विआधारी खोज शुरू करें, शेष उम्मीदवारों को आधा में काटें और उसके साथ प्रयास करें।
   2ए. यदि यह काम करता है, तो द्विआधारी खोज को "नए" पक्ष की ओर ले जाना शुरू करें (इसे आधे में काटें, पुनः प्रयास करें, आदि)।
   2बी. यदि यह विफल हो जाता है, तो द्विआधारी खोज को "पुराने" पक्ष की ओर ले जाना शुरू करें (इसे आधा में काटें, पुनः प्रयास करें, आदि)।

यह बाइनरी खोज का बिल्कुल सही उपयोग नहीं है, क्योंकि संस्करणों की सूची वास्तव में उस तरह से "क्रमबद्ध" नहीं होती है, लेकिन यह git bisect के समान ही कार्य करेगी? इसके साथ सबसे बड़ी समस्या यह है कि यदि नवीनतम N संस्करण सभी विफल हो जाते हैं, और पुराने आधे संस्करण विफल हो जाते हैं, तो यह अच्छे संस्करणों को छोड़ देगा, लेकिन मध्य आधा "ठीक" है।

एक अन्य संभावित विचार एक द्विआधारी खोज के बजाय है, एक समान विचार करें, लेकिन संस्करण को हिस्सों में सेट करने के बजाय, उन्हें बाल्टी में बाल्टी करने का प्रयास करें जो उनके संस्करण "कार्डिनैलिटी" से मेल खाते हैं। IOW, यदि इसके बहुत से प्रमुख संस्करण हैं, तो उन्हें प्रमुख संस्करण द्वारा बकेट करें, यदि इसके कुछ प्रमुख संस्करण हैं, लेकिन बहुत सारे छोटे संस्करण हैं, तो इसे बकेट करें, आदि। ताकि आप समस्या स्थान को विभाजित कर सकें, फिर पुनरावृति शुरू करें प्रत्येक बाल्टी में पहले (या आखिरी?) संस्करण की कोशिश कर रहे हैं, जब तक कि आप एक काम नहीं करते हैं, तो सॉल्वर को केवल उस बाल्टी तक सीमित करें (और शायद एक बाल्टी नई अगर आप पहले के बजाय अंतिम संस्करण का परीक्षण कर रहे हैं?)

मुझे पता नहीं, ऐसा लगता है कि अंतरिक्ष की पूरी तरह से खोज करना "सही" बात है यदि आप हमेशा उत्तर के साथ आना चाहते हैं यदि कोई कहीं भी मौजूद है, लेकिन अगर हम इतनी तेजी से नहीं बना सकते हैं, यहां तक ​​​​कि गोदाम आदि में बदलाव के साथ भी , हम शायद खोज स्थान को संकीर्ण करने के लिए अनुमानों का उपयोग करने के बारे में स्मार्ट होने का प्रयास कर सकते हैं, इस धारणा के तहत कि संस्करण श्रेणियां आमतौर पर इसे अक्सर नहीं बदलती हैं और जब वे करते हैं, तो वे अक्सर हर एक रिलीज को नहीं बदलते हैं।

हो सकता है कि अगर हम हेरिस्टिक्स मोड में जाते हैं, तो हम एक चेतावनी देते हैं कि हम इसे कर रहे हैं, सुझाव देते हैं कि लोग सॉल्वर को अधिक जानकारी प्रदान करें, आदि। शायद हेरिस्टिक्स को अक्षम करने के लिए --please-be-exhaustive-its-ok-ill-wait जैसे ध्वज प्रदान करें।

शायद हम पहले से ही ऐसा कर रहे हैं और मैं गूंगा हूँ :)

हम इसे नहीं कर रहे हैं, और आप गूंगा नहीं हैं :-) लेकिन इस तरह की चीजें करना बहुत मुश्किल है - मैंने देखा है कि अधिकांश रिज़ॉल्यूशन एल्गोरिदम इस धारणा पर आधारित हैं कि निर्भरता डेटा प्राप्त करना सस्ता है (कई भी नहीं हैं पाइप द्वारा प्रयोग करने योग्य क्योंकि वे मानते हैं कि सभी निर्भरता की जानकारी शुरू से ही उपलब्ध है)। तो हम "प्रसिद्ध हार्ड सीएस समस्याओं के लिए नए एल्गोरिदम डिजाइन करना" क्षेत्र में शामिल हो रहे हैं :-(

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

मेरे द्वारा सर्वेक्षण किए गए कुछ रिज़ॉल्वर वास्तव में ऐसा करते हैं, विशेष रूप से पारिस्थितिक तंत्र से जो कि सेवर को भारी बढ़ावा देते हैं (आईआईआरसी कार्गो?)

पायथन समुदाय आमतौर पर सीवर का सख्ती से पालन नहीं करता है, लेकिन हम अभी भी इसे करने में सक्षम हो सकते हैं क्योंकि रिज़ॉल्वर ने कभी भी सबसे अच्छा समाधान वापस करने का वादा नहीं किया है, लेकिन केवल एक अच्छा पर्याप्त है (यानी यदि दोनों 2.0.1 और 1.9.3 संतुष्ट हैं) , समाधानकर्ता को 2.0.1 चुनने की आवश्यकता नहीं है )।

दूसरा हिस्सा यह है कि हम निर्माण में विफलता को कैसे संभालते हैं। हमारी वर्तमान प्रक्रियाओं के साथ, हमें बिल्ड डिप्स प्राप्त करने होंगे, बिल्ड करना होगा (या जानकारी प्राप्त करने के लिए prepare_metadata_for_build_wheel पर सबसे अच्छा कॉल करना होगा)।

द्विआधारी खोज-जैसे शब्दार्थ के साथ, हमें निर्माण विफलताओं के बारे में उदार होना होगा और पाइप को विफलताओं पर पैकेज के एक अलग संस्करण का उपयोग करने का प्रयास करने की अनुमति देनी होगी (जैसा कि हम आज करते हैं, पूरी तरह से विफल होने की तुलना में)।

शायद हेरिस्टिक्स को अक्षम करने के लिए --please-be-exhaustive-its-ok-ill-wait जैसे ध्वज प्रदान करें।

मुझे लगता है कि 100+ बार बैकट्रैक करने के बाद रुकना और "अरे, इसमें बहुत समय लग रहा है। $packages के संस्करणों को कम करके मेरी सहायता करें, या मुझे --option के साथ कठिन प्रयास करने के लिए कहें।" ऐसा कुछ है जिसे हम अब अपेक्षाकृत आसानी से कर सकते हैं।

यदि लोग इसके साथ हैं, तो आइए एक नंबर चुनें (मैंने 100 कहा है, लेकिन मैंने उसे हवा से बाहर निकाल दिया) और इसे इसमें जोड़ दें?

क्या हमारे पास इस बात की अच्छी समझ है कि क्या ये मामले जहां हल करने में वास्तव में लंबा समय लगता है, आम तौर पर ऐसे मामले होते हैं जहां कोई जवाब नहीं होता है और अंतरिक्ष को पूरी तरह से खोजने में काफी समय लगता है क्योंकि प्रति उम्मीदवार हमारे धीमे समय का मतलब है कि इसमें घंटों लगते हैं .. या ये ऐसे मामले हैं जहां एक सफल उत्तर है, लेकिन हमें वहां पहुंचने में कुछ समय लगता है?

@dstufft मेरे मामले में, कोई उपयुक्त समाधान नहीं था (देखें https://github.com/pypa/pip/issues/9187#issuecomment-736010650)। मैंने अनुमान लगाया कि समस्याग्रस्त निर्भरता कौन सी हो सकती है और पैकेजों के कम सेट के साथ इसमें इतना समय नहीं लगता है और अपेक्षित त्रुटि उत्पन्न होती है। पूर्ण आवश्यकताओं-min.txt के साथ यह घंटों में पूरा नहीं हुआ।

लगभग 100 पिन की गई निर्भरताओं के साथ, खोज करने के लिए स्थान बहुत बड़ा है, और कुछ समाधान खोजने की कोशिश करते समय पाइप (शायद) असीम रूप से मुद्रण "आवश्यकता पहले से ही संतुष्ट:" के साथ समाप्त होता है (देखें https://github.com/WeblateOrg/weblate/ रन/1474960864?check_suite_focus=true लंबे लॉग के लिए, इसे कुछ घंटों के बाद मार दिया गया)। मुझे अभी एहसास हुआ कि सीआई प्रक्रिया थोड़ी अधिक जटिल है जिसका मैंने वर्णन किया है - यह पहले श्रेणियों के आधार पर पैकेज स्थापित करता है, फिर न्यूनतम संस्करणों की सूची तैयार करता है और मौजूदा वर्चुअलएन्व को समायोजित करने का प्रयास करता है। शायद यहीं से "आवश्यकता पहले से ही संतुष्ट" लॉग आते हैं।

मेरे मामले में समस्याग्रस्त निर्भरता श्रृंखला थी:

• कमांड लाइन से google-cloud-translate==3.0.0
• setuptools==36.0.1 कमांड लाइन से
• google-api-core[grpc] >= 1.22.0, < 2.0.0dev से google-cloud-translate==3.0.0
• google-auth >= 1.19.1, < 2.0dev से google-api-core
• setuptools>=40.3.0 से google-auth (श्रेणी में कोई भी संस्करण)

अंत में, मुझे लगता है कि समस्या यह है कि यह उन क्षेत्रों में समाधान खोजने की कोशिश करता है जहां कोई नहीं हो सकता है। पूर्ण पिप कैश के साथ:

$ time pip install  google-cloud-translate==3.0.0 setuptools==36.0.1
...

real    0m6,206s
user    0m5,136s
sys 0m0,242s
$ time pip install  google-cloud-translate==3.0.0 setuptools==36.0.1 requests==2.20.0
...

real    0m28,724s
user    0m25,162s
sys 0m0,283s

इस मामले में, requests==2.20.0 (जिसे किसी भी निर्भरता के साथ बिना किसी समस्या के स्थापित किया जा सकता है) जोड़ने से समय लगभग पांच गुना बढ़ जाता है। यह पाइप द्वारा किसी कारण से अलग-अलग chardet और certifi संस्करणों को देखने के कारण होता है।

क्या हमारे पास इस बात की अच्छी समझ है कि क्या ये मामले जहां हल करने में वास्तव में लंबा समय लगता है, आम तौर पर ऐसे मामले होते हैं जहां कोई जवाब नहीं होता है और अंतरिक्ष को पूरी तरह से खोजने में काफी समय लगता है क्योंकि प्रति उम्मीदवार हमारे धीमे समय का मतलब है कि इसमें घंटों लगते हैं .. या ये ऐसे मामले हैं जहां एक सफल उत्तर है, लेकिन हमें वहां पहुंचने में कुछ समय लगता है?

मैं प्रीफेक्ट के मामले में [all_extras] के बारे में निश्चित हूं क्योंकि कोई समाधान मौजूद नहीं है, लेकिन मैं अभी तक यह निर्धारित करने में सक्षम नहीं हूं कि अपमानजनक पैकेज क्या हैं। कुछ बिंदु पर मैं बैठ जाऊंगा और चीजों को धीमा होने तक बेस इंस्टाल पर निर्भरता जोड़ दूंगा, बस समय खोजने की जरूरत है।

लॉग की व्याख्या करने की युक्तियां यहां उपयोगी हो सकती हैं - मैं देख सकता हूं कि पाइप किन पैकेजों के माध्यम से खोज रहा है, लेकिन यह स्पष्ट नहीं है कि इस खोज में कौन सी बाधा विफल हो रही है।

एक अवधि के बाद छोड़ने या संस्करण योजनाओं के बारे में अनुमान/धारणाओं का उपयोग करने के बारे में ऊपर दी गई कुछ टिप्पणियों के बारे में - जिन चीजों पर मैंने काम किया है, उनके लिए एक वैध इंस्टॉल आमतौर पर होता है:

• सभी पैकेज नवीनतम संस्करणों का उपयोग करते हैं (उदाहरण के लिए नवीनतम A , B , और C )
• सिवाय अगर कुछ निर्भरता की सबसे हालिया रिलीज़ टूट जाती है, तो उस स्थिति में हम इसे काम करने के लिए आमतौर पर चीजों को बहुत जल्दी ठीक कर देते हैं और टूटे हुए की हाल ही में रिलीज़ का उपयोग करते हैं (उदाहरण के लिए नवीनतम A और B , C 1 या 2 रिलीज़ पुराना है)।

मैं जिस इंस्टालेशन की तलाश कर रहा हूं वह शायद ही कभी होगा " A और B के नवीनतम संस्करण, साथ ही 3 साल पहले C की रिलीज"। एक मामला जहां मैं यह चाहता हूं कि अगर मैं कुछ डिबगिंग कर रहा हूं, या पुराने वातावरण को फिर से बनाने की कोशिश कर रहा हूं, लेकिन उस स्थिति में मैं आमतौर पर निर्दिष्ट करता हूं कि मुझे सॉल्वर करने के बजाय सीधे C=some-old-version चाहिए मेरे लिए।

@brainwane ने मुझे #9126 से अपना मामला यहां पोस्ट करने के लिए कहा। TLDR: मेरे मामले में नया रिज़ॉल्वर (केवल) 3x धीमा है।

मूल रूप से, मैं उपयोग करता हूँ
pip list --format freeze | sed 's/==.*//' | xargs --no-run-if-empty pip install --upgrade --upgrade-strategy eager
मेरे मैनुअल वातावरण को बदलने के लिए (पैकेज जोड़ने और हटाने के बाद, अपग्रेड करना, डाउनग्रेड करना, चीजों को आज़माना) जो जितना संभव हो उतना अद्यतित है। यह पुराने रिज़ॉल्वर के साथ विफल रहा, लेकिन नए के साथ बढ़िया काम करता है। यह पुराने पैकेजों को अपग्रेड करता है जिन्हें अपग्रेड किया जा सकता है, और उन पैकेजों को डाउनग्रेड करता है जो किसी अन्य पैकेज के लिए बहुत नए हैं।

केवल एक चीज जिसके बारे में मुझे आश्चर्य हुआ कि नया रिज़ॉल्वर कितना धीमा था। यह एक कारक 3 के बारे में है (42 बनाम 13 सेकंड, pip==2.3.0 के साथ और बिना --use-deprecated legacy-resolver का उपयोग करके)। हालांकि मुझे लगता है कि शायद नेटवर्क अनुरोध मुख्य मुद्दा होगा, लेकिन pip list --outdated जीईटी अनुरोध (125) की सटीक समान संख्या के साथ केवल 20s लेता है। मैं सोच रहा था कि कैसे pip केवल संस्करण को हल करने पर ~ 30s खर्च कर सकता है, लेकिन फिर से, इस धागे के संदर्भ में, मैं समझना शुरू करता हूं कि समस्या क्या है।

इस टिप्पणी का उपयोग या उपेक्षा करने के लिए स्वतंत्र महसूस करें क्योंकि आप फिट हैं;)

> time pip list --outdated
Package           Version Latest Type
----------------- ------- ------ -----
gast              0.3.3   0.4.0  wheel
grpcio            1.32.0  1.33.2 wheel
h5py              2.10.0  3.1.0  wheel
lazy-object-proxy 1.4.3   1.5.2  wheel
protobuf          3.13.0  3.14.0 wheel

real    0m19.373s
user    0m19.718s
sys     0m0.721s


> time pip list --format freeze | sed 's/==.*//' | xargs --no-run-if-empty pip install --upgrade --upgrade-strategy eager

[...]

real    0m41.655s
user    0m38.308s
sys     0m1.786s


> time pip list --format freeze | sed 's/==.*//' | xargs --no-run-if-empty pip install --upgrade --upgrade-strategy eager
> --use-deprecated legacy-resolver

[...]

Successfully installed gast-0.4.0 grpcio-1.33.2 h5py-3.1.0 lazy-object-proxy-1.5.2 protobuf-3.14.0

real    0m13.064s
user    0m10.804s
sys     0m0.391s


> time pip list --format freeze | sed 's/==.*//' | xargs --no-run-if-empty pip install --upgrade --upgrade-strategy eager

[...]

Successfully installed gast-0.3.3 grpcio-1.32.0 h5py-2.10.0 lazy-object-proxy-1.4.3 protobuf-3.13.0

real    0m42.860s
user    0m39.015s
sys     0m2.000s

क्या हमारे पास इस बात की अच्छी समझ है कि क्या ये मामले जहां हल करने में वास्तव में लंबा समय लगता है, आम तौर पर ऐसे मामले होते हैं जहां कोई जवाब नहीं होता है और अंतरिक्ष को पूरी तरह से खोजने में काफी समय लगता है क्योंकि प्रति उम्मीदवार हमारे धीमे समय का मतलब है कि इसमें घंटों लगते हैं .. या ये ऐसे मामले हैं जहां एक सफल उत्तर है, लेकिन हमें वहां पहुंचने में कुछ समय लगता है?

खैर, यह पुराने रिज़ॉल्वर के साथ बिना किसी त्रुटि के काम करता है लेकिन नए के साथ नहीं- क्या यह प्रश्न का उत्तर देता है?

यह एक बड़ा ओवरहेड है, हालांकि पीआईपी का डाउनलोड कैश यहां बहुत मदद करता है (हो सकता है कि आप अपने सीआई सेटअप में पीआईपी के कैश को जारी रख सकें?) प्लस साइड पर, यह केवल उन मामलों में कड़ी मेहनत करता है जहां बहुत अधिक निर्भरता प्रतिबंध हैं (जहां " स्पष्ट" पैकेज के नवीनतम संस्करण की पसंद किसी अन्य पैकेज से निर्भरता द्वारा अवरुद्ध है), और यह केवल उन मामलों में वास्तव में महत्वपूर्ण है जहां वैसे भी कोई वैध समाधान नहीं है (हालांकि यह हमेशा तुरंत स्पष्ट नहीं होता है - पुराना रिज़ॉल्वर होगा पैकेज के अमान्य सेट को खुशी से स्थापित करें, इसलिए समस्या "पुराने रिज़ॉल्वर ने काम किया, नया एक विफल" जैसा दिखता है, जहां यह वास्तव में "पुराना एक चुपचाप टूटा हुआ सामान है, इसके बजाय नया स्थापित करने में विफल रहता है")।

यह आपको समस्या का समाधान करने में मदद नहीं करता है, मुझे पता है, लेकिन उम्मीद है कि यह कुछ पृष्ठभूमि देता है कि नया रिज़ॉल्वर ऐसा क्यों व्यवहार कर रहा है।

हम कैश जारी रखते हैं, लेकिन यह सचमुच कभी खत्म नहीं होता है।

मैं समझता हूं कि रिज़ॉल्वर कैसे काम करता है, लेकिन मेरा कहना है कि इसे समझने से समस्या दूर नहीं होती है। ओवरहेड का यह स्तर वस्तुतः पिछले संस्करण- या किसी अन्य पैकेज मैनेजर की तुलना में अधिक परिमाण का आदेश है।

मैं उन पुराने फैसलों को समझता हूं जिनका यहां समर्थन किया जाना था, लेकिन स्पष्ट रूप से जब तक प्रदर्शन के मुद्दे को संबोधित नहीं किया जाता है, तब तक रिज़ॉल्वर का यह संस्करण डिफ़ॉल्ट नहीं होना चाहिए। PyPi को पहले से गणना किए गए निर्भरता डेटा को भेजना चाहिए, न कि हमें उसी डेटा को उत्पन्न करने के लिए दर्जनों पैकेज बनाने के लिए मजबूर करना चाहिए जो सैकड़ों अन्य लोग भी पुन: उत्पन्न कर रहे हैं। मैं समझता हूं कि यह रोडमैप में है, लंबित फंडिंग, लेकिन मेरी राय है कि यह समाधानकर्ता तब तक उत्पादन के लिए तैयार नहीं है जब तक कि इस मुद्दे का समाधान नहीं किया जाता।

मुझे अपने विचार यहां छोड़ने होंगे: मैं @tedivm से सहमत हूं कि यह रिज़ॉल्वर उत्पादन के लिए तैयार नहीं है। बिना किसी उपयोगी आउटपुट के 10 मिनट तक पाइप चलाने का UX भयानक है। अभी pip एक अधर्मी मात्रा में दोहराव वाले पाठ का उत्पादन कर रहा है (जो शायद खोज को धीमा कर रहा है) Requirement already satisfied: ... ।

यदि रिज़ॉल्वर पहले प्रयास में विफल हो जाता है (मुझे लगता है कि पाइप नवीनतम संस्करणों को स्थापित करने का प्रयास करता है) मुझे लगता है कि पाइप को बाधा उल्लंघनों को तुरंत प्रिंट करना चाहिए। या खोज को N प्रयासों तक सीमित करने के लिए विकल्प जोड़ें, या किसी दिए गए पैकेज के लिए केवल M प्रयास करें। और हो सकता है कि कुछ प्रयासों के बाद पाइप को कम से कम बाधा उल्लंघन के साथ स्थिति को प्रिंट करना चाहिए। जैसा कि यह खड़ा है मुझे बस Ctrl-C पाइप करना है जब यह बहुत लंबा चलता है (10 मिनट बहुत लंबा है) और मुझे प्रतीक्षा करने से कोई उपयोगी जानकारी नहीं मिलती है।

मेरे पायथन पैकेज की किस्त बहुत अधिक समय ले रही है और फिर जेनकींस सीआई/सीडी पाइपलाइन 2 घंटे के बाद विफल हो जाती है।

एएमक्यूपी एकत्रित करना==2.5.2
14:27:30 डाउनलोड कर रहा हूँ amqp-2.5.2-py2.py3-none-any.whl (49 kB)
14:27:30 boto3 एकत्रित करना==1.16.0
14:27:30 डाउनलोडिंग boto3-1.16.0-py2.py3-none-any.whl (129 kB)
14:27:30 आवश्यकता पहले से ही संतुष्ट है: jmespath<1.0.0,>=0.7.1 in /root/.local/lib/python3.6/site-packages (from boto3==1.16.0->gehc-edison- ऐ-कंटेनर-समर्थन==3.5.0) (0.10.0)
14:27:30 आवश्यकता पहले से ही संतुष्ट: s3transfer<0.4.0,>=0.3.0 in /root/.local/lib/python3.6/site-packages (from boto3==1.16.0->gehc-edison- ऐ-कंटेनर-समर्थन==3.5.0) (0.3.3)
14:27:30 बोटोकोर एकत्रित करना==1.19.26
14:27:30 डाउनलोडिंग botocore-1.19.26-py2.py3-none-any.whl (6.9 एमबी)
14:27:30 आवश्यकता पहले ही पूरी हो चुकी है: python-dateutil<3.0.0,>=2.1 in /root/.local/lib/python3.6/site-packages (from botocore==1.19.26->gehc-edison- ऐ-कंटेनर-समर्थन==3.5.0) (2.8.1)
14:27:30 आवश्यकता पहले से ही संतुष्ट है: jmespath<1.0.0,>=0.7.1 in /root/.local/lib/python3.6/site-packages (from boto3==1.16.0->gehc-edison- ऐ-कंटेनर-समर्थन==3.5.0) (0.10.0)
14:27:30 आवश्यकता पहले से ही संतुष्ट है: urllib3<1.27,>=1.25.4 in /root/.local/lib/python3.6/site-packages (से botocore==1.19.26->gehc-edison-ai- कंटेनर-समर्थन==3.5.0) (1.25.11)
14:27:30 अजवाइन इकट्ठा करना==5.0.2
14:27:30 सेलेरी डाउनलोड कर रहा है-5.0.2-py3-none-any.whl (392 kB)
14:27:30 जानकारी: पीआईपी यह निर्धारित करने के लिए बोटोकोर के कई संस्करणों को देख रहा है कि कौन सा संस्करण अन्य आवश्यकताओं के अनुकूल है।
इसमें कुछ समय लग सकता है।14:27:31 जानकारी: पीआईपी यह निर्धारित करने के लिए <Python from Requires-Python> के कई संस्करणों को देख रहा है कि कौन सा संस्करण अन्य आवश्यकताओं के अनुकूल है।
इसमें कुछ समय लग सकता है।

क्यों पाइप कई संस्करणों को देख रहा है?

क्या इसका कोई संकल्प है।

@Nishanksingla मुझे आपके द्वारा यहां कॉपी किए गए आउटपुट में एक आइटम दिखाई देता है:

14:27:31 जानकारी: पीआईपी यह निर्धारित करने के लिए कि कौन सा संस्करण अन्य आवश्यकताओं के अनुकूल है, इसके कई संस्करणों को देख रहा है। इसमें कुछ समय लग सकता है।

क्या यह सचमुच पीआईपी आउटपुट है, या आपने पैकेज का नाम हटा दिया है?

साथ ही, मेरा सुझाव है कि आप इस टिप्पणी में दिए गए सुझावों और मार्गदर्शन पर एक नज़र डालें।

मैंने टिप्पणी अपडेट की, गिट <Python from Requires-Python> . नहीं दिखा रहा था

खैर, यह पुराने रिज़ॉल्वर के साथ बिना किसी त्रुटि के काम करता है लेकिन नए के साथ नहीं- क्या यह प्रश्न का उत्तर देता है?

नहीं। पुराना रिज़ॉल्वर नियमित रूप से निर्भरता के एक समूह का समाधान करेगा जो निर्भरता बाधाओं का उल्लंघन करता है। नया रिज़ॉल्वर कुछ हद तक धीमा है, क्योंकि यह ऐसा करना बंद कर देता है, और काम का एक हिस्सा ऐसा करना बंद कर देता है जिससे चीजें धीमी हो जाती हैं (आंशिक रूप से उन कारणों के लिए जो पायथन पैकेजिंग के इतिहास के लिए अद्वितीय हैं)।

PyPi को पहले से गणना किए गए निर्भरता डेटा को भेजना चाहिए, न कि हमें उसी डेटा को उत्पन्न करने के लिए दर्जनों पैकेज बनाने के लिए मजबूर करना चाहिए जो सैकड़ों अन्य लोग भी पुन: उत्पन्न कर रहे हैं। मैं समझता हूं कि यह रोडमैप में है, लंबित फंडिंग, लेकिन मेरी राय है कि यह समाधानकर्ता तब तक उत्पादन के लिए तैयार नहीं है जब तक कि इस मुद्दे का समाधान नहीं किया जाता।

यह वास्तव में सभी मामलों में संभव नहीं है।

मूल रूप से हमारे पास पहिए हैं, जिनके पास सांख्यिकीय रूप से गणना की गई निर्भरता की जानकारी है। इसके लिए वर्तमान में PyPI से एक व्हील डाउनलोड करने और उस व्हील से इस जानकारी को निकालने की आवश्यकता है। वर्तमान में हमारे पास वेयरहाउस में निश्चित रूप से ऐसा करने की योजना है।

पहिए आसान मामला हैं... समस्या तब sdists के लिए नीचे आती है। ऐतिहासिक रूप से sdists में पूरी तरह से गतिशील निर्भरता की जानकारी हो सकती है, जैसे कुछ इस तरह:

setup(
    install_requires=[random.choice(["urllib3", "requests"])]
)

एक पूरी तरह से मान्य (हालांकि मूर्खतापूर्ण) setup.py फ़ाइल है, जहां निर्भरताओं के सेट की पूर्व-गणना करना संभव नहीं है। एक अधिक गंभीर उदाहरण वह होगा जो वर्तमान चल रहे वातावरण का आत्मनिरीक्षण करता है, और वर्तमान परिवेश के बारे में जो खोजता है उसके आधार पर निर्भरताओं के सेट को समायोजित करता है, यह कभी-कभी ओएस या पायथन संस्करण (जो आधुनिक समय में) के आधार पर सांसारिक हो सकता है हमारे पास इसे व्यक्त करने के लिए स्थिर तरीके हैं, लेकिन हर कोई अभी तक उनका उपयोग नहीं कर रहा है) या ऐसी चीजें जैसे कि सी लाइब्रेरी सिस्टम पर मौजूद हैं या। ऐसा कुछ।

इस प्रकार sdists के लिए, हमारे पास कुछ मामले हैं जहां हम समाप्त हो जाते हैं जहां उनमें से कुछ स्थिर निर्भरता जानकारी हो सकती है (लेकिन वर्तमान में नहीं, हालांकि हमारे पास इसके लिए एक योजना है) लेकिन उनमें से कुछ नहीं कर सकते हैं और नहीं करेंगे, और उन मामलों में पीछे हटना वे विकल्प मूल रूप से हमेशा धीमे होने वाले हैं।

तो यहां हमारी आशा है कि निर्भरता के कौन से स्थिर सेट की गणना करके हम सामान्य मामलों को गति दे सकते हैं, जो कि रिपॉजिटरी एपीआई के हिस्से के रूप में उपलब्ध हो सकते हैं, लेकिन हमेशा एक मौका होता है कि कुछ प्रोजेक्ट ऐसे राज्य में मौजूद हो सकते हैं जो इस धीमे व्यवहार को भी ट्रिगर करते हैं उन सुधारों (और यह उन सभी पैकेज प्रबंधकों के साथ हो सकता है जो सिस्टम का उपयोग करते हैं, हालांकि पाइथन हमारी गतिशील निर्भरता क्षमता के कारण बदतर स्थिति में है)।

मुझे लगता है कि यह शायद सच है कि अपेक्षा से अधिक लोग "बुरे मामले" को मार रहे थे, कारणों में से एक मैंने पूछा कि क्या ये धीमी चीजें अंततः निर्भरताओं के हल किए गए सेट के साथ समाप्त होती हैं, या यदि वे निर्भरताओं के एक अनसुलझे सेट के साथ समाप्त होती हैं। यदि वे आम तौर पर त्रुटियां हैं, तो यह एक त्रुटि संदेश के साथ जल्द ही बम आउट करने के लिए समझ में आता है, क्योंकि हमारा अनुमानी हो सकता है "यदि हमारे पास एन से अधिक बार बैकट्रैक है, तो हम शायद विफलता की ओर बढ़ रहे हैं"। यदि वे आम तौर पर सफलता के साथ समाप्त होते हैं, लेकिन वहां पहुंचने में थोड़ा समय लगता है, तो यह सुझाव देता है कि उम्मीदवारों को किसी तरह से बेहतर तरीके से चुनने के लिए हमारे अनुमान को बेहतर बनाने की कोशिश में निवेश करना बेहतर होगा, ताकि समाधान तेजी से पहुंचने का प्रयास किया जा सके।

एक बात जो मुझे आश्चर्यचकित करती है, वह यह है कि जब मैं वर्चुअल वातावरण में पाइप 20.3 और पायथन 3.6 के साथ अपनी आवश्यकताओं.txt को स्थापित करता हूं तो मुझे यह समस्या मेरे सिस्टम में नहीं मिल रही है।
लेकिन समान आवश्यकताओं के लिए। txt मैं अपने जेनकींस पाइपलाइन में समस्या हो रही है।
कोई विचार?

खैर, यह पुराने रिज़ॉल्वर के साथ बिना किसी त्रुटि के काम करता है लेकिन नए के साथ नहीं- क्या यह प्रश्न का उत्तर देता है?
नहीं। पुराना रिज़ॉल्वर नियमित रूप से निर्भरता के एक समूह का समाधान करेगा जो निर्भरता बाधाओं का उल्लंघन करता है। नया रिज़ॉल्वर कुछ हद तक धीमा है, क्योंकि यह ऐसा करना बंद कर देता है, और काम का एक हिस्सा ऐसा करना बंद कर देता है जिससे चीजें धीमी हो जाती हैं (आंशिक रूप से उन कारणों के लिए जो पायथन पैकेजिंग के इतिहास के लिए अद्वितीय हैं)।

जब मैं कहता हूं "बिना त्रुटि के" मैं सचमुच बोल रहा था- आप जो उल्लंघन कह रहे हैं वह हो सकता है। आम तौर पर जब यह चीजों को तोड़ता है तो यह ऐसा कहता है- जैसे आपको एक संदेश मिलता है जैसे "पैकेज एक्स चाहता है लेकिन हमने इसके बजाय वाई स्थापित किया है"। मैं स्पष्ट रूप से कह रहा हूं कि हमें ऐसा कोई संदेश नहीं मिला है।

जब हम पुराने रिज़ॉल्वर को नए रिज़ॉल्वर के समान निर्भरता के सेट पर चलाते हैं, तो पुराना रिज़ॉल्वर एक मिनट और उनतीस सेकंड में निर्भरता के एक मान्य कार्य सेट के साथ वापस आ जाता है, जबकि पुराना रिज़ॉल्वर हमारे सीआई सिस्टम के साथ समय समाप्त करने के बाद विफल हो जाता है। 20 मिनट कुछ नहीं।

कोई विचार?

पर्यावरण मतभेद शायद? पर्यावरण के लिए निर्भरता सशर्त होना संभव है जिसमें पाइप चल रहा है (पायथन संस्करण, ओएस, प्लेटफॉर्म इत्यादि)

लॉग की व्याख्या करने की युक्तियां यहां उपयोगी हो सकती हैं - मैं देख सकता हूं कि पाइप किन पैकेजों के माध्यम से खोज रहा है, लेकिन यह स्पष्ट नहीं है कि इस खोज में कौन सी बाधा विफल हो रही है।

एक गैर-दस्तावेज + असमर्थित विकल्प है जिसे मैंने अपने निजी डिबगिंग के लिए जोड़ा है: PIP_RESOLVER_DEBUG । कोई वादा नहीं है कि यह भविष्य के रिलीज में होगा या कोई प्रदर्शन हिट नहीं होगा, लेकिन अभी, आप शायद इसका उपयोग कर सकते हैं। मोर आउटपुट! :)

आम तौर पर जब यह चीजों को तोड़ता है तो यह ऐसा कहता है- जैसे आपको एक संदेश मिलता है जैसे "पैकेज एक्स चाहता है लेकिन हमने इसके बजाय वाई स्थापित किया है"। मैं स्पष्ट रूप से कह रहा हूं कि हमें ऐसा कोई संदेश नहीं मिला है।

ओह दिलचस्प! क्या आप वाकई त्रुटि संदेश को दबा नहीं रहे हैं? (एक CLI विकल्प है, env var या config फाइल जो ऐसा कर सकती है -- pip config list अंतिम दो की पहचान करने में मदद करेगी)

यदि नहीं, तो क्या आप शायद जीथब जिस्ट में प्रजनन निर्देश पोस्ट कर सकते हैं, और उसे यहां से लिंक कर सकते हैं?

पीएस: मैंने यहां प्रत्येक घटक पर काम किया/लिखा है - चेतावनी, पुराना रिज़ॉल्वर और नया, और AFAIK जो आप वर्णन कर रहे हैं वह तब तक संभव नहीं होना चाहिए जब तक कि मैंने वास्तविक कड़ी मेहनत नहीं की है और किसी और के पास नहीं है देखा। ;)

मेरा अनुभव निम्नलिखित है:

1. बैकट्रैकिंग के साथ नया रिज़ॉल्वर उपयोग करने के लिए सीधा बहुत धीमा है (यह बहुत मददगार होगा यदि कोई ध्वज था, जैसे ही वह बैकट्रैक करना शुरू करता है, तो उसे तुरंत विफल कर दिया जाता है), इसलिए स्पष्ट समाधान केवल स्नैपशॉट निर्भरता के लिए है जिसे हम एक से काम जानते हैं लीगेसी pip freeze को स्टॉपगैप के रूप में constraints.txt फ़ाइल में बदलें। (भगवान जानता है कि हम उस फ़ाइल को कैसे पुन: उत्पन्न करने जा रहे हैं, लेकिन यह एक और दिन के लिए एक समस्या है)।

2. उह ओह, ऐसा लगता है कि हमारे पास अभी भी एक संघर्ष है, भले ही हम जानते हैं कि संस्करण काम करते हैं, लेकिन सौभाग्य से जिस परियोजना पर हम निर्भर हैं, उसने मास्टर पर अपनी निर्भरता तय कर ली है, तो चलिए बस गिट यूआरएल पर निर्भर हैं। आह, अच्छा, यह काम नहीं करता (https://github.com/pypa/pip/issues/8210), वे requirements.txt में हैं।

3. .post1 संस्करण के लिए खराब मेटाडेटा पर एक कठिन विफलता सहित कुछ और मुद्दे (https://github.com/pypa/pip/pull/9085 स्पष्ट रूप से ठीक नहीं हुआ, या लगता है कि यह एक वास्तविक विफलता है) - तो अब मैं मैन्युअल रूप से constraints.txt का संपादन कर रहा हूं और यह समझाते हुए टिप्पणियां जोड़ रहा हूं कि इस फ़ाइल को हाथ से आगे बढ़ने की आवश्यकता है।

4; सब कुछ हल हो गया लगता है, और अब मैं एक स्पष्ट रूप से अनंत लूप में हूं (जो जानता है, मैंने इसे 33k लाइनों को स्टडआउट पर मुद्रित करने के बाद रोक दिया था) जिसमें निम्नलिखित पंक्तियां बार-बार मुद्रित होती हैं:

Requirement already satisfied: google-auth<2.0dev,>=0.4.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from google-api-core<1.24,>=1.16.0->dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (1.23.0)
Requirement already satisfied: google-auth<2.0dev,>=0.4.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from google-api-core<1.24,>=1.16.0->dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (1.23.0)
Requirement already satisfied: six>=1.14.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (1.15.0)
Requirement already satisfied: requests<2.24.0,>=2.18.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from dbt-core@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-core&subdirectory=core->-r python_modules/elementl-data/requirements.txt (line 3)) (2.23.0)
Requirement already satisfied: pytz>=2015.7 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from Babel>=2.0->agate<2,>=1.6->dbt-core@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-core&subdirectory=core->-r python_modules/elementl-data/requirements.txt (line 3)) (2020.4)
Requirement already satisfied: googleapis-common-protos<1.53,>=1.6.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (1.6.0)
Requirement already satisfied: setuptools>=34.0.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from google-api-core<1.24,>=1.16.0->dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (50.3.2)
Requirement already satisfied: six>=1.14.0 in /Users/max/.virtualenvs/internal/lib/python3.7/site-packages (from dbt-bigquery@ git+https://github.com/fishtown-analytics/dbt.git#egg=dbt-bigquery&subdirectory=plugins/bigquery->-r python_modules/elementl-data/requirements.txt (line 4)) (1.15.0)

चौंकाने वाला। मैंने आवश्यकताएँ.txt, और Constraints.txt संलग्न की हैं। Setup.py निम्नानुसार चलता है:

from setuptools import setup

setup(
    install_requires=[
        "boto3",
        "dagster_aws",
        "dagster_dbt",
        "dagster_gcp",
        "dagster_pandas",
        "dagster_slack",
        "dagster",
        "dagstermill",
        "dbt",
        "google-cloud-bigquery",
        "idna",
        "nltk",
        "pandas",
        "pybuildkite",
        "requests",
        "slackclient",
        "snowflake-sqlalchemy",
        "tenacity",
    ],
)

आवश्यकताएँ.txt
बाधाओं.txt

@mgasner मुझे लगता है कि आपको पाइप-टूल्स को अपनाने और निर्भरता ग्राफ निर्माण और निर्भरता प्रबंधन को स्थापना से एक अलग कदम के रूप में करने से लाभ होगा। :)

ओह दिलचस्प! क्या आप वाकई त्रुटि संदेश को दबा नहीं रहे हैं? (एक CLI विकल्प है, env var या config फाइल जो ऐसा कर सकती है -- pip config list अंतिम दो को पहचानने में मदद करेगी)

यह सर्किलसीआई में है इसलिए कमांड चलाने के लिए यह छोटा नहीं है, लेकिन मैंने इन संदेशों को इन कंटेनरों के साथ सर्किलसीआई में देखा है और हम चीजों को ओवरराइड नहीं कर रहे हैं इसलिए मेरे पास यह मानने का कोई कारण नहीं है कि हम कुछ भी दबा रहे हैं।

यदि नहीं, तो क्या आप शायद जीथब जिस्ट में प्रजनन निर्देश पोस्ट कर सकते हैं, और उसे यहां से लिंक कर सकते हैं?

मैं इसे देख कर आप सभी की सराहना करता हूं, और निश्चित रूप से इसे दोहराने में मदद करने की कोशिश करूंगा- लेकिन चूंकि इसमें हमारे कुछ निजी पुस्तकालय शामिल हैं (जीथब रेपो से खींचे गए) मुझे कुछ प्रयास करना होगा और यह वादा नहीं कर सकता जल्दी करो।

@pradyunsg हां, यह बिल्कुल स्पष्ट है कि निर्भरता को हल करने के लिए निर्भरता रिज़ॉल्वर का उपयोग करना एक नॉनस्टार्टर है, लेकिन यह वह मुद्दा नहीं है जिसका मैंने यहां सामना किया - यह शुरुआती बिंदु है।

यहां समस्याओं की रिपोर्ट करने वाले सभी लोगों के लिए एक नोट:

नमस्ते। मुझे खेद है कि आपको अभी परेशानी हो रही है। अपनी रिपोर्ट हमारे साथ साझा करने के लिए धन्यवाद। हम कई परस्पर जुड़ी समस्याओं पर काम कर रहे हैं जो लोग हमें रिपोर्ट कर रहे हैं।

(यदि आपको कोई आपत्ति नहीं है, तो कृपया हमें यह भी बताएं कि अलग तरीके से क्या हो सकता था ताकि आप रिज़ॉल्वर बीटा अवधि के दौरान इसका परीक्षण और पकड़ और रिपोर्ट कर सकें।)

FYI करें: PEP-643 (पैकेज स्रोत वितरण के लिए मेटाडेटा) को मंजूरी दे दी गई है। :रॉकेट:

इसलिए पहले मैंने भविष्यवाणी की थी कि यह लोगों को केवल निर्भरता के मुद्दों के कारण पैकेज के वैध संस्करणों का समर्थन करना बंद कर देगा, न कि उनके साथ किसी वास्तविक प्रोग्रामेटिक समस्या के कारण। ऐसा पहले से हो रहा है-

यह परिवर्तन लोगों को समर्थित संस्करणों में कहीं अधिक प्रतिबंधात्मक होने की ओर धकेलने वाला है और इसके ऐसे प्रभाव होने जा रहे हैं जिनकी मुझे वास्तव में आशा है कि लोगों ने विचार किया है।

यह परिवर्तन लोगों को समर्थित संस्करणों में कहीं अधिक प्रतिबंधात्मक होने की ओर धकेलने वाला है और इसके ऐसे प्रभाव होने जा रहे हैं जिनकी मुझे वास्तव में आशा है कि लोगों ने विचार किया है।

उम्मीद यह है कि लोग पारंपरिक रूप से पसंद किए जाने वाले सामूहिक समुदाय की तुलना में यथोचित सख्त आवश्यकताएं प्रदान करेंगे। ऐसा बहुत कम होता है, जब उपयोगकर्ता "अनुरोध" (उदाहरण के लिए) मांगते हैं, तो वास्तव में अनुरोधों का कोई भी संस्करण ऐसा करेगा; लेकिन पाइथन पैकेजिंग टूल परंपरागत रूप से न्यूज़सेट संभावित संस्करण पर भोलेपन से बसने से उपयोगकर्ता को "मदद" करते हैं। मेरी आशा है कि पायथन पैकेज उपयोगकर्ता और अनुरक्षक समान रूप से एक आवश्यकता निर्दिष्ट होने पर अधिक संदर्भ प्रदान करने में सक्षम होंगे; यह सभी उपयोगकर्ताओं, अनुरक्षकों और टूल डेवलपर्स को एक बेहतर सह-संचालन वातावरण प्रदान करने में मदद करेगा।

एक बात जो विचार करने योग्य हो सकती है, वह यह है कि क्या लंबे रिज़ॉल्यूशन के समय की रिपोर्ट में कोई सामान्य लक्षण होते हैं - सबसे स्पष्ट बात "परेशानी" पैकेजों का एक विशेष सेट है। मैंने देखा है कि बोटोकोर रिपोर्ट में बहुत अधिक आया है और मुझे आश्चर्य है कि क्या इसे असामान्य रूप से बड़ी संख्या में रिलीज मिली है, या अन्य पैकेजों की तुलना में अधिक असंगत परिवर्तन किए हैं?

जाहिर है, हमारे लिए (पाइप डेवलपर्स) मामले के आधार पर पैकेज की जांच करना व्यावहारिक नहीं है, लेकिन समस्या पर कर्षण प्राप्त करने के लिए हमें कुछ और विशिष्ट चाहिए।

हो सकता है कि हम किसी स्थानीय फ़ाइल में जहां हम लोगों को अपलोड करने के लिए कहते हैं, आँकड़ों को डंप करने के लिए पाइप लिख सकते हैं ("प्रोजेक्ट ए के एक्स संस्करण, प्रोजेक्ट बी के वाई संस्करण, ..., असफल/सफल होने से पहले")? लेकिन यह वैसे भी लॉग में है, और यह तब तक कम उपयोगी है जब तक कि लोग कमांड को पूरा नहीं होने देते, इसलिए शायद यह बहुत अतिरिक्त मदद नहीं होगी।

https://github.com/pypa/pip/issues/9187#issuecomment -736104404

इसके प्रति एक अन्य विचार है, 100 बैकट्रैक (या कुछ) के बाद एक संदेश के साथ रुकना "अरे, पीआईपी $ पैकेज पर बहुत अधिक विरोध के कारण बैकट्रैकिंग कर रहा है"।

आइए इसे करते हैं -- और इसके लिए एक नंबर चुनें। और उपयोगकर्ता को सीएलआई से अधिक संख्या चुनने की अनुमति दें?

एक बात पर विचार करना है कि हम उस संख्या की ओर कैसे गिनती करते हैं। मान लें कि यदि X Y पर निर्भर करता है। X==2.0 पिन किया गया है, Y को तीन बार बैकट्रैक किया गया और अंततः सभी संस्करण विफल हो गए, इसलिए X को बैकट्रैक किया गया और X==1.0 में पिन किया गया, जहां Y को दो बार और बैकट्रैक किया गया और अंत में एक कार्यशील संस्करण मिला। . क्या Y की अब बैकट्रैक गिनती 3 या 5 है? मैं उन कारणों के बारे में सोच सकता हूं कि क्यों दोनों में से कोई एक दूसरे से बेहतर हो सकता है।

मैंने देखा है कि बोटोकोर रिपोर्ट में बहुत अधिक आया है और मुझे आश्चर्य है कि क्या इसे असामान्य रूप से बड़ी संख्या में रिलीज मिली है, या अन्य पैकेजों की तुलना में अधिक असंगत परिवर्तन किए हैं?

इसमें वास्तव में असामान्य रूप से उच्च संख्या में रिलीज़ हैं, इसे लगभग दैनिक रूप से रिलीज़ किया जा रहा है, देखें https://pypi.org/project/botocore/#history

इसमें वास्तव में असामान्य रूप से बड़ी संख्या में रिलीज़ हैं, इसे लगभग रोज़ रिलीज़ किया जा रहा है

और एक उदाहरण के रूप में, यह python-dateutil>=2.1,<3.0.0 पर निर्भर करता है। इसलिए यदि आप अजगर-डेटुटिल 3.0.0 और बोटोकोर को स्थापित करना चाहते हैं, तो पाइप को बोटोकोर के हर रिलीज के माध्यम से पीछे हटना होगा, इससे पहले कि यह सुनिश्चित हो सके कि कोई ऐसा नहीं है जो डेटुटिल 3.0.0 के साथ काम करता है।

मूल रूप से, यही वह परिदृश्य है जो इन लंबे रनटाइम का कारण बन रहा है। हम यह नहीं मान सकते हैं कि वर्षों पहले के बोटोकोर के एक संस्करण ने python-dateutil के किसी भी संस्करण की अनुमति नहीं दी होगी (भले ही 3.0.0 शायद तब भी मौजूद नहीं था और व्यवहार में इसके साथ काम नहीं करेगा ) , इसलिए हमें जांचना होगा। और इससे भी बदतर, अगर बोटोकोर के एक प्राचीन संस्करण में python-dateutil पर एक अप्रतिबंधित निर्भरता है, तो हम इसे dateutil 3.0.0 के साथ स्थापित कर सकते हैं, और एक प्रणाली है, जबकि तकनीकी रूप से सुसंगत है, वास्तव में काम नहीं करता है .

सबसे अच्छा समाधान शायद उपयोगकर्ता के लिए एक बाधा जोड़ने के लिए है जो पाइप को कुछ रिलीज से पहले बोटोकोर के संस्करणों पर विचार नहीं करने के लिए कह रहा है जिसे उपयोगकर्ता "हाल ही" मानता है। लेकिन पाइप यथोचित रूप से ऐसी बाधा का आविष्कार नहीं कर सकता है।

मैंने देखा है कि बोटोकोर रिपोर्ट में बहुत अधिक आया है और मुझे आश्चर्य है कि क्या इसे असामान्य रूप से बड़ी संख्या में रिलीज मिली है, या अन्य पैकेजों की तुलना में अधिक असंगत परिवर्तन किए हैं?

एडब्ल्यूएस पैकेज वास्तव में अक्सर जारी किए जाते हैं, और शायद यह तथ्य कि वे इतनी सख्ती से पिन करते हैं, व्यापक बैकट्रैकिंग का कारण है। तो यह न केवल बहुत ढीला लगता है, बल्कि बहुत सख्त आवश्यकता विनिर्देश भी रिज़ॉल्वर के लिए समस्याएं पैदा कर सकते हैं। संघर्षों को तेजी से मजबूर करने के लिए कुछ तरकीबें हैं (उदाहरण के लिए कम से कम संस्करणों के आधार पर हल करने के लिए अगला पैकेज चुनना, और कम से कम निर्भरता वाले पैकेज चुनना, रेफरी https://github.com/sdispater/mixology/pull/5 )

क्लासिक एक्सप्लोडिंग उदाहरण awscli के किसी भी संस्करण के साथ पसंदीदा boto3 संस्करण का संयोजन है, क्योंकि boto3 botocore पर प्रतिबंधात्मक है, और awscli botocore पर भी प्रतिबंधात्मक है।

कुछ पुस्तकालय extras_require प्रदान करके इस समस्या को हल करने का प्रयास करते हैं, उदाहरण के लिए aiobotocore[awscli,boto3]==1.1.2 सटीक पिन लागू करेगा (awscli==1.18.121 boto3==1.14.44) जो एक दूसरे के साथ संगत होने के लिए जाने जाते हैं (बोटोकोर यहां निर्णय ले रहा है) )

यदि दोनों में से बिना पिन के अनुरोध किया जाता है, तो रिज़ॉल्वर को एक को खोजने के लिए बड़ी मात्रा में संस्करणों पर विचार करना होगा जो अतिव्यापी बोटोकोर संस्करणों का अनुरोध करता है।

$ pipgrip --tree boto3==1.14.44 awscli==1.18.121
boto3==1.14.44 (1.14.44)
├── botocore<1.18.0,>=1.17.44 (1.17.44)
│   ├── docutils<0.16,>=0.10 (0.15.2)
│   ├── jmespath<1.0.0,>=0.7.1 (0.10.0)
│   ├── python-dateutil<3.0.0,>=2.1 (2.8.1)
│   │   └── six>=1.5 (1.15.0)
│   └── urllib3<1.26,>=1.20 (1.25.11)
├── jmespath<1.0.0,>=0.7.1 (0.10.0)
└── s3transfer<0.4.0,>=0.3.0 (0.3.3)
    └── botocore<2.0a.0,>=1.12.36 (1.17.44)
        ├── docutils<0.16,>=0.10 (0.15.2)
        ├── jmespath<1.0.0,>=0.7.1 (0.10.0)
        ├── python-dateutil<3.0.0,>=2.1 (2.8.1)
        │   └── six>=1.5 (1.15.0)
        └── urllib3<1.26,>=1.20 (1.25.11)
awscli==1.18.121 (1.18.121)
├── botocore==1.17.44 (1.17.44)
│   ├── docutils<0.16,>=0.10 (0.15.2)
│   ├── jmespath<1.0.0,>=0.7.1 (0.10.0)
│   ├── python-dateutil<3.0.0,>=2.1 (2.8.1)
│   │   └── six>=1.5 (1.15.0)
│   └── urllib3<1.26,>=1.20 (1.25.11)
├── colorama<0.4.4,>=0.2.5 (0.4.3)
├── docutils<0.16,>=0.10 (0.15.2)
├── pyyaml<5.4,>=3.10 (5.3.1)
├── rsa<=4.5.0,>=3.1.2 (4.5)
│   └── pyasn1>=0.1.3 (0.4.8)
└── s3transfer<0.4.0,>=0.3.0 (0.3.3)
    └── botocore<2.0a.0,>=1.12.36 (1.17.44)
        ├── docutils<0.16,>=0.10 (0.15.2)
        ├── jmespath<1.0.0,>=0.7.1 (0.10.0)
        ├── python-dateutil<3.0.0,>=2.1 (2.8.1)
        │   └── six>=1.5 (1.15.0)
        └── urllib3<1.26,>=1.20 (1.25.11)

@ddelange विश्लेषण के लिए धन्यवाद!

झगड़ों को तेज़ करने के लिए कुछ तरकीबें हैं

हम उस विकल्प को #9211 . में तलाश रहे हैं

क्लासिक एक्सप्लोडिंग उदाहरण awscli के किसी भी संस्करण के साथ पसंदीदा boto3 संस्करण का संयोजन है, क्योंकि boto3 botocore पर प्रतिबंधात्मक है, और awscli botocore पर भी प्रतिबंधात्मक है।

दुर्भाग्य से, मैं किसी भी तरह से पैकेज मेंटेनर्स की मदद किए बिना इसे संबोधित करने के किसी भी तरीके के बारे में नहीं सोच सकता (या उपयोगकर्ता स्पष्ट रूप से, और मैन्युअल रूप से, यह बाधित करते हुए कि वे किन संस्करणों को पाइप पर विचार करने के लिए तैयार हैं)।

हो सकता है कि हमें संस्करणों को "डिफ़ॉल्ट रूप से विचार करने योग्य होने के लिए बहुत पुराना" के रूप में चिह्नित करने के लिए एक तंत्र की आवश्यकता हो। लेकिन उस जानकारी को कैसे उजागर किया जाता है, यह परिभाषित करने के लिए पैकेजिंग मानकों की आवश्यकता होगी, और उस जानकारी को प्रबंधित करने के लिए पैकेज अनुरक्षक, इसलिए व्यवहार में मुझे संदेह है कि यह व्यावहारिक होगा।

FYI करें: PEP-643 (पैकेज स्रोत वितरण के लिए मेटाडेटा) को मंजूरी दे दी गई है। मैं

अधिक प्लेटफ़ॉर्म-विशिष्ट/विरासत आदि पैकेजों को अनदेखा करना, क्या यह सैद्धांतिक रूप से संभव हो जाएगा कि पीपीपी के लिए एक बड़ी कॉल में पैकेज के प्रत्येक संस्करण के लिए सभी .whl.METADATA फाइलें प्राप्त करना संभव हो?

पाइपा/वेयरहाउस सर्वर साइड और पीआईपी-यूजर साइड दोनों पर उचित कैशिंग के साथ, यह एक बहुत बड़ा स्पीडअप हो सकता है। जैसा कि आपने पहले उल्लेख किया है:

मैंने देखा है कि अधिकांश रिज़ॉल्यूशन एल्गोरिदम इस धारणा पर आधारित हैं कि निर्भरता डेटा प्राप्त करना सस्ता है

@ddelange यदि प्रमुख लागत + बिल्डिंग पैकेज डाउनलोड कर रही है, तो हाँ। https://github.com/pypa/warehouse/issues/8254 देखें। :)

संपादित करें: @dstufft ने इस बारे में https://github.com/pypa/pip/issues/9187#issuecomment -736792074 में कुछ विस्तार से चर्चा की।

2\. Start a binary search, cut the remaining candidates in half and try with that.
    2a. If it works, start taking the binary search towards the "newer" side (cut that in half, try again, etc).
    2b. If it fails, start taking the binary search towards the "older"side (cut that in half, try again, etc).

यह बाइनरी खोज का बिल्कुल सही उपयोग नहीं है, क्योंकि संस्करणों की सूची वास्तव में उस तरह से "क्रमबद्ध" नहीं होती है, लेकिन यह git bisect के समान ही कार्य करेगी? इसके साथ सबसे बड़ी समस्या यह है कि यदि नवीनतम N संस्करण सभी विफल हो जाते हैं, और पुराने आधे संस्करण विफल हो जाते हैं, तो यह अच्छे संस्करणों को छोड़ देगा, लेकिन मध्य आधा "ठीक" है।

मुझे आश्चर्य है कि एक शोर द्विआधारी खोज/संभाव्य द्विभाजन एल्गोरिथ्म इस दृष्टिकोण को और अधिक मजबूत बना सकता है। https://github.com/choderalab/thresholds/blob/master/thresholds/bisect.py

और एक उदाहरण के रूप में, यह python-dateutil>=2.1,<3.0.0 पर निर्भर करता है। इसलिए यदि आप अजगर-डेटुटिल 3.0.0 और बोटोकोर को स्थापित करना चाहते हैं, तो पाइप को बोटोकोर के हर रिलीज के माध्यम से पीछे हटना होगा, इससे पहले कि यह सुनिश्चित हो सके कि कोई ऐसा नहीं है जो डेटुटिल 3.0.0 के साथ काम करता है।

सबसे अच्छा समाधान शायद उपयोगकर्ता के लिए एक बाधा जोड़ने के लिए है जो पाइप को कुछ रिलीज से पहले बोटोकोर के संस्करणों पर विचार नहीं करने के लिए कह रहा है जिसे उपयोगकर्ता "हाल ही" मानता है। लेकिन पाइप यथोचित रूप से ऐसी बाधा का आविष्कार नहीं कर सकता है।

क्षमा करें अगर यह पहले से ही सोचा गया है और निक्स किया गया है

मुझे आश्चर्य है कि क्या पीआईपी यहां एक धारणा बना सकता है।

दिए गए पैकेज A और B जहां A B पर निर्भर करता है। यदि A संस्करण 10 संस्करणों का समर्थन करता है B <= 5 , तो मुझे लगता है कि पाइप मान सकता है कि A < 10 के संस्करण B > 5 के संस्करणों का समर्थन नहीं करते हैं। मेरे अनुभव में, पैकेज शायद ही कभी निर्भरता पर ऊपरी सीमा का उपयोग करते हैं। और जब वे करते हैं, तो वे शायद ही कभी संख्या में कमी करते हैं (आमतौर पर रखरखाव टक्कर संस्करण, उन्हें कम नहीं करते)। ऐसा लगता नहीं है कि A==9 B<=6 का समर्थन करेगा और अगली रिलीज पर B<=5 तक घट जाएगा। और अगर ऐसा होता है, तो उपयोगकर्ता अभी भी एक स्पष्ट बाधा प्रदान करके इस वातावरण को हल करने के लिए पाइप प्राप्त कर सकता है।

मुझे लगता है कि यह उस मामले में मदद करेगा जहां पीआईपी botocore संस्करणों पर बैकट्रैकिंग रखता है - यह सबसे हालिया संस्करण की जांच कर सकता है, देखें कि यह python-dateutil 3.0.0 समर्थन नहीं करता है और जल्दी से बाहर निकलता है (क्योंकि यह पुराने संस्करणों को मानता है botocore में से python-dateutil के नए संस्करण का समर्थन नहीं करते हैं।

हो सकता है कि हमें संस्करणों को "डिफ़ॉल्ट रूप से विचार करने योग्य होने के लिए बहुत पुराना" के रूप में चिह्नित करने के लिए एक तंत्र की आवश्यकता हो। लेकिन उस जानकारी को कैसे उजागर किया जाता है, यह परिभाषित करने के लिए पैकेजिंग मानकों की आवश्यकता होगी, और उस जानकारी को प्रबंधित करने के लिए पैकेज अनुरक्षक, इसलिए व्यवहार में मुझे संदेह है कि यह व्यावहारिक होगा।

@pfmoore मेरे पास कई शुरुआती विफलताएं थीं जहां निर्भरता रिज़ॉल्वर एक दर्जन से अधिक पैकेज संस्करणों में घूम रहा था और पैकेज से पैकेज मेटाडेटा प्राप्त करने का प्रयास करते समय दुर्घटनाग्रस्त हो गया था कि उनका setup.py पायथन 3 के साथ संगत नहीं था ...

1. मैं उम्मीद करना चाहता हूं कि निर्भरता रिज़ॉल्वर एक संस्करण को एक संस्करण डाउनलोड न करने के लिए पर्याप्त स्मार्ट हो रहा है कि यह _knows_ केवल पायथन 2 है ... निश्चित रूप से सबसे अच्छा तरीका नहीं है, लेकिन इस मामले पर मेरी भावना को बता रहा है।
2. विफलता की स्थिति में संस्करण बाधाओं के बारे में किसी प्रकार के सूचनात्मक संदेश के साथ पैकेज के n+1th (एन के मनमाने ढंग से उचित मूल्य के लिए) संस्करणों को डाउनलोड करने से पहले देना, संभवतः बिल्ड समय समाप्त होने तक 100+ पैकेज डाउनलोड करने से बेहतर है .

विशेष रूप से आपको @pfmoore पर संबोधित नहीं किया गया है, आज कई (> 6) घंटों के लिए पीआईपी की नवीनतम प्रकाशित रिलीज में नए रिज़ॉल्वर से निपटने (और शोध करने) के बाद मेरी सामान्य प्रतिक्रिया।

1. अधिकांश लोगों के मुद्दों के पीछे का मुद्दा "यह एक वैध समाधान नहीं ढूंढ सका" का मामला कम लगता है और अधिक मामला यह है कि चीजों को हल करने के प्रयास में नया रिज़ॉल्वर _पैथोलॉजिकल रूप से लगातार_ हो रहा है। यह महसूस करता है कि नए रिज़ॉल्वर के पास स्पष्ट अनंत लूप और पैथोलॉजिकल सबसे खराब स्थिति प्रदर्शन समय के खिलाफ कोई सुरक्षा उपाय नहीं है। डिफ़ॉल्ट व्यवहार के रूप में _कोई क्यों पाइप को एक घंटे से अधिक समय तक चलने देना चाहेगा। "तेजी से विफल" या "जल्दी छोड़ दें" विकल्प की लाइन के साथ कई सुझाव हैं, जो एक पैकेज के लिए रिज़ॉल्वर की निर्भरता की जानकारी प्राप्त करने के मुद्दे को साथ रखते हैं, 50 संस्करणों पर वापस जा रहे हैं (बिंदु में मेरा एलएक्सएमएल उदाहरण देखें) 4) चूंकि यह एक सीआई बिल्ड पर एक घंटे के दौरान धीमा और धीमा हो जाता है ... ऐसा नहीं लगता कि यह डिफ़ॉल्ट बनाने के लिए तैयार था।

2. स्वीकार्य प्रदर्शन के करीब पहुंचने का एकमात्र तरीका --use-feature=fast-deps के साथ था, लेकिन यहां तक ​​​​कि यह आंशिक शमन है क्योंकि निर्भरता रिज़ॉल्वर खुशी से इतनी दूर चलेंगे कि इसे अब इस तरह से जानकारी नहीं मिल सकती है, और चीजों को फिर से धीमे तरीके से करना शुरू कर देता है। मेरा सबसे अच्छा उदाहरण lxml है जो संस्करण 4.6.1 से 3.7.2 तक तेज़ पथ का उपयोग करता है फिर धीमी गति से डाउनलोड पैकेज टैरबॉल विधि 3.7.1 से उपयोग में थी जब तक कि सीआई 60 मिनट के बाद समय समाप्त नहीं हो जाता, 2.0.8 पर वापस चला गया।

3. उपलब्ध डॉकटर बिल्डिंग टूल्स के विभिन्न संयोजनों की सीमाओं के कारण डॉकर कंटेनरों के लिए सीआई सिस्टम में अक्सर _no pip cache_ होते हैं। अन्य मुद्दों के बावजूद, रिज़ॉल्वर _must_ के प्रदर्शन को मापने में इस मामले के लिए किसी प्रकार का प्रदर्शन परीक्षण शामिल है, 100% स्वच्छ निर्माण वातावरण के साथ कम से कम 100 कुल निर्भरता की उचित आकार की परियोजनाएं, कैश्ड कुछ भी नहीं।

   • रुचि रखने वाले लोगों के लिए नए रिज़ॉल्वर के साथ अपनी स्वयं की प्रदर्शन समस्याओं का निवारण करने के लिए, मुझे इसके आसपास 1 आंशिक तंत्र मिला है https://stackoverflow.com/questions/58018300/using-a-pip-cache-directory-in-docker-builds लेकिन यह प्रयोगात्मक नई सुविधाओं पर निर्भर करता है, इसलिए मैं किसी को भी इस पर भरोसा करने से सावधान करता हूं, और यहां तक ​​​​कि कैश को डॉकर पर्यावरण से मेजबान पर खींचने के लिए भी ... सीआई सिस्टम द्वारा लगाए गए सीमाओं का मुद्दा है जो बाहर रहते हैं जैसे कि मेरे अपने मामले में, भले ही मैंने बिल्ड होस्ट फाइल सिस्टम पर कंटेनर से एक पाइप कैश निकाला हो, सीआई सेवा उस फाइल सिस्टम सामग्री को बिल्ड बॉक्स के 60 मिनट के भीतर फेंक देगी। बेकार।

संपादित करें- फिक्स्ड टाइपोस

क्षमा करें अगर यह पहले से ही सोचा गया है और निक्स किया गया है

यह निश्चित रूप से कुछ ऐसा है जो हमारी चर्चाओं में निहित है, लेकिन हमने इसे कभी भी स्पष्ट रूप से कवर नहीं किया होगा। तो इसे लाने के लिए धन्यवाद।

मुझे आश्चर्य है कि क्या पीआईपी यहां एक धारणा बना सकता है।

समस्या यह है कि यह बहुत खतरनाक मैदान है। बड़ी संख्या में ऐसी धारणाएँ हैं जो पाइप बना सकती हैं जो चीजों को सरल बना सकती हैं, लेकिन अनुभव से पता चला है कि जब भी हम ऐसी धारणाएँ बनाते हैं, तो हमें कुछ पैकेज मिलते हैं जो उन्हें तोड़ देते हैं। और "एक अमान्य धारणा बनाना" हमें "एक बग" के रूप में रिपोर्ट करने की काफी गारंटी है

आपका उदाहरण बहुत ही उचित लगता है, लेकिन क्या होगा यदि एक पैकेज ने python-dateutil <= 3.0 का समर्थन करने वाला संस्करण जारी किया, लेकिन फिर एक ऐसी सुविधा जोड़ी जो व्यवहार पर निर्भर थी जिसे dateutil 3.0 में हटा दिया गया था, इसलिए उन्होंने python-dateutil < 3 के आधार पर अपना अगला संस्करण जारी किया।

मुझे लगता है कि अगर हमने इस तरह के अनुमानों का उपयोग करना शुरू कर दिया है, तो हमें उपयोगकर्ताओं को सक्षम होने पर नियंत्रित करने की अनुमति देने के तरीकों को जोड़ना होगा। और यह बहुत जल्दी जटिल हो जाता है।

मुझे सिद्धांत रूप में विचार पसंद है (काश परियोजनाएं अजीब चीजें नहीं करतीं जो एक पीआईपी डेवलपर के रूप में मेरा काम कठिन बनाती हैं) लेकिन व्यावहारिकता काफी हद तक इसे संभव बनाती है।

@pfmoore मेरी टिप्पणी के बिंदु 3 में मुझे जो मिल रहा था, उसकी तर्ज पर https://github.com/pypa/pip/issues/9187#issuecomment -738103308 - यहां एक "सरल डिफ़ॉल्ट" अनुमानी समाधान जहां "डिफ़ॉल्ट पैकेज संस्करण बैकट्रेस डेप्थ = N " और M के उपयोगकर्ता परिभाषित मूल्य के साथ इसे ओवरराइड करने के लिए एक कमांड लाइन फ्लैग बोटोकोर और अन्य पैकेजों के साथ कुछ मुद्दों को हल करेगा जो बहुत अधिक संस्करण वापस चलते हैं। नए रिज़ॉल्वर के लिए मुझे लगता है कि इस तरह के सरल अनुमान, अच्छी तरह से प्रलेखित चूक, सहायक त्रुटि संदेश और आसान कॉन्फ़िगरेशन के साथ ... बग रिपोर्ट को कम करने के लिए एक लंबा रास्ता तय कर सकते हैं जो अधिक जटिल "स्मार्ट" दृष्टिकोण से आ सकते हैं।

मुझे लगता है कि अगर हमने इस तरह के अनुमानों का उपयोग करना शुरू कर दिया है, तो हमें उपयोगकर्ताओं को सक्षम होने पर नियंत्रित करने की अनुमति देने के तरीकों को जोड़ना होगा। और यह बहुत जल्दी जटिल हो जाता है।

एक उचित बिंदु। मैं पूरी तरह से एक ओएसएस परियोजना पर "बहुत सारे घुंडी" से संबंधित हूं। मैं समझता हूं कि धारणाएं यहां एक कीमत पर आती हैं, और अपने (और पीपी टीम के) निर्णय पर भरोसा करें। उस ने कहा, मुझे लगता है कि ऊपर की धारणा एक उचित है जिसे एक अच्छी तरह से डिज़ाइन किया गया एस्केप हैच दिया गया है। शायद:

• उपयोगकर्ता जिसे पुराने संस्करण की आवश्यकता है, उस संस्करण के लिए बाधा उत्पन्न कर सकता है? यह नए रिज़ॉल्वर के लिए वर्कअराउंड व्यवहार को उपयोगकर्ताओं को स्पष्ट रूप से आवश्यकताओं पर निचली सीमा निर्धारित करने के लिए मजबूर करता है ताकि निर्भरता पर ऊपरी सीमा निर्धारित करने के लिए निर्भरता ऊपरी-बाउंड डाउनग्रेड के कारण पुराने संस्करण की आवश्यकता हो।

• पिप ऊपर वर्णित धारणा को थोड़ा सा बना सकता है, लेकिन आवश्यकतानुसार एक छोटी राशि (बैकट्रैक की एक विन्यास योग्य संख्या के साथ) को भी पीछे कर सकता है। यह धारणा बनाता है कि एक निर्भरता अधिकतम संस्करण में घट जाती है दुर्लभ और अल्पकालिक होती है (उदाहरण के लिए एक पैच रिलीज जारी करें जो डिपो को डाउनग्रेड करता है, अगले संस्करण या दो में ठीक करता है और कैप को फिर से हटा देता है) और हल करेगा:

  क्या होगा अगर एक पैकेज ने अजगर-डेटुटिल <= 3.0 का समर्थन करने वाला एक संस्करण जारी किया, लेकिन फिर एक ऐसी सुविधा जोड़ी जो व्यवहार पर निर्भर थी जिसे डेटुटिल 3.0 में हटा दिया गया था, इसलिए उन्होंने अपना अगला संस्करण पायथन-डेटुटिल <3 के आधार पर एक अल्पकालिक दृष्टिकोण के रूप में जारी किया, जबकि उन्होंने अपनी सुविधा को इस तरह से लागू करने की कोशिश की जो डेटुटिल के नए संस्करणों के साथ काम करती है?

उस ने कहा, मैंने इस बारे में उतना नहीं सोचा है जितना आप सभी के पास है। बस मेरे 2 सेंट।

@jcrist का प्रस्ताव वही धारणा बनाता है जो @dstufft का द्विआधारी खोज का प्रस्ताव करता है: कि पैकेज की न्यूनतम आवश्यक निर्भरता आमतौर पर पैकेज के संस्करणों के माध्यम से आदेशित की जाती है

मुझे लगता है कि सवाल यह है कि क्या जिन मामलों में यह सच नहीं है, वे अक्सर पर्याप्त होते हैं कि यह रिज़ॉल्वर की गति के लायक नहीं है।

जैसा कि यह बेतुका लग सकता है ... मुझे आश्चर्य है कि क्या किसी ने स्थिति का वास्तविक विश्लेषण करने के लिए PyPI पर सभी उपलब्ध पैकेज मेटाडेटा का उपयोग किया है। एक निर्भरता अधिकतम संस्करण में वास्तव में कितनी बार घटती है, इसके लिए एक उचित निचली सीमा की खोज करना संभव होना चाहिए।

मैं उतनी तेज़ी से प्रतिक्रिया नहीं दे पा रहा हूँ जितना अभी सुझाव आ रहे हैं, इसलिए मैं इस चर्चा को अभी के लिए छोड़ दूँगा और बाद में समीक्षा करूँगा। लेकिन क्या मैं रचनात्मक और उपयोगी सुझावों के लिए सभी को धन्यवाद कह सकता हूं। सही होने के लिए यह वास्तव में एक मुश्किल समस्या है, और नए विचार और दृष्टिकोण वास्तव में सहायक होते हैं!

जैसा कि यह बेतुका लग सकता है ... मुझे आश्चर्य है कि क्या किसी ने स्थिति का वास्तविक विश्लेषण करने के लिए PyPI पर सभी उपलब्ध पैकेज मेटाडेटा का उपयोग किया है। एक निर्भरता अधिकतम संस्करण में वास्तव में कितनी बार घटती है, इसके लिए एक उचित निचली सीमा की खोज करना संभव होना चाहिए।

बिल्कुल भी बेतुका नहीं। मेरे पास विश्लेषण के लिए उस डेटा को एकत्र करने का प्रयास कर रहा एक निरंतर कार्य है। समस्या यह है कि, मुझे पीपीपीआई जेएसओएन एपीआई से सामान उपलब्ध है, और यह इकट्ठा करने के लिए एक बहुत बड़ा काम रहा है। लेकिन निर्भरता डेटा प्राप्त करने का अर्थ है PyPI पर हर पहिये को डाउनलोड करना, साथ ही सभी sdists का निर्माण करना (और फिर भी, sdists के लिए मुझे केवल मेटाडेटा मिलता है जो मेरे सिस्टम पर लागू होता है)। मुझे अभी तक यह भी पता नहीं चला है कि उस कार्य को कहाँ से शुरू किया जाए। यहां तक ​​​​कि "केवल प्रतिनिधि पैकेज चुनें" व्यावहारिक नहीं है, क्योंकि मैंने "बोटोकोर" को नहीं देखा होगा और मान लिया था कि यह एक महत्वपूर्ण पैकेज था, अगर मैंने इसे इतनी बार यहां नहीं देखा होता।

(यदि किसी के पास एक पीईपीआई दर्पण है और सभी पहियों से मेडटाडा फाइलों को निकाल सकता है, और कहीं भी उस डेटा को प्रकाशित कर सकता है, तो यह बहुत उपयोगी होगा)।

तो हाँ, यह एक उचित सुझाव है, लेकिन डेटा प्राप्त करने के लिए संपूर्ण पीईपीआई को डाउनलोड करने की रसद आपके विचार से कहीं अधिक कठिन बना देती है। (पाइप देवों के पास पीईपीआई तक कोई विशेषाधिकार प्राप्त नहीं है जो दुर्भाग्य से इसे आसान बना सकता है)।

मैं चीजों को रातोंरात जमा होने दूंगा और देखूंगा कि बातचीत कैसे आगे बढ़ी है। लेकिन अभी के लिए ... @pfmoore (और कोई और उत्सुक ... रात के इस घंटे में इस तरह की चीज़ को चलाने के लिए मेरे लिए थोड़ा देर हो चुकी है) यदि आप उत्सुक हैं तो कुछ शुरुआती बिंदु हैं जिन्हें मैंने देखा है। अगर यह प्रयास किया गया था कि अन्य लोगों से हैं जिन्होंने अतीत में पीईपीआई विश्लेषण "कठिन तरीका" किया है।

• https://martin-thoma.com/analyzing-pypi-metadata/
• https://martin-thoma.com/analyzing-pypi-metadata-2/
• https://kgullikson88.github.io/blog/pypi-analysis.html
• https://ogiardot.wordpress.com/2013/01/05/state-of-the-pythonpypi-dependency-graph/
• https://github.com/ogiardot/meta-deps

... संपादित करें: अंतिम विचार, इस विचार को देखने वाले किसी भी व्यक्ति के लिए, यह जांचना न भूलें कि --use-feature=fast-deps के लिए निर्भरता कैसे पाइप करता है क्योंकि इससे मेटाडेटा कितनी आसानी से प्राप्त होता है, इसमें एक बड़ा अंतर होगा इतने सारे संस्करणों के लिए।

@techdragon ये पोस्ट ज्यादातर कुछ साल पहले के मेले से हैं, और PyPI के पास अब पहले की तुलना में काफी अधिक पैकेज हैं (यहां 2019 की शुरुआत से एक पोस्ट है, जो विकास वक्र दिखा रहा है: https://blog.adafruit.com/2019/03 /13/ग्रोथ-इन-द-पायथन-पारिस्थितिकी तंत्र-पायथन/)। यह मोटे तौर पर घातीय वृद्धि है।

इनमें से कई तकनीकों को अब पहले की तुलना में _महत्वपूर्ण रूप से अधिक संसाधनों की आवश्यकता है। मुझे ऐसा करने के लिए एक गैर-सार्वजनिक प्रयास में कुछ दृश्यता मिली है, और यहां तक ​​​​कि एडब्ल्यूएस से सबसे बड़ी एकल ईसी 2 मशीन के साथ, यह गैर-तुच्छ था और इससे कुछ भी उपयोगी होने से पहले इसे बंद कर दिया गया था।

PyPI पर पैकेज से अभिलेखीय मेटाडेटा के विश्लेषण (और संभवतः मान्य) के मुद्दे पर, लोगों की दिलचस्पी https://github.com/pypa/warehouse/issues/474#issuecomment -370986838 और https://github.com/ में हो सकती है। कि फंडेबल पैकेजिंग प्रोजेक्ट्स की सूची में "ऑडिट और अपडेट पैकेज मेटाडेटा" आइटम में सूचीबद्ध है ।

(यदि किसी के पास एक पीईपीआई दर्पण है और सभी पहियों से मेडटाडा फाइलों को निकाल सकता है, और कहीं भी उस डेटा को प्रकाशित कर सकता है, तो यह बहुत उपयोगी होगा)।

fwiw: मैंने सितंबर 2019 और अगस्त 2020 में प्रत्येक पैकेज की निर्भरता प्राप्त करने के लिए distlib का उपयोग करते हुए PyPI को स्क्रैप किया, और परिणामों को एक फ़ाइल में डाल दिया। परिणाम गड़बड़ और अधूरे हैं (मुझे याद नहीं है कि डिस्टलिब निर्भरताओं को कैसे काम करता है, इसलिए मुझे बिल्कुल _how_ अधूरा नहीं पता), और मेरे पास अभी उन्हें साफ करने का समय नहीं है, लेकिन यह अब यहां उपलब्ध है यदि यह किसी के लिए भी उपयोगी है: https://github.com/sersorrel/pypi-stats

उम्मीद यह है कि लोग पारंपरिक रूप से पसंद किए जाने वाले सामूहिक समुदाय की तुलना में यथोचित सख्त आवश्यकताएं प्रदान करेंगे। ऐसा बहुत कम होता है, जब उपयोगकर्ता "अनुरोध" (उदाहरण के लिए) मांगते हैं, तो वास्तव में अनुरोधों का कोई भी संस्करण ऐसा करेगा; लेकिन पाइथन पैकेजिंग टूल परंपरागत रूप से न्यूज़सेट संभावित संस्करण पर भोलेपन से बसने से उपयोगकर्ता को "मदद" करते हैं। मेरी आशा है कि पायथन पैकेज उपयोगकर्ता और अनुरक्षक समान रूप से एक आवश्यकता निर्दिष्ट होने पर अधिक संदर्भ प्रदान करने में सक्षम होंगे; यह सभी उपयोगकर्ताओं, अनुरक्षकों और टूल डेवलपर्स को एक बेहतर सह-संचालन वातावरण प्रदान करने में मदद करेगा।

यह शीर्ष पर उचित है- संस्करण को कैप करना समझ में आता है क्योंकि आप नहीं जानते कि क्या नए संस्करण काम करने जा रहे हैं (और यह उन पैकेजों के लिए स्पष्ट रूप से आसान है जो सिमेंटिक वर्जनिंग का समर्थन करते हैं)।

समस्या दूसरी दिशा में है- अधिक प्रतिबंधात्मक सीमाएं (उदाहरण के लिए हम केवल लाइब्रेरी X के नवीनतम तीन संस्करणों का समर्थन करते हैं) पैकेजों के बीच संगतता विंडो को कम करती है। यदि आपके पास एक पैकेज है जो ~v1 के साथ काम करता है, लेकिन केवल>v1.46 पर सेट है और दूसरा पैकेज जो v1.40 पर छाया हुआ है, तो आप बिल्कुल भी मैच नहीं ढूंढ पाएंगे।

यह ठीक है अगर यह वैध कारणों से है, लेकिन अगर यह केवल पैकेज मैनेजर से अत्यधिक मुद्दों से निपटने से बचने के लिए हो रहा है तो यह एक समस्या की तरह लगता है। यह एक सरल उदाहरण है- वास्तविक दुनिया में जहां लोग दो से अधिक पुस्तकालयों पर निर्भर हैं, और अनुरक्षक (जो अक्सर मुफ्त में काम करते हैं) केवल एक न्यूनतम संस्करण सेट का समर्थन करने के लिए चिपके रहते हैं, यह बहुत बुरा होगा और इसके परिणामस्वरूप बहुत कुछ होगा ऐसे मामले जहां पाइप मैच नहीं ढूंढ पाएगा।

यहां तक ​​​​कि "सिर्फ प्रतिनिधि पैकेज चुनें" व्यावहारिक नहीं है, क्योंकि मैंने "बोटोकोर" को नहीं देखा होगा और माना कि यह एक महत्वपूर्ण पैकेज था

https://pypistats.org/top

@tedivm ने जो कहा वह सच है - मॉड्यूल डेवलपर्स को उनकी आवश्यकताओं को और अधिक कसकर पिन करने के लिए प्रोत्साहित करके, आप संस्करण नरक के लिए पूछ रहे हैं जहां दो मॉड्यूल एक साथ स्थापित करना असंभव है, भले ही वे वास्तव में काम करेंगे।

गंभीर रूप से पीआईपी अनुरक्षक - कृपया पिछले रिज़ॉल्वर पर वापस आएं और उन सभी समस्याओं का समाधान होने पर बेहतर रिज़ॉल्वर के साथ वापस आएं। कृपया। उन सभी मुद्दों को हल करने का कोई तरीका नहीं है। इसे करने का कोई तरीका नहीं है।

बस इलाज एक सीखने के अवसर के रूप में है। कोशिश करने में कोई समस्या नहीं है लेकिन जब आप देखते हैं कि यह काम नहीं करता है, तो पीछे हटने में कोई शर्म नहीं है।

हाय, @पोटियुक! अपनी सलाह और राय साझा करने के लिए धन्यवाद। हम इसे संज्ञान में लेंगे।

हमने बग रिपोर्ट मांगने के लिए नए पाइप रिज़ॉल्वर के लिए बीटा अवधि चलाई, जिसकी शुरुआत जुलाई में पाइप 20.2 के रिलीज के साथ हुई । जो लोग हमें नए मुद्दों की रिपोर्ट कर रहे हैं: यह वास्तव में हमारी मदद करेगा यदि आप हमें यह भी बता सकते हैं कि अलग-अलग क्या हो सकता है ताकि आप परीक्षण कर सकें और उन समस्याओं को पकड़ सकें और रिपोर्ट कर सकें जो आप पीआईपी रिज़ॉल्वर बीटा अवधि के दौरान देख रहे हैं। इससे कोई फर्क नहीं पड़ता कि हम योजना के अनुसार लीगेसी रिज़ॉल्वर को तोड़ते हैं, इसे अधिक समय तक इधर-उधर रखते हैं, या कुछ और करते हैं, उस बिंदु पर आपकी प्रतिक्रिया हमें भविष्य के रोलआउट में मदद करेगी।

मैंने वास्तव में एयरफ्लो स्टोरी को यहां पहले ही पूरी व्याख्या के साथ साझा किया था कि हमने वास्तव में क्यों कोशिश की, लेकिन https://github.com/pypa/pip/issues/9203#issuecomment -737878689 से पहले नए रिज़ॉल्वर का परीक्षण नहीं कर सका।

@potiuk ऐसा करने के लिए धन्यवाद! यहां अन्य प्रतिभागी - कृपया @potiuk के नेतृत्व का अनुसरण करें।

और बहुत स्पष्ट होना - यह किसी प्रकार की कोई शिकायत नहीं थी। यह सिर्फ सलाह का एक टुकड़ा था। मैं समझता हूं कि आधे इंटरनेट को काम में रखने के लिए आपने कितनी मेहनत की है! यह वास्तव में सुझाव था, और एक उपयोगकर्ता के रूप में अवलोकन था कि अब आप इसे ठीक करने का कोई तरीका नहीं है, हम देखते हैं कि समस्याओं के प्रकार और मात्रा को देखते हुए। यह केवल यथार्थवादी (मुझे लगता है) स्थिति का आकलन है और आपके द्वारा की जाने वाली कार्रवाई का सुझाव दे सकता है।

मैं आपके द्वारा इसमें किए गए सभी कार्यों की सराहना करता हूं! यह इस बार काम नहीं करेगा और मुझे लगता है कि यह अच्छा है कि आप वास्तविकता का सामना करते हैं।

दोनों @potiuk के अंक के लिए एक सेकंड - मैं लंबे समय से पाइप में "उचित" सॉल्वर की कमी के बारे में चिंतित हूं, इसलिए मैं किंक को इससे बाहर निकलने के लिए इंतजार नहीं कर सकता।

और सभी पाइप टीम के लिए HugOps के बराबर डेवलपर!

हो सकता है कि बैकट्रैकर को डिफ़ॉल्ट रूप से 2 बैकट्रैक पर रुकना चाहिए?

यदि कुल बीता हुआ समय एक डिफ़ॉल्ट सीमा से अधिक है, तो क्या डिफ़ॉल्ट रूप से उठाना (और परीक्षण मामले का प्रिंट आउट लेना) समझ में आता है?

(ध्यान दें कि "पैकेज और स्लोलोरिस की एक अनंत श्रृंखला उत्पन्न करें" यहां सबसे खराब स्थिति अभी भी असीमित है जब केवल बैकट्रैक सीमा होती है)

@westurner नहीं, क्योंकि सभी के पास तेज़ इंटरनेट कनेक्शन और/या कंप्यूटर नहीं हैं, इसलिए समय आधारित तरीके ऐसे उपयोगकर्ताओं के लिए डिफ़ॉल्ट रूप से पाइप को अनुपयोगी बना देंगे।

बैकट्रैक की संख्या एक बेहतर अनुमानी होगी।

यह एक लंबा धागा है, जिसमें कई अलग-अलग राय और सुझाव हैं। मैं अपना खुद का अनुभव यहां भी डालूंगा।

काम पर, मैं नए रिज़ॉल्वर का उपयोग कर रहा हूं और यह बहुत अच्छी तरह से काम करता है। हमारे पास ~ 70 जटिल प्रत्यक्ष निर्भरताएं हैं, जिनमें बड़े एमएल ढांचे जैसे pytorch , tensorflow , आदि और boto3 और सामान्य संदिग्ध जैसे requests , Click , Flask । यह सफलतापूर्वक ~ 267 निर्भरता के पूर्ण निर्भरता ग्राफ का समाधान करता है।

उत्पादन प्रणालियों के लिए, मेरी बहुत राय है कि निर्भरता को समय से पहले बंद कर दिया जाना चाहिए। एक परियोजना पर काम कर रहे एक डेवलपर को यह समझने की जरूरत है कि जब वे एक निर्भरता को अद्यतन करते हैं या एक नई निर्भरता जोड़ते हैं तो क्या प्रभाव पड़ता है। मुझे एहसास है कि यह कार्यप्रवाह या राय केवल कार्यप्रवाह या राय नहीं है। मुझे पेशेवरों या विपक्षों पर चर्चा करने में कोई दिलचस्पी नहीं है। मैं केवल वही साझा कर रहा हूं जो मेरे अनुभव में अच्छी तरह से काम करता है और जो मेरा मानना ​​​​है कि वह नियतात्मक और अच्छे परिणामों की ओर ले जाता है।

lock हमारी निर्भरता के लिए, हमारे पास पहले उल्लेख किए गए पाइप-टूल्स का उपयोग करके बहुत सकारात्मक परिणाम हैं।

हमारा वर्कफ़्लो इस प्रकार है:

• डेवलपर requirements.in संशोधित करता है
• डेवलपर एक स्क्रिप्ट चलाता है जो अंततः python3.7 -m piptools compile को आमंत्रित करता है
• डेवलपर रिज़ॉल्यूशन परिणामों को देखता है और लॉक की गई requirements.txt फ़ाइल को रेपो में भेजता है
• सीआई को केवल लॉक की गई requirements.txt फ़ाइल का उपयोग करने की आवश्यकता है जो पहले से ही उचित समय में हल करने की गारंटी है

मैं मानता हूं कि यह केवल "अंतिम उपयोगकर्ताओं" के लिए काम करता है, न कि अन्य परियोजनाओं जैसे एयरफ्लो के लिए जिन्हें "लूसर" निर्भरता की आवश्यकता होती है। हालाँकि, मुझे लगता है कि awscli, boto, airflow जैसी परियोजनाओं पर उनकी निर्भरता पर उचित प्रतिबंध लगाने की कुछ जिम्मेदारी है। जावा और जावास्क्रिप्ट जैसे अन्य भाषा पारिस्थितिकी तंत्र इसे सफलतापूर्वक करने में सक्षम हैं, पायथन को क्यों नहीं करना चाहिए?

मैं कुछ डेटा पर भी ध्यान देना चाहूंगा जो पीईपीआई के कुछ स्थिर विश्लेषण में सहायता कर सकते हैं।
https://github.com/DavHau/pypi-deps-db

ऊपर दिया गया लिंक मच-निक्स से है जो निक्स में उपयोग करने के लिए पायथन को सुखद बनाने के लिए बहुत प्रयास करता है। मैं सुझाव नहीं दे रहा हूं कि पायथन पारिस्थितिकी तंत्र को ऐसे चरम तंत्र की ओर बढ़ने की जरूरत है, लेकिन शायद वह डेटाबेस मदद करेगा अगर कोई चीजों का विश्लेषण करना चाहता है।

एक उपकरण के लिए उचित डिफ़ॉल्ट सीमाएं जो इंस्टॉल-स्तरीय अनुमतियों के साथ निष्पादित करने के लिए कोड के अनंत अनुक्रम को डाउनलोड नहीं करना चाहिए:

• बैकट्रैक की संख्या
  
  
  
  • 100?
  
  
• कुल रनटाइम
  
  
  
  • 1 घंटा?
  
  
• बंडलों की संख्या
  
  
  
  • 1000?
  
  

इन्हें pip.conf और/या PIP_ पर्यावरण चर के साथ ओवरराइड किया जा सकता है।

हमें पूरी तरह से सबसे खराब मामलों में संसाधन खपत (बैंडविड्थ, सीपीयू समय) को सीमित करने का प्रयास करना चाहिए।

निर्भरताओं को पिन करना एक ऐसा समाधान है जो गंभीर गंभीरता के मुद्दों के लिए समय में देरी का परिचय दे सकता है: (जैसे SemVer) बाधाओं के साथ, उपयोगकर्ताओं को पुराने संस्करणों में बंद होने की आवश्यकता नहीं है।

(संपादित करें) हालांकि, निष्पक्ष होने के लिए, पीआईपी पूर्ण सॉफ्टवेयर वितरण जीवनचक्र का प्रबंधन करने का दावा नहीं करता है: pip install -U चीजों को तोड़ सकता है, काम नहीं: हमें उपयोगकर्ताओं से नियमित रूप से pip install चलाने की उम्मीद नहीं करनी चाहिए या फिर भी (जब तक एक कंटेनर को --no-cache TBH के साथ फिर से नहीं बनाया जाता )