Pip: नया रिज़ॉल्वर: रोलआउट, फीडबैक लूप और विकास प्रवाह

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

एक कारण यह है कि यदि आप अधिक कोड साझा कर रहे हैं, तो नए व्यवहार को चालू और चालू करने पर टूटने की संभावना कम होगी, क्योंकि आप दोनों राज्यों में उस साझा कोड का प्रयोग करेंगे और आपके पास ऐसा नहीं होगा व्यवहार में कई संभावित मतभेदों का सामना करना पड़ता है।

इसमें उपयोगकर्ताओं को इसे आज़माने और फ़ीडबैक प्रदान करने के लिए कहने के लिए CTA शामिल होंगे

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

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

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

गिट/गिटहब के संदर्भ में, यह शायद पाइप के भीतर पहला "प्रयोगात्मक" फीचर कार्यान्वयन है

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

मैंने इस एक पोस्ट को लिखने में ~ 60 मिनट (री-री-री-री-री-) बिताए, इसलिए अब मैं न्यूयॉर्क के स्थानों पर एक नज़र डालूंगा! यदि आपको मेरी ओर से कोई त्वरित प्रतिक्रिया दिखाई नहीं देती है, तो इसका कारण यह है कि मैं पर्यटन मोड में रहूंगा।

मैं आपको नए कोड और वर्तमान कोड के बीच जितना संभव हो सके कोड साझा करने का प्रयास करने के लिए प्रोत्साहित करता हूं, और जब आप नए और वर्तमान कोड पथों के बीच अधिक साझाकरण की अनुमति देने के लिए काम कर रहे हैं तो वर्तमान कोड को दोबारा दोहराएं।

निश्चित रूप से! यह 80% है कि मैं इसके आगे 5051 क्यों डाल रहा हूं - मैं अपने निर्माण तर्क में जमा किए गए बहुत सारे तकनीकी ऋण का भुगतान करने का इरादा रखता हूं ताकि इसका पुन: उपयोग करना आसान हो जाए (सभी?) कोड का एक गुच्छा होना चाहिए: आग: और मैं मानता हूं कि बाकी को निश्चित रूप से जितना उचित हो उतना पुन: उपयोग किया जाना चाहिए।

हमने उन्हें "डिफ़ॉल्ट रूप से बंद, उन्हें आज़माने के लिए सक्षम करें" छोड़ने की प्रवृत्ति नहीं की है, यदि आपका यही मतलब है

हाँ, वास्तव में। मैं यहां विकास प्रवाह पर भी इशारा कर रहा हूं - आईएमओ खाली बुनियादी ढांचे को मर्ज करना ठीक होगा (विधियों के समूह के साथ कक्षाएं जो केवल raise NotImplementedError() हैं जो बाद के पीआर में फिसल जाएंगी) या कोई नहीं करता है सभी मामलों (अर्ध-बेक्ड कार्यान्वयन) को master शाखा में कवर करें, जब तक कि इसका उपयोग केवल ध्वज के पीछे किया जाता है जिसे स्पष्ट रूप से "प्रायोगिक/अल्फा" के रूप में जाना जाता है।

पुन: प्रतिक्रिया

मैं युवा, गूंगा और आशावादी हूं -- मैं इस रोलआउट को एक ऑप्ट-इन बनाना चाहता हूं, ताकि सक्रिय प्रतिक्रिया प्राप्त कर सकूं और इस पर कार्य कर सकूं। "प्रोएक्टिव" से मेरा मतलब उन लोगों से है जो अल्फा/बीटा कार्यक्षमता को आजमाने के लिए कुछ अतिरिक्त समय निकालने के इच्छुक हैं और हमें इस बारे में सूचित करते हैं कि यह कैसा है। मुझे लगता है कि अगर हम पर्याप्त शोर करते हैं और रणनीतिक रूप से लक्षित/लोगों तक पहुंचते हैं, तो हम उन लोगों से अच्छी "सक्रिय" प्रतिक्रिया प्राप्त कर सकते हैं जिनके पास विवरण/मुद्दों को दूर करने में मदद करने के लिए नई कार्यक्षमता का प्रयास करने के लिए समय और ऊर्जा है।

हमारे हालिया "प्रमुख" परिवर्तनों को देखते हुए, मुझे लगता है कि हमें प्राप्त अधिकांश प्रतिक्रिया प्रतिक्रियात्मक थी - उपयोगकर्ताओं को उनके वर्कफ़्लो के साथ समस्याओं का एहसास होने पर, और फिर हमें इसके बारे में सूचित करने के लिए पहुंचना। हो सकता है कि उनमें से बहुतों के पास नई कार्यक्षमता के विवरण को समझने में मदद करने का समय न हो, जो बहुत अधिक घर्षण का कारण बनता है। इससे हमें हमारे "मंथन बजट" [1] का बहुत अधिक खर्च आता है, जिसे मैं अधिक खर्च नहीं करना चाहता, क्योंकि पायथन पैकेजिंग में वास्तव में बहुत कुछ नहीं बचा है [2]।

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

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

पुन: अनुदान

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

FWIW, PSF के पास चेंजसेट कंसल्टिंग के साथ PyPA/पैकेजिंग-संबंधित संचार का पता लगाने में मदद करने के लिए एक निरंतर अनुबंध है, इसलिए शायद हम इसका लाभ उठा सकें?

मैं जानबूझकर @ लोगों का उल्लेख नहीं कर रहा हूं क्योंकि बातचीत में और लोगों को जोड़ने की योजना बनाने की स्थिति में यह काफी जल्दी है।

फुटनोट:

1. एक बहुत अच्छा शब्द जिसका @pganssle ने प्रयोग किया है जिसका मैं निश्चित रूप से उपयोग करने जा रहा हूँ।
2. यही कारण है कि मैंने वहां प्रस्तावित "पाइप-क्ली" पैकेज के कार्यान्वयन के बावजूद और रोलआउट को कैसा दिखना चाहते हैं, इस पर उचित सहमति होने के बावजूद, मैंने बैक बर्नर पर #3164 डाल दिया है।

मैं युवा, गूंगा और आशावादी हूं

:-) और मैं कभी-कभी बहुत बूढ़ा, थका हुआ और सनकी हो जाता हूं। आइए आपके दर्शन के साथ चलते हैं, यह बहुत बेहतर लगता है :-)

निश्चित रूप से! यह 80% है कि मैं इसके आगे 5051 क्यों डाल रहा हूं - मैं अपने निर्माण तर्क में जमा किए गए बहुत सारे तकनीकी ऋण का भुगतान करने का इरादा रखता हूं ताकि इसका पुन: उपयोग करना आसान हो जाए (सभी?)

महान!

आईआरसी से अभी :

[सुमनाः] प्रद्युन्सग: क्या ऐसा कुछ है जो हम पाइप और पैकेजिंग समुदाय कर सकते हैं जिससे आपको रिज़ॉल्वर पर अधिक काम तेजी से करने में मदद मिल सके?
....
[pradyunsg] वास्तव में, अभी, https://github.com/pypa/pip/issues/6536 पर इनपुट शायद मुझे यह पता लगाने में मदद करेंगे कि काम कैसे करें/लोगों से प्रतिक्रिया प्राप्त करें आदि।
....
[सुमना] प्रद्युन्सग: पुन: नया रिज़ॉल्वर: रोलआउट, फीडबैक लूप्स और डेवलपमेंट फ्लो # 6536 - जो इनपुट आप चाहते हैं वह कुछ इस तरह है: क्या फीचर फ्लैग दृष्टिकोण एक अच्छा विचार है? क्या पाइप गिटहब मुद्दों के अलावा किसी अन्य तंत्र के माध्यम से प्रतिक्रिया प्राप्त करना एक अच्छा विचार है? क्या अनुदान प्राप्त करना या रीयलवर्ल्ड मैन्युअल परीक्षण और मजबूत परीक्षण बुनियादी ढांचे, और/या सक्रिय कॉमम्स प्राप्त करने के समान ही एक अच्छा विचार है?
...
[pradyunsg] हां -- क्या मैं जो सुझाव दे रहा हूं वह अच्छे हैं। इसके अलावा कोई भी अतिरिक्त विचार/दृष्टिकोण/विचार जो रोलआउट + फीडबैक को आसान बनाने में मदद कर सकते हैं, वे शानदार होंगे।

इसलिए:

क्या फीचर फ्लैग दृष्टिकोण एक अच्छा विचार है? हां।

क्या पाइप GitHub मुद्दों के अलावा किसी अन्य तंत्र के माध्यम से प्रतिक्रिया प्राप्त करना एक अच्छा विचार है? हां। हमें कम विशेषज्ञ उपयोगकर्ताओं से कम संरचित बग रिपोर्ट स्वीकार करने के स्वचालित तरीके खोजने चाहिए।

क्या अधिक मजबूत परीक्षण बुनियादी ढांचे से मदद मिलेगी? हाँ, बहुत कुछ, और यह वह जगह है जहाँ हमारे प्रायोजक हमारी मदद करने में सक्षम हो सकते हैं।

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

क्या उपयोगकर्ता अनुभव, संचार/प्रचार और परीक्षण में अधिक सहायता प्राप्त करने के लिए अनुदान या समान प्राप्त करना एक अच्छा विचार है? हां। पीएसएफ अनुदान संभावित रूप से रुचि का होगा, जैसा कि एनएलनेट अनुदान ( 30,000 यूरो से कम के अनुरोधों के लिए), संभावित रूप से विज्ञान अनुदान के लिए चान जुकरबर्ग आवश्यक ओपन सोर्स सॉफ्टवेयर और मोज़िला का एमओएसएस होगा। पैकेजिंग डब्ल्यूजी रिकॉर्ड का आवेदक हो सकता है। अगर @pradyunsg या @pfmoore "हाँ जो दिलचस्प लगता है" देना चाहता है, तो मैं WG के साथ उन संभावनाओं की जांच शुरू कर सकता हूं।

अगर @pradyunsg या @pfmoore "हाँ जो दिलचस्प लगता है" देना चाहता है,

यह निश्चित रूप से मेरे लिए दिलचस्प लगता है :-)

@pradyunsg या @pfmoore एक "हाँ जो दिलचस्प लगता है" देना चाहता है

_nods_ हाँ यह दिलचस्प लगता है

क्या अधिक मजबूत परीक्षण बुनियादी ढांचे से मदद मिलेगी? हाँ, बहुत कुछ, और यह वह जगह है जहाँ हमारे प्रायोजक हमारी मदद करने में सक्षम हो सकते हैं।

@brainwane यहां भी प्रासंगिक है https://github.com/pypa/integration-test। मुझे लगता है कि इसे स्थापित करना, वित्त पोषण के लिए एक और संभावित क्षेत्र है - हमें इसे https://wiki.python.org/psf/Fundable%20Packaging%20Improvements में जोड़ना चाहिए।

ठीक है! मैंने पैकेजिंग वर्किंग ग्रुप के माध्यम से CZI अनुदान के लिए आवेदन करने के बारे में PSF और चैन जुकरबर्ग इनिशिएटिव के लोगों के साथ बात करना शुरू कर दिया है। मैंने फ़ंडेबल पैकेजिंग इम्प्रूवमेंट पेज में कुछ विवरण जोड़े हैं कि नया पाइप रिज़ॉल्वर क्यों महत्वपूर्ण है, और उस सूची में integration-test प्रोजेक्ट जोड़ा है। और मैंने उपयोगकर्ता अनुभव विशेषज्ञों के नाम एकत्र करना शुरू कर दिया है, जो हमारे जटिल ऑल-ऑन-द-कमांड-लाइन पैकेज वितरण/स्थापना टूलचेन पर शोध करने की क्षमता रखते हैं, उपयोगकर्ताओं के साथ बात करके उनके मानसिक मॉडल को समझने के लिए कि क्या हो रहा है और क्या होना चाहिए , और अनुरक्षकों को सलाह दें।

अगर हमें MOSS, CZI, या NLNET से अनुदान के माध्यम से पैसा मिलता है, तो मुझे लगता है कि हमें पैसा मिल जाएगा ... अक्टूबर जल्द से जल्द, शायद। पीएसएफ से सीधे अनुदान शायद तेज होगा लेकिन "हमारा वर्तमान ध्यान पायथन कार्यशालाओं, सम्मेलनों (वित्तीय सहायता के लिए विशेष रूप से), और पायथन विविधता/समावेशी प्रयासों पर है।"

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

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

उदाहरण के लिए जावास्क्रिप्ट या जंग से आने वाले लोग भी किसी प्रकार की लॉकफाइल की अपेक्षा करेंगे, ताकि इस पर विचार किया जा सके ...

इसमें कूदने के लिए खेद है, इसे आगे बढ़ते हुए देखकर खुशी हुई!

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

इसी कारण से कुछ पीईपी 517 मुद्दों से प्रभावित लोगों में से एक के रूप में, मुझे वास्तव में चीजों का परीक्षण करने का एक ऑप्ट-इन तरीका देखना अच्छा लगेगा। लेकिन मैं केवल इस तरह के सामान के बारे में जानता हूं क्योंकि मैंने --no-use-pep517 ध्वज मुद्दे के बाद सभी पायथन पैकेजिंग समाचार स्रोतों की सदस्यता ली है। मैं जो कह रहा हूं वह यह है कि इस तरह की खबरें फैलाना कठिन है और शायद इसीलिए प्रतिक्रिया प्राप्त करना कठिन है।

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

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

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

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

हालाँकि, जो अधिक उल्लेखनीय प्रतीत होता है, वह यह है कि यदि केवल _one_ फीचर ध्वज के बारे में जानना है,

एक मायने में, क्या यह --pre के रूप में पहले से मौजूद नहीं है? क्या पाइप के लिए बीटा रिलीज़ चैनल केवल pip install --upgrade --pre pip चलाने का मामला हो सकता है?

इसमें कूदने के लिए खेद है, इसे आगे बढ़ते हुए देखकर खुशी हुई!

@techalchemy कृपया, सभी लोगों में से, _you_ को निश्चित रूप से इस चर्चा में शामिल होने के लिए खेद नहीं होना चाहिए।

क्या आप जिस संसाधन की तलाश कर रहे हैं, क्या वह इसकी अनुमति देगा?

एक हद तक, हाँ।

reg: पीआईपी के लिए बीटा रिलीज/"चैनल"

@jriddy और @chrish42 में चिमिंग करने के लिए धन्यवाद। जबकि मुझे लगता है कि आम तौर पर यह निश्चित रूप से एक उपयोगी/महत्वपूर्ण बातचीत है, मुझे यह भी लगता है कि यह इस मुद्दे के लिए थोड़ा ओटी है। कम नहीं, मैं यहाँ एक बार जवाब दूंगा; अगर हम इस पर और चर्चा करना चाहते हैं, तो आइए एक नया मुद्दा खोलें।

हमने अतीत में कोशिश की है - हाल ही में पीआईपी 10 के साथ - लेकिन यह अच्छी तरह से काम नहीं कर पाया है। मुझे इस बात पर थोड़ा संदेह है कि आगे भी यह कितनी अच्छी तरह काम कर सकता है, लेकिन मैं यह भी सोच सकता हूं कि हमारी प्रक्रिया में कुछ बदलावों के परिणामस्वरूप यह हमारे लिए सुचारू रूप से काम कर सकता है। हो सकता है कि हम सुविधाओं या कुछ और का "केवल बीटा" सेट कर सकें? मैंने इसके लिए #5727 में सिंटैक्स के रूप में -X all की कल्पना की थी। हो सकता है कि हम इसे इस रोलआउट योजना के एक भाग के रूप में उठा सकें? आईडीके हमें इसका पता लगाने के लिए समय और ऊर्जा का निवेश करना होगा। :)

जैसा कि https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480 में उल्लेख किया गया है, मुझे लगता है कि एक सॉल्वर पाइप अनुभव को कैसे बदलता है, इसका एक समेकित विवरण होना महत्वपूर्ण है। अधिक कठोर प्रणाली में बदलाव से बहुत से लोग निराश होंगे (भले ही चीजें समग्र रूप से अधिक विश्वसनीय होनी चाहिए, वे उन जगहों पर अवरुद्ध हो जाएंगे जहां वे वर्तमान में अवरुद्ध नहीं हो रहे हैं।

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

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

ध्वज के संबंध में: मुझे लगता है कि कॉन्फ़िगरेशन विकल्प (शायद ध्वज के अतिरिक्त) होना बेहतर है। मैं हर समय झंडा फहराना नहीं चाहता। मुझे यकीन नहीं है कि क्या पाइप में यह क्षमता है - हो सकता है कि आप उन लोगों को बताएं जो संबंधित env var का उपयोग करने के लिए अधिक स्थायी स्विच चाहते हैं?

ध्वज के संबंध में:

पाइप के सीएलआई विकल्प, उपयुक्त नामों के साथ स्वचालित रूप से एक कॉन्फ़िगरेशन फ़ाइल विकल्प और एक पर्यावरण चर के लिए मैप किए जाते हैं।

@msarahan चिंराट करने के लिए धन्यवाद, बहुत सराहना की! :)

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

आप यह भी विचार करना चाहेंगे कि --ignore-installed सॉल्वर के साथ कैसे इंटरैक्ट करता है - जब यह पारित हो जाता है, तो आपको शायद पहले से स्थापित पैकेज के लिए सभी आवश्यकताओं को अनदेखा करना चाहिए।

इसके अलावा, रिज़ॉल्वर के एकीकरण को आसान बनाने के लिए चीजों को छोटे रिफैक्टरिंग पैच के रूप में संभालना एक शानदार तरीका है (यही दृष्टिकोण है जिसने सीपीथॉन के लिए नई कॉन्फ़िगरेशन एपीआई को संभव बनाया: बहुत से निजी रिफैक्टरिंग जो अंततः सार्वजनिक बनाने के लिए पर्याप्त स्थिर थे)

@ncoghlan रिज़ॉल्वर के "ऑप्ट आउट" का क्या अर्थ है? निर्भरता समाधान (और इसलिए रिज़ॉल्वर) से पूरी तरह बचना --no-deps है। मैं समझता हूं कि "इस पैकेज पर संस्करण संघर्षों को अनदेखा करें" या उन पंक्तियों के साथ कुछ की आवश्यकता है।

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

हालांकि, अगर ऐसे उपयोग के मामले हैं जिन्हें इन दो विकल्पों में शामिल नहीं किया जाएगा, तो मैं वास्तव में उनके बारे में जानना चाहता हूं। :)

अधिक व्यापक रूप से, यदि ऐसे वर्कफ़्लो हैं जिनमें एक सख्त रिज़ॉल्वर के व्यवहार के साथ समस्याएं हैं, तो मैं यह जानने के लिए उत्सुक हूं कि वे क्या दिखते हैं, जितनी जल्दी हो सके, यह पता लगाने में सक्षम हो कि उनका समर्थन करना है या नहीं।

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

आईडीके, मैं इस "फीचर" का उपयोग बिल्ड के साथ कुछ सुंदर पागल सामान करने के लिए करता हूं, जैसे ...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

स्थानीय व्हीलहाउस से कुछ पूर्व-निर्धारित पैकेज स्थापित करने के बाद इस मामले में मैं इसे अपनी निर्भरताओं को हल करने के लिए कह रहा हूं। मुझे लगता है कि मैं एक रिज़ॉल्वर को खुश करने के लिए उस स्थानीय-reqs फ़ाइल में अपने सटीक संस्करणों को पढ़ सकता हूं, लेकिन मुझे वास्तव में पाइप के वर्तमान व्यवहार को इस प्रकार के मनमाने निर्माण इंजेक्शन चरणों की अनुमति देने में काफी उपयोगी पाया गया है। स्पेसबार हीटिंग वर्कफ़्लो का मामला हो सकता है, हालांकि, मैं मानता हूँ।

लेकिन हो सकता है कि "बेवकूफ संकल्प" व्यवहार का अभी भी उपयोग हो।

मैं @pradyunsg से सहमत हूं। मुझे नहीं लगता कि मौजूदा कोड और एक नए रिज़ॉल्वर को अनिश्चित काल तक बनाए रखना व्यवहार्य है। निश्चित रूप से एक पिप मेंटेनर के रूप में मुझे ऐसा करने में कोई दिलचस्पी नहीं है।

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

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

क्या कोई अन्य है जिसे मैंने याद किया है? विशेष रूप से कोई भी जहां पुराने रिज़ॉल्वर को बहिष्कृत करना और फिर निकालना संभव नहीं है?

वैसे, "यहाँ एक किनारे का मामला है जिसके बारे में मैंने सोचा" परिदृश्यों को पोस्ट करने के लिए सबसे अच्छी जगह कहाँ है, ताकि वे खो न जाएँ? मुझे लगता है कि अग्रिम में जितनी अजीब परिस्थितियों को इकट्ठा करना उपयोगी होगा, यदि केवल ऐसा है तो हम परीक्षण मामलों को लिखने पर प्रारंभिक शुरुआत कर सकते हैं :-)

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

1. रिज़ॉल्वर बहुत धीमा है (कोंडा देखें)। अगर मुझे 20 मिनट से अधिक रिज़ॉल्वर, या वर्तमान व्यवहार के बीच चयन करना है, तो अक्सर मैं वर्तमान व्यवहार चाहता हूं (या कम से कम कोशिश करें; कई मामलों में यह एक परिणाम देने के लिए होगा जो ठीक है)।

2. मेटाडेटा गलत। आज इतनी समस्या नहीं है, लेकिन ऐसे मामलों की कल्पना करना आसान है जिन्हें हल किया जाना चाहिए लेकिन नहीं। पीईपीआई मेटाडेटा कोंडा/कोंडा-फोर्ज मेटाडेटा से भी बदतर स्थिति में है, और यह पहले से ही कोंडा के लिए एक समस्या है। यदि यह गलत है और एक उपयोगकर्ता के रूप में मुझे कोई समाधान नहीं मिल रहा है, तो मैं कुछ ऑप्ट-आउट करना चाहूंगा।

@rgommers 6 के लिए, "इस पैकेज पर संस्करण संघर्षों को अनदेखा करें" शैली विकल्प काम कर सकता है, है ना?

धन्यवाद, @rgommers - वे अच्छे अंक हैं।

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

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

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

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

@jriddy "संगत होने पर मौजूदा इंस्टॉल का उपयोग करें" की संकल्प रणनीति इसके लिए काम करेगी।

परिदृश्यों को पोस्ट करने के लिए सबसे अच्छी जगह कहां है "यहां एक किनारे का मामला है जिसके बारे में मैंने सोचा था", ताकि वे खो न जाएं?

https://github.com/pradyunsg/zazo/

6 के लिए, "इस पैकेज पर संस्करण विरोधों को अनदेखा करें" शैली विकल्प काम कर सकता है, है ना?

हाँ, यह सही विकल्प लगता है

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

बहुत सारे लोग हैं जो conda प्रदर्शन के बारे में शिकायत कर रहे हैं, और वे सुन रहे हैं - लेकिन यह बहुत काम का है, उनके हाल के ब्लॉग पोस्ट देखें। मुझे नहीं पता कि कोई त्वरित और गंदा कोंडा विकल्प होगा या नहीं। हालांकि, संबंधित समाधान (हैक्स) जैसे conda-metachannel हैं जो आपको तेजी से समाधान प्राप्त करने के लिए निर्भरता ग्राफ (मैन्युअल रूप से शामिल/बहिष्कृत पैकेज) को कम करने देता है। तो मुझे लगता है कि यह उसी तर्ज पर है।

हालांकि, ध्यान रखें कि यह _निश्चित रूप से तब तक आवश्यक होगा जब तक कि आप:

• सीधे कोंडा की तुलना में बहुत बेहतर काम करें (बहुत संभावना नहीं है, ऐसा नहीं है कि वे लोग नहीं जानते कि वे क्या कर रहे हैं - यह वास्तव में बालों वाली समस्या है)।
• हल करने के लिए केवल छोटी समस्याएं हैं (उम्मीद है कि सच नहीं है, पीईपीआई बड़ा है और अच्छे मेटाडेटा के साथ समस्याएं बड़ी होनी चाहिए)

खराब मेटाडेटा निश्चित रूप से कुछ ऐसा है जिस पर मैं विचार करूंगा "हम इसका समर्थन नहीं करेंगे"

काफी उचित। "हम सही मेटाडेटा लागू नहीं करते" पर पूरा रुख हालांकि यहां मदद नहीं कर रहा है। जब तक वह हाल ही में नहीं बदला? (और मुझे पता है, यह एक पीपीपीआई चीज है न कि पीआईपी चीज - लेकिन यह संबंधित है)।

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

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

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

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

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

@wolfv ने हाल ही में कोंडा के लिए libsolv का उपयोग करके पता लगाया। वह अंततः निराश था कि उसे कोंडा के समान उत्तर देने के लिए नहीं मिला। यह दृष्टिकोणों के बीच इस अंतर तक उबल गया। Libsolv एक बैकट्रैकिंग सॉल्वर है। यह चीजों को गति देने के लिए एक वैकल्पिक संकलित ऐड-ऑन के रूप में काम कर सकता है, हालांकि मुझे पता है कि आप सीधे पीआईपी के साथ संकलित कोड को शामिल नहीं करने के प्रति संवेदनशील हैं।

( @pradyunsg ने अभी अपने ब्लॉग पर अगस्त अपडेट पोस्ट किया है।)

कुछ सवाल और जरूरतें जो लोग अभी उठा रहे हैं, वे चीजें हैं जिन्हें हमें अभी इकट्ठा करना शुरू करना है, जैसे परीक्षण मामले।

लेकिन यह भी: इस रोलआउट के लिए हम कौन सी समयरेखा यथार्थवादी सोच रहे हैं? यह बहुत कुछ प्रद्युण के स्वास्थ्य और खाली समय, और अन्य पाइप अनुरक्षकों से कोड समीक्षा उपलब्धता पर निर्भर करता है, और क्या हमें कुछ अनुदान मिलता है जिसके लिए हम आवेदन कर रहे हैं, लेकिन मुझे लगता है कि अनुक्रम कुछ इस तरह है:

• लॉजिक रिफ्लेक्टर का निर्माण: प्रगति पर है, कभी-कभी दिसंबर-फरवरी में किया जाता है
• यूएक्स अनुसंधान और डिजाइन, बुनियादी ढांचे के निर्माण का परीक्षण, डाउनस्ट्रीम और उपयोगकर्ताओं से कॉन्फिग फ्लैग और ट्रांजिशन शेड्यूल के बारे में बात करना: हमें इसके लिए धन की आवश्यकता है; जल्द से जल्द शुरुआत संभवत: दिसंबर है, इसमें 2-3 महीने लगेंगे
• अल्फा परीक्षण करते समय resolvelib/zazo में परिभाषित अमूर्तता का परिचय दें: कुछ महीने लगेंगे, इसलिए, रूढ़िवादी रूप से अनुमान लगाते हुए, मई 2020?
• बेहतर निर्भरता समाधान अपनाना और बीटा परीक्षण करना: ?

क्या यह सही है? मुझे किसकी याद आ रही है?

मैं पूछता हूं क्योंकि कुछ जानकारी इकट्ठा करने का काम एक प्रोजेक्ट मैनेजर और/या यूएक्स शोधकर्ता को करना चाहिए, मेरी राय में, और क्योंकि कुछ प्रगति https://github.com/pypa/packaging-problems/issues/264 और अन्य मुद्दे उन चिंताओं के साथ मदद कर सकते हैं जिन्हें लोगों ने यहां लाया है।

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

चूंकि setup.py / pyproject.toml के अपवाद के बजाय अप्रतिबंधित निर्भरता या >= some_old_version का उपयोग करना नियम है, यह एक समस्या होगी। मुझे वास्तव में परवाह नहीं है कि यह "गलत बाधा" है या सॉल्वर को अलग-अलग विकल्प बनाने की आवश्यकता है - यह पीपीपीआई पर मेटाडेटा की स्थिति है।

इन खुली बाधाओं ने कोंडा को वास्तव में खराब समाधानों का पता लगाने के लिए बहुत सारे डाउनग्रेड की आवश्यकता होती है।

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

वास्तव में, मुझे यकीन नहीं है कि pip _can_ यहां तक ​​कि चीजों को डाउनग्रेड भी कर सकते हैं। इसमें पहले बहुत आक्रामक "सब कुछ अपग्रेड करें" रणनीति थी, अब "आवश्यकतानुसार अपग्रेड करें" बहुत अच्छी तरह से काम करता है। मैंने इसे कभी भी कुछ भी डाउनग्रेड नहीं देखा है, और व्यवहार में यह नियमित उपयोग के लिए बहुत अच्छा काम करता है।

एक उदाहरण डाउनग्रेड जिसे कोंडा के साथ संघर्ष करना चाहिए, लेकिन पाइप नहीं होगा: एनाकोंडा या मिनीकोंडा के उपयोगकर्ता अजगर 3 के साथ अजगर 3.7 से शुरू करते हैं। उपयोगकर्ताओं को कभी-कभी कुछ ऐसा स्थापित करने की आवश्यकता होती है जो केवल अजगर 3.6 के लिए उपलब्ध हो। सॉल्वर को अजगर और अन्य सभी गैर-नोआर्क पैकेजों को डाउनग्रेड करना होगा। यह एक विशेष मामला है जिसे शायद पाइथन संस्करण परिवर्तनों के लिए विशेष व्यवहार करके अनुकूलित किया जा सकता है, लेकिन यह इस बात को दिखाता है कि एक पैकेज में परिवर्तन के लिए दूसरे में डाउनग्रेड की आवश्यकता हो सकती है। "इसने अब तक काम किया है" गूंगा भाग्य है, जो वास्तव में हर समय काम नहीं करता है।

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

pip _can_ चीजों को डाउनग्रेड भी कर सकते हैं।

यह कर सकता है - पाइप के लिए, डाउनग्रेडिंग अपग्रेड करने जैसा एक अनइंस्टॉल-इंस्टॉल कदम है। और यह डाउनग्रेड करता है जब उसे एक बाधा दिखाई देती है जिसे संतुष्ट करने के लिए कहा गया है।

निम्नलिखित सेटअपटूल को डाउनग्रेड करता है - जब तक कि यह पहली चीज है जो पाइप देखता है:

pip install "setuptools < 20.0"

परिदृश्यों को पोस्ट करने के लिए सबसे अच्छी जगह कहां है "यहां एक किनारे का मामला है जिसके बारे में मैंने सोचा था", ताकि वे खो न जाएं?

https://github.com/pradyunsg/zazo/

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

एक उदाहरण डाउनग्रेड जिसे कोंडा के साथ संघर्ष करना चाहिए, लेकिन पाइप नहीं होगा: एनाकोंडा या मिनीकोंडा के उपयोगकर्ता अजगर 3 के साथ अजगर 3.7 से शुरू करते हैं। उपयोगकर्ताओं को कभी-कभी कुछ ऐसा स्थापित करने की आवश्यकता होती है जो केवल अजगर 3.6 के लिए उपलब्ध हो। सॉल्वर को अजगर और अन्य सभी गैर-नोआर्क पैकेजों को डाउनग्रेड करना होगा। यह एक विशेष मामला है जिसे शायद पाइथन संस्करण परिवर्तनों के लिए विशेष व्यवहार करके अनुकूलित किया जा सकता है, लेकिन यह इस बात को दिखाता है कि एक पैकेज में परिवर्तन के लिए दूसरे में डाउनग्रेड की आवश्यकता हो सकती है। "इसने अब तक काम किया है" गूंगा भाग्य है, जो वास्तव में हर समय काम नहीं करता है।

यह एक ऐसा मामला भी है जहां आप सामान्य रूप से _डाउनग्रेड नहीं करना चाहते_। एक उपयोगकर्ता के रूप में, मुझे यह बताने के बजाय एक अपवाद मिलेगा कि पैकेज उपलब्ध नहीं है, और मुझे स्पष्ट रूप से 3.6 स्थापित करने दें यदि मैं यही चाहता हूं।

एक अन्य उदाहरण चैनलों के बीच असंगति है। हालिया उदाहरण: हम पायथन 3.7.3 पर थे, फिर base को 3.7.4 मिला। मुझे उन संस्करण अंतरों की परवाह नहीं है, और अधिकांश उपयोगकर्ता नहीं करेंगे। एक डिफ़ॉल्ट "कुछ भी न करें" "हे .4 > .3 से बेहतर होगा, आइए इसे अपग्रेड करें और फिर अन्य पैकेजों के चैनलों को base में बदलें यदि हमें (भले ही वह उन्हें डाउनग्रेड करता हो)"।

हम पूर्ण रेपोडेटा के लिए एक फॉलबैक प्रदान करते हैं, और समय-आधारित सबसेट को पेश करने की भी योजना बनाते हैं, जिसमें समय पर केवल नवीनतम संस्करण उपलब्ध होते हैं

यह एक बहुत ही उपयोगी सुधार की तरह लगता है।

मानसिकता के रूप में "कचरा अंदर, कचरा बाहर" के साथ समस्या यह है कि सॉल्वर के रखरखाव के रूप में, आप बैग पकड़ रहे हैं। जब तक आपके पास कचरा क्या है, इसके लिए बहुत अच्छे अनुमान नहीं हैं, आप शक्तिहीन हैं।

हां, यह सही है। मुझे लगता है कि प्रत्येक आईडीई, वितरण या "सामान के समूह के लिए सामान्य इंटरफ़ेस" में यह समस्या है।

निम्नलिखित setuptools . को डाउनग्रेड करता है

यह एक उपयोगकर्ता द्वारा अनुरोधित डाउनग्रेड है। एक अप्रत्यक्ष वह है जो मेरा मतलब था (उदाहरण के लिए setuptools<20.0 pyproject.toml` में)। मुझे लगता है कि यह भी काम करेगा, लेकिन व्यवहार में यह दुर्लभ है।

मानसिकता के रूप में "कचरा अंदर, कचरा बाहर" के साथ समस्या यह है कि सॉल्वर के रखरखाव के रूप में, आप बैग पकड़ रहे हैं।

100% सहमत। यह कुछ ऐसा है जिसे बहुत सावधानी से संभालना होगा। लेकिन इसके विपरीत, किसी भी पुराने कबाड़ के लिए एक समझदार व्यवहार करने की कोशिश करना व्यवहार्य नहीं है - हमें कहीं न कहीं एक रेखा खींचनी होगी।

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

और वास्तव में, उपयोग के मामलों के एक बड़े हिस्से के लिए, पुराने और नए रिज़ॉल्वर वैसे भी समान परिणाम देंगे।

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

किसी भी पुराने कबाड़ के लिए एक समझदार व्यवहार करने की कोशिश करना व्यवहार्य नहीं है - हमें कहीं न कहीं एक रेखा खींचनी होगी।

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

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

@rgommers , conda 4.7 इसमें चले गए - मामूली संस्करणों को बदलने के लिए स्पष्ट पायथन स्पेक की आवश्यकता है। लोगों ने इससे नफरत की है। मुझे नहीं पता कि वोकल वाले आबादी का कितना हिस्सा हैं, लेकिन बहुत से लोग वास्तव में यह पसंद नहीं करते हैं कि वे conda install कुछ करने में सक्षम थे, और अब वे नहीं कर सकते। वे कारण के बारे में ज्यादा परवाह नहीं करते हैं, और वे ज्यादातर जवाब से शांत हो जाते हैं, लेकिन इस बीच हमें अभी भी शत्रुता का सामना करना पड़ता है। बस एक और उदाहरण

"दाएं" उपयोगकर्ताओं के लिए कोई मायने नहीं रखता जब वे आपके परिवर्तनों से टूट जाते हैं।

एक अन्य उदाहरण चैनलों के बीच असंगति है। हाल का उदाहरण: हम पायथन 3.7.3 पर थे, फिर आधार को 3.7.4 मिला। मुझे उन संस्करण अंतरों की परवाह नहीं है, और अधिकांश उपयोगकर्ता नहीं करेंगे। एक डिफ़ॉल्ट "कुछ भी न करें" "हे .4> .3 से बेहतर होगा, आइए इसे अपग्रेड करें और फिर अन्य पैकेजों के चैनलों को आधार में बदलें यदि हमें करना है (भले ही वह उन्हें डाउनग्रेड करें)"।

यह बहुत अधिक जटिल बिंदु है। आप मूल रूप से विभिन्न अनुकूलन मानदंड प्रस्तावित कर रहे हैं। आपने https://www.anaconda.com/understanding-and-improving-condas-performance/ पर हमारे ब्लॉग पोस्ट में वर्तमान 11 चरणों को देखा होगा।

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

नमस्ते, इस मुद्दे में मेरा उल्लेख करने के लिए @msarahan धन्यवाद। मैं पहले झंकार करना चाहता था लेकिन समय नहीं मिला।

वास्तव में मैंने libsolv कोंडा स्पेक्स के लिए सॉल्वर के रूप में उपयोग करने के साथ काफी प्रयोग किया। और यह काम करता है - शेष अंतर अब यह है कि कोंडा बिल्ड नंबर के बारे में ज्यादा परवाह नहीं करता है, लेकिन जिस तरह से इसे कोड किया जाता है (और बैकट्रैकिंग सॉल्वर के साथ) libsolv करता है। यहां तक ​​​​कि पूर्ण रेपोडेटा का उपयोग करते समय, libsolv वास्तव में तेज़ है - मैं कहूंगा कि libsolv की गति इतनी तेज़ है कि परेशान न हो :)

लिबसोल्व में मेरा बड़ा योगदान इसे क्रॉस-प्लेटफ़ॉर्म संगत बनाना था ताकि यह अब विंडोज, ओएस एक्स और लिनक्स पर संकलित हो।

मैं पूरी तरह से एक नए रिज़ॉल्वर के लिए libsolv का उपयोग करने की वकालत करता हूं, भले ही यह संकलित कोड का एक ब्लॉब है (कम से कम यह तेज़ है) और @mlschroe मदद के लिए उपलब्ध हो सकता है - उसने libsolv समर्थन के साथ बहुत मदद की कोंडा मैचस्पेक।

दूसरी तरफ मुझे यकीन नहीं है कि रिज़ॉल्वर विकास किस चरण में है और गीला हो गया है, अब बहुत देर हो चुकी है, और गीलेर संकलित कोड स्वीकार्य है या नहीं।

आपने https://www.anaconda.com/understanding-and-improving-condas-performance/ पर हमारे ब्लॉग पोस्ट में वर्तमान 11 चरणों को देखा होगा।

वास्तव में मैंने किया। वह एक अच्छा ब्लॉग पोस्ट था।

आप मूल रूप से विभिन्न अनुकूलन मानदंड प्रस्तावित कर रहे हैं।

ज़रूरी नहीं। मुझे लगता है कि आपका _"बाइनरी संगतता बाधा बनाम एक सादा और सरल संस्करण बाधा"_ बस कुछ ऐसा इंगित करता है जिसे मैं शायद याद कर रहा हूं। मैं जो उम्मीद करता हूं वह यह है कि किसी भी पैकेज में python >= 3.7.4 या == 3.7.4 इसके मेटाडेटा में नहीं होना चाहिए, यह हमेशा == 3.7 होता है (बस scipy के लिए जाँच की जाती है, meta.yaml कहता है python और conda_forge.yml कहते हैं max_py_ver: '37' - समझ में आता है)। इसलिए 3.7.4 को पेश करने से कुछ नहीं होना चाहिए - 3.7.3 चयन करने वाला रिज़ॉल्वर और कुछ और नहीं बदलना 3.7.4 को मजबूर करने और ट्रिगर करने की तुलना में बहुत सस्ता (और आपके 11 चरणों के अनुसार मान्य) है। अप / डाउन-ग्रेड की श्रृंखला।

मान लीजिए कि यह हिस्सा pip रोलआउट योजनाओं के लिए विषय से हटकर हो रहा है, इसलिए इसे कहीं और ले जाने में खुशी हो रही है।

मेरी सलाह है कि सॉल्वर को बहुत डिबग करने योग्य बनाने में बहुत समय व्यतीत करें।

+1

इसके अलावा: इसे यथासंभव मरम्मत योग्य बनाएं (रखें)। pip के साथ यह अच्छी बात है, अगर यह गड़बड़ हो जाती है तो आमतौर पर कोई cd site-packages && rm -rf troublesome_package (संभवतः --no-deps के साथ पुनर्स्थापित करके) कर सकता है और चीजें फिर से काम करती हैं। conda , apt और दोस्तों को इस तरह से सुधारना बहुत कठिन है।

आप मूल रूप से विभिन्न अनुकूलन मानदंड प्रस्तावित कर रहे हैं।

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

पैकेज में अजगर नहीं है> = 3.7.4, न ही == 3.7.4। कोंडा पैकेजिंग में मानक ऊपरी और निचली बाउंड होना है। ये आम तौर पर कोंडा-बिल्ड द्वारा नुस्खा लेखक द्वारा प्रदान की गई जानकारी का उपयोग करके स्वचालित रूप से निर्धारित किए जाते हैं कि एक संगत श्रेणी पर विचार करने के लिए संस्करण के कितने स्थान हैं। पैकेज में>=3.7.2,<3.8.0a0 जैसी बाधाएं हैं, 0a0 अजीबता के साथ इस तथ्य के लिए खाते में है कि प्रीरिलीज संस्करण .0 रिलीज से नीचे हैं, और इस प्रकार <3.8.0 स्पेक से मेल खाते हैं जहां लोग नहीं करते हैं वास्तव में इसकी उम्मीद है।

पैकेज में उनके साथ जुड़ा एक चैनल भी होता है। यह चैनल प्रभावी रूप से संस्करण अनुकूलन का हिस्सा है: https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - चैनल एक सुपर-संस्करण की तरह है, एक स्थान आगे है पैकेज का प्रमुख संस्करण। यदि कोई हल अजगर को नहीं बदलना चाहिए, तो अजगर कल्पना अजगर नहीं हो सकती ==3.7 - यह एक सीमा है, और चैनल उस सीमा को प्रभावित करेगा। विशेष रूप से, एक अजगर ==3.7 कल्पना होना और defaults चैनल से एक इंस्टालेशन के साथ शुरू करना, फिर conda-forge चैनल जोड़ने से बहुत मंथन होगा, क्योंकि आपने नए पायथन पैकेज पेश किए हैं "संस्करण" (चैनल सहित) में उच्च हैं, और आपका अजगर कल्पना उस परिवर्तन के लिए अनुमत है।

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

इसके अलावा: इसे यथासंभव मरम्मत योग्य बनाएं (रखें)। यह अब पाइप के साथ अच्छी बात है, अगर यह आम तौर पर गड़बड़ कर देता है तो कोई सीडी साइट-पैकेज && आरएम-आरएफ परेशानी_पैकेज (संभवतः --नो-डिप्स के साथ पुनर्स्थापित करके) कर सकता है और चीजें फिर से काम करती हैं। कोंडा, उपयुक्त और दोस्तों की पसंद को उस तरह से ठीक करना बहुत कठिन है।

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

(लिबसोल्व स्पर्शरेखा: वापस जब मैं आरएच के लिए काम करता था, मैंने फेडोरा पर "पाइप इंस्टाल सॉल्व" सुरक्षा खामी को बंद करने के लिए https://pypi.org/project/solv/ को पकड़ लिया, क्योंकि libsolv बिल्ड प्रक्रिया एक उत्पन्न नहीं करती है इस समय sdist या व्हील आर्काइव, इसे केवल PyPI पर प्रकाशित करने दें। किसी से भी चैट करने में खुशी हो सकती है, जो उन वास्तविक लाइब्रेरी बाइंडिंग को libsolv की एक बंडल कॉपी के साथ बनाने में रुचि रखता है, बजाय इसके कि अब यह सहज प्लेसहोल्डर है)

मेरी "ऑप्टिंग आउट" टिप्पणी के संबंध में, मेरा मतलब यह नहीं है कि "पुराने इंस्टॉलेशन लॉजिक पर वापस आएं", मेरा मतलब है "संपूर्ण इंस्टॉलेशन अनुरोध को विफल करने के बजाय उन पैकेजों को स्थापित करने से रोकने का विकल्प प्रदान करें जो बाधा उल्लंघन का कारण बनेंगे"।

यम/डीएनएफ पेशकश करते हैं कि उनके --skip-broken विकल्प के माध्यम से (डीएनएफ में वह ध्वज --setopt=strict=0 के लिए उपनाम है), और मुझे लगता है कि pip के रिज़ॉल्वर को एक समान विकल्प प्रदान करना चाहिए।

@ncoglan आह ठीक है। यह समझ आता है।

"इस पैकेज पर संस्करण विरोधों को अनदेखा करें" शैली विकल्प

मैंने पहले ही उल्लेख किया था कि हम ऐसा करेंगे, इसलिए मैं आपकी टिप्पणी से भ्रमित हो गया।

हम तब उसी पृष्ठ पर हैं। :)

@ncoghlan ने डिस्टुटिल्स -सिग पर मेरी प्रस्तावित टाइमलाइन का जवाब दिया और कहा कि यह उचित लगता है।

@pradyunsg - आपके अगले मासिक अपडेट की प्रतीक्षा में!

मैंने इसे फिर से देखने के लिए कुछ समय बिताया, और #7317 दर्ज किया।

मुझे लगता है कि हम लगभग सारगर्भित हैं - पाइप के इंडेक्स इंटरैक्शन पर बहुत सारे काम के लिए धन्यवाद, निर्भरता संकल्प + तर्क अलगाव और सामान्य सफाई का एक गुच्छा बनाएं।

मैंने अभी #7317 बंद किया है। जहां तक ​​​​मैं कह सकता हूं, मेटाडेटा बिल्ड लॉजिक से निर्भरता संकल्प अब डिकूप्ड (पर्याप्त) है। बिल्ड लॉजिक रिफ्लेक्टर अच्छी तरह से आगे बढ़ चुका है और यह अब आगे की प्रगति के लिए अवरोधक नहीं है।

अब हम [पासा] और कविता के रिज़ॉल्वर से संदर्भ लेते हुए, जहां उपयुक्त हो, पीआईपी में [रिज़ॉल्वलिब] एब्स्ट्रैक्शन को लागू करने पर काम करना शुरू कर सकते हैं। :)

@pradyunsg मैं पोएट्री कोडबेस से बेस रिज़ॉल्वर (पबग्रब पर आधारित) निकालने की योजना बना रहा हूं (देखें https://github.com/sdispater/poetry/tree/master/poetry/mixology)। यह ज्यादातर कोड के बाकी हिस्सों से अलग हो गया है, लेकिन अभी भी आंतरिक भागों के संदर्भ हैं जिन्हें मुझे सार करने की आवश्यकता है।

यदि आप इसमें मदद करने में रुचि रखते हैं तो कृपया मुझे बताएं। विचार पबग्रब एल्गोरिथम का एक स्टैंडअलोन कार्यान्वयन है जिसका उपयोग तीसरे पक्ष द्वारा किया जा सकता है और इसे https://pypi.org/project/mixology/ में रखा जाएगा जो वर्तमान में पुराने रिज़ॉल्वर का कोड रखता है।

@sdispater निश्चित रूप से! मुझे नहीं पता कि मैं सीधे (समय की कमी) मदद कर सकता हूं, लेकिन यह बहुत अच्छा होगा यदि आप पबग्रब पोर्ट को बाकी कविताओं से अलग कर सकें!

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

FYI करें, हम ( @wolfv , और @QuantStack टीम सामान्य रूप से) ने पाइप निर्भरता रिज़ॉल्वर के लिए RfP को जवाब दिया है।

प्रस्तावित दृष्टिकोण libsolv सी पुस्तकालय को अपनाने के लिए है, और पीआईपी के संस्करण बाधाओं प्रारूप के लिए libsolv के लिए समर्थन में योगदान करने के लिए है। हम नई पायथन बाइंडिंग के माध्यम से सी लाइब्रेरी का पर्दाफाश करेंगे।

लिबसॉल्व आरपीएम पारिस्थितिकी तंत्र के तहत संघर्ष-कठोर पुस्तकालय है, और इसलिए पहले से ही औद्योगिक पैमाने पर उपयोग किया जाता है।

• Libsolv's को BSD-3-क्लॉज लाइसेंस के तहत वितरित किया जाता है।
• Libsolv कई पैकेजों और रिपॉजिटरी प्रारूपों का समर्थन करता है, जैसे rpm , deb ,
  haiku , conda , arch । महत्वपूर्ण रूप से, स्वरूपों की विविधता और व्यक्त करने के तरीके
  निर्भरता बाधाओं से पता चलता है कि यह एक प्लग करने योग्य प्रणाली है जिसे सक्षम होना चाहिए
  निर्भरता संस्करणों पर बाधाओं के लिए पाइप के सिंटैक्स को समायोजित करने के लिए ..
• पतले मांबा आवरण में कोंडा के सॉल्वर के बजाय लिबसोल्व का उपयोग करते हुए, हम थे
  कोंडा के प्रदर्शन में उल्लेखनीय सुधार करने में सक्षम। (बड़े चैनलों के साथ पैकेज समाधान में कोंडा की सुस्ती मांबा पर काम करने के लिए हमारी मुख्य प्रेरणा थी)।
• यह विंडोज, ओएस एक्स और लिनक्स पर क्रॉस-प्लेटफॉर्म पर काम करता है। ( @wolfv ने libsolv का विंडोज़ पोर्ट किया था)
• यह इष्टतम निर्भरता संयोजनों को खोजने के लिए पूर्ण SAT समाधान करता है और यदि यह सफल नहीं होता है, तो यह संघर्ष समाधान के लिए कार्रवाई योग्य संकेत देता है।

प्रस्तावित दृष्टिकोण libsolv C पुस्तकालय को अपनाना है

उन प्लेटफार्मों के लिए एक फॉलबैक होने की आवश्यकता होगी जो libsolv समर्थन नहीं करता है (उदाहरण के लिए, पाइप में AIX समर्थन पर सक्रिय रूप से काम किया जा रहा है, और आपने BSD का उल्लेख नहीं किया है)। तो libsolv एक प्रदर्शन विकल्प के रूप में जहां उपलब्ध है मेरे लिए व्यावहारिक है, लेकिन हम वास्तव में इसका उपयोग करने की स्थिति में नहीं हैं। (क्या libsolve का एक शुद्ध पायथन संस्करण है, यानी ऐसा कुछ जो समान परिणाम देता है, बस धीमा?)

साथ ही, get-pip.py कैसे काम करेगा? क्या हमें सभी संभावित प्लेटफार्मों के लिए libsolv के लिए बाइनरी शामिल करना होगा? दोबारा, मुझे नहीं लगता, हम शुद्ध-पायथन फ़ॉलबैक का उपयोग करेंगे।

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

नमस्ते @pfmoore

मुझे लगता है कि अतिरिक्त प्लेटफ़ॉर्म समर्थन प्राप्त करना इतना कठिन नहीं होना चाहिए क्योंकि libsolv काफी सीधा-सीधा सी कोड है। मुझे पूरा यकीन है कि libsolv का कोई शुद्ध पायथन संस्करण नहीं है, हालांकि (जो मैं समझता हूं कि एक कमी है, लेकिन पायथन का कोई शुद्ध पायथन संस्करण या पायथन मानक lib भी नहीं है, इसलिए मेरे दिमाग में यह नहीं होना चाहिए अवरोधक)।

मुझे लगता है कि बूटस्ट्रैपिंग के लिए, किसी के पास शुद्ध पायथन पाइप हो सकता है जो हल करने के लिए वर्तमान तंत्र का उपयोग करता है, जो तब libsolv पर आधारित आवश्यक रिज़ॉल्वर lib स्थापित करता है। उदाहरण के लिए, कोई libsolv + पाइप-विशिष्ट पायथन बाइंडिंग के सटीक पैकेज को पिन कर सकता है, और जैसा कि आप वर्णन करते हैं, उन्हें बूस्टर-पाइप से स्थापित करें। यह मेरे लिए पूरी तरह से करने योग्य लगता है, लेकिन आप बेहतर जान सकते हैं कि इसमें क्या शामिल होगा ...

मुझे लगता है कि अतिरिक्त प्लेटफ़ॉर्म समर्थन प्राप्त करना इतना कठिन नहीं होना चाहिए

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

मुझे लगता है कि बूटस्ट्रैपिंग के लिए, एक शुद्ध पायथन पाइप हो सकता है जो हल करने के लिए वर्तमान तंत्र का उपयोग करता है

मैंने ऊपर तर्क दिया है, और मैं इसे यहां दोहराऊंगा, मैं वास्तव में दो रिज़ॉल्वर को पाइप में अनिश्चित काल तक बनाए रखना नहीं चाहता।

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

चर्चा शायद कहीं और बेहतर अनुकूल है, और अधिक विवरण प्रकट होने पर पूरी तरह से बेमानी हो सकती है, लेकिन मैं वास्तव में अपने प्रश्नों को अभी बाहर करना चाहता हूं।

मेरी समझ से, libsolv निर्भरता समाधान के लिए पूरी तरह से SAT सॉल्वर का उपयोग करता है, और इसे हल करने से पहले निर्भरता जानकारी में लोड करने की आवश्यकता होती है। लेकिन पीईपीआई अब तक निर्भरता मेटाडेटा प्रति-पैकेज स्टोर करता है। यहां तक ​​​​कि अगर आप setup.py की रनटाइम-निर्भर प्रकृति को अनदेखा करते हैं, तो भी एसएटी सॉल्वर के लिए आवश्यक जानकारी को कुशलतापूर्वक प्राप्त करना मुश्किल होगा।

आप इस समस्या से निपटने की योजना कैसे बनाते हैं? क्या आप संकुल अपलोड होने पर .solv फ़ाइलें उत्पन्न करने के लिए बुनियादी ढांचे को लागू करने (और तृतीय-पक्ष रेपो कार्यान्वयन के लिए अतिरिक्त कल्पना का प्रस्ताव) करने की योजना बना रहे हैं? या क्या आपके पास सॉल्वर के रूप में उपयुक्त सॉल्व करने योग्य डेटा उत्पन्न करने वाली आपकी आस्तीन में कुछ स्ट्रेजीज हैं, और हो सकता है कि कुछ बैकट्रैकिंग लागू करें क्योंकि नया निर्भरता डेटा आता है?

मुझे इस संबंध में किसी भी मौजूदा काम के बारे में पता नहीं है, और अधिकांश संसाधन जो मुझे मिल सकते हैं, सुझाव देते हैं कि पायथन पैकेजिंग परिदृश्य को सीधे-सीधे एसएटी सॉल्वर की तुलना में कुछ और/अधिक चाहिए। इसलिए मुझे यहां किसी भी संभावना में बहुत दिलचस्पी है।

वे .solv फ़ाइलें केवल कैशिंग के लिए हैं, libsolv को हल करने के लिए उनकी आवश्यकता नहीं है। लेकिन मैं सहमत हूं कि पीईपीआई की निर्भरताओं की गतिशील प्रकृति एसएटी सॉल्वर का उपयोग करना मुश्किल बनाती है।

(अधिक जानकारी के लिए https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit देखें)

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

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

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

मैंने तकनीकी ट्रेड-ऑफ पर आगे की चर्चा के लिए # 7406 दायर किया - @sdispater , @techalchemy , @uranusjr , @wolfv अगर हम रिज़ॉल्वर डिज़ाइन के लिए विभिन्न विकल्पों के बारे में और चर्चा कर सकते हैं तो मैं सराहना करता हूं।

उम्मीदों को जल्दी स्थापित करने के लिए, मैं अगले 2 सप्ताह के लिए यात्रा करने जा रहा हूँ और उम्मीद है कि ~ 9 ​​दिसंबर को सभी चर्चाओं को पूरा करने में सक्षम होगा।

स्थिति अद्यतन: पीएसएफ मोज़िला ओपन सोर्स सपोर्ट और चैन जुकरबर्ग इनिशिएटिव से कुछ फंडिंग प्राप्त करने में सक्षम था, ताकि पाइप रिज़ॉल्वर और संबंधित उपयोगकर्ता अनुभव मुद्दों पर काम करने के लिए ठेकेदारों को नियुक्त किया जा सके । आप हमारे रोडमैप (जिसे मुझे पॉलिश करने की आवश्यकता है) और ब्लॉग और फ़ोरम और मेलिंग सूची पोस्ट और हाल की बैठकों के नोटों से अवगत कराने के लिए देख सकते हैं। मैं जल्द ही इस बारे में कुछ पोस्ट कर रहा हूँ distutils-sig और पैकेजिंग फ़ोरम पर Python's Discourse उदाहरण पर ।

हमारा लक्ष्य है कि पिप की रिज़ॉल्वर सुविधा को जुलाई में पिप 20.2 में रिलीज़ के लिए तैयार किया जाए। (पाइप के लिए त्रैमासिक रिलीज ताल के अनुसार, अप्रत्याशित कठिनाइयां अगली तिमाही में 20.3 तक विलंबित हो सकती हैं।)

@uranusjr :

मेरी समझ से, libsolv निर्भरता समाधान के लिए पूरी तरह से SAT सॉल्वर का उपयोग करता है, और इसे हल करने से पहले निर्भरता जानकारी में लोड करने की आवश्यकता होती है। लेकिन पीईपीआई अब तक निर्भरता मेटाडेटा प्रति-पैकेज स्टोर करता है। यहां तक ​​कि अगर आप setup.py की रनटाइम-निर्भर प्रकृति को अनदेखा करते हैं, तो SAT सॉल्वर के लिए आवश्यक जानकारी को कुशलतापूर्वक प्राप्त करना मुश्किल होगा।

#7819 में प्रोटोटाइप pip resolve कमांड इस जानकारी को बेहतर ढंग से प्राप्त करने के लिए दो तकनीकों का उपयोग करता है (विवरण के लिए उस मुद्दे को देखें):

1. > व्हील को वास्तव में डाउनलोड किए बिना किसी व्हील के यूआरएल से मेटाडेटा फ़ाइल की सामग्री को निकालना।
2. > लगातार json फ़ाइल में प्रत्येक self._resolve_one() कॉल के परिणाम को कैशिंग करना।

(1) के लिए उपयोग की जाने वाली तकनीक व्हील यूआरएल को आवश्यकता स्ट्रिंग्स की सूची में परिवर्तित करने में सक्षम है, जो कि व्हील की सामग्री के केवल कुछ केबी को डाउनलोड करते समय बहुत तेज़ी से निर्भर करती है। #7819 में प्रोटोटाइप तब सुनिश्चित करता है कि req.populate_link() द्वारा लौटाई गई प्रत्येक आश्रित आवश्यकताओं पर self._resolve_one() कहा जाता है, और (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] की मैपिंग को एक सतत जोंस कैश फ़ाइल में संग्रहीत करता है। (1) नई जानकारी तेजी से प्राप्त करता है, (2) पुरानी जानकारी को तेजी से क्वेरी करता है।

जबकि मैं अभी तक libsolv से परिचित नहीं हूँ, मेरा मानना ​​है कि आवश्यकता URL से निर्भरता और उनके URL तक इस मैपिंग की प्रविष्टियाँ SAT सॉल्वर द्वारा आवश्यक परमाणु इनपुट हो सकती हैं। जैसा कि #7189 में दिखाया गया है, लगातार जोंस निर्भरता कैश फ़ाइल ने pip resolve इनवोकेशन को पहले रन के बाद पूर्ण नो-ऑप्स बनने का कारण बना, तब से कमांड लाइन पर 800-900ms ले लिया। यदि (1) और (2) की तकनीकों का उपयोग किया जाता है, तो मेरा मानना ​​​​है कि एक एसएटी सॉल्वर को हर बार पाइप को अविश्वसनीय रूप से लंबे समय तक इंतजार किए बिना पूरा करने के लिए चलाने देना संभव हो सकता है। इस संख्या को और अधिक ठोस बनाने के लिए #7189 में प्रोटोटाइप के शीर्ष पर libsolv को हैक करने का प्रयास करना शायद बहुत कठिन नहीं होगा।

@techalchemy :

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

पैंट में कुछ कोड हुआ करते थे जिससे setup.py -आधारित प्रोजेक्ट (#6273) के लिए एक कंपाइलर और लिंकर को बेनकाब करना आसान हो जाता था, लेकिन बाद में हमने इसे बनाना संभव बनाने के पक्ष में इसे हटा दिया (# 7016 देखें) C/C++ setup.py का उपयोग किए बिना पैंट में, जो ट्विटर के अंदर हमारे उपयोग के मामले के लिए उपयुक्त था जिसे केवल TensorFlow कस्टम ऑपरेटरों के लिए एक साझा लाइब्रेरी बनाने की आवश्यकता थी। हम OSX और Linux के लिए हमारे s3 पर सांख्यिकीय रूप से जुड़े GCC और binutils अभिलेखागार के लिए प्रीबिल्ट बायनेरिज़ की मेजबानी करते हैं (देखें https://github.com/pantsbuild/binaries/) ताकि पैंट उपयोगकर्ताओं को अजगर और JDK के अलावा कुछ भी स्थापित न करना पड़े पैंट का इस्तेमाल बिल्कुल करना।

मुझे सी और सी ++ के पोर्टेबल निर्माण के लिए किसी भी प्रकार के टूलिंग पर विचार-मंथन और/या विकसित करने में मदद करने में दिलचस्पी होगी, जो कि सभी समर्थित प्लेटफॉर्म पर पीआईपी को विश्वसनीय रूप से लिबसोल्व पर निर्भर करने में सक्षम हो सकता है।

@cosmicexplorer

पैंट में कुछ कोड हुआ करते थे जिससे एक कंपाइलर और लिंकर को एक setup.py- आधारित प्रोजेक्ट (#6273) में उजागर करना आसान हो जाता था, लेकिन बाद में हमने इसे हटा दिया (# 7016 देखें) सी/सी ++ बनाना संभव बनाने के पक्ष में। पैंट में setup.py का उपयोग किए बिना, जो ट्विटर के अंदर हमारे उपयोग के मामले के लिए उपयुक्त था जिसे केवल TensorFlow कस्टम ऑपरेटरों के लिए एक साझा लाइब्रेरी बनाने की आवश्यकता थी। हम OSX और Linux के लिए हमारे s3 पर सांख्यिकीय रूप से जुड़े GCC और binutils अभिलेखागार के लिए प्रीबिल्ट बायनेरिज़ की मेजबानी करते हैं (पैंटबिल्ड/बायनेरिज़ देखें) ताकि पैंट उपयोगकर्ताओं को पैंट का उपयोग करने के लिए अजगर और JDK के अलावा कुछ भी स्थापित न करना पड़े।

कंपाइलर/लिंकर का काम बहुत दिलचस्प है! setup.py (या सामान्य रूप से एक पीईपी 517 बिल्ड बैकएंड) से कंपाइलर को डिकूप करने पर भी चर्चा है। यह वास्तव में रिज़ॉल्वर से संबंधित नहीं है (कम से कम सीधे नहीं), लेकिन आपकी रुचि हो सकती है: https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- ड्राइविंग-सी-कंपाइलर/2591

@cosmicexplorer

मुझे सी और सी ++ के पोर्टेबल निर्माण के लिए किसी भी प्रकार के टूलिंग पर विचार-मंथन और/या विकसित करने में मदद करने में दिलचस्पी होगी, जो कि सभी समर्थित प्लेटफॉर्म पर पीआईपी को विश्वसनीय रूप से लिबसोल्व पर निर्भर करने में सक्षम हो सकता है।

Myself और @wolfv इसे Mamba के लिए सभी प्रमुख समर्थित प्लेटफॉर्म पर DNF पैकेज मैनेजर स्टैक के कुछ हिस्सों के निर्माण के लिए देख रहे हैं और DNF के साथ मेरा अपना व्यक्तिगत कार्य। इस समय, libsolv अब विंडोज, लिनक्स, मैकओएस, बीएसडी, हाइकू ओएस के लिए बनाया जा सकता है, और मुझे यूनिक्स पर डीएनएफ का उपयोग करने के हिस्से के रूप में इसे विभिन्न यूनिक्स सिस्टम पर रखा जा रहा है। मुझे पता है कि @dralley ने solv बाइनरी व्हील भी उपलब्ध कराए हैं, जो कि PyPI द्वारा समर्थित ~ प्रमुख प्लेटफॉर्म के लिए उपलब्ध हैं ~ PyPI पर manylinux2014 का उपयोग करके ।

अब हमारे पास 20.1b1 बाहर है, एक बीटा रिलीज़ जिसमें नए रिज़ॉल्वर का एक बहुत प्रारंभिक (अल्फ़ा) संस्करण शामिल है (उस पर संदर्भ के लिए #8099 देखें, और एक सर्वेक्षण जहां लोग प्रतिक्रिया दे सकते हैं)। यहाँ घोषणा है । और https://github.com/pypa/pip/issues/7951#issuecomment -617851381 कुछ स्थानों को सूचीबद्ध करता है जिन्हें हमने अभी तक बीटा प्रचारित किया है।

पाइप 20.1 अब बाहर है और इसमें रिज़ॉल्वर का अल्फा संस्करण शामिल है।

हम मई में एक और पीआईपी रिलीज प्रकाशित करने पर चर्चा कर रहे हैं, जिसमें रिज़ॉल्वर का एक और साथ-साथ अल्फा शामिल है। और हम यह पता लगा रहे हैं कि नए रिज़ॉल्वर का बीटा कब रिलीज़ किया जाए और "कृपया इसका परीक्षण करें" पुश करें।

हम देरी में भाग गए क्योंकि हम # 8371 का पता लगा रहे थे, कुछ त्रुटि संदेशों को बेहतर तरीके से कैसे प्रदर्शित किया जाए, और अन्य बालों वाली चीजों का एक गुच्छा संभालना; हमारी प्रगति पर अधिक जानकारी के लिए https://github.com/pypa/pip/projects/6 और https://github.com/pypa/pip/projects/5 देखें। #8206 आगामी बीटा, पिप 20.2b2 की चर्चा है, जो मुझे आशा है कि हम जून के अंत तक प्रकाशित कर सकते हैं।

मैंने अपनी मध्य-वर्ष की रिपोर्ट पीएसएफ ब्लॉग पर पोस्ट की है । जानने के लिए एक महत्वपूर्ण बात: इस महीने के अंत में हम पाइप 20.2 जारी करेंगे जिसमें नए निर्भरता रिज़ॉल्वर का बीटा संस्करण होगा (पाइप 20.1 में अल्फा संस्करण था) एक वैकल्पिक ध्वज " --use-feature=2020-resolver " के माध्यम से उपलब्ध होगा। हम पीआईपी 20.2 को बहुत प्रचारित करेंगे और बहुत से उपयोगकर्ताओं को अपने पेस के माध्यम से नए रिज़ॉल्वर को रखने के लिए कहेंगे।

प्रति #8511 हमने अब pip 20.2 जारी किया है। इस रिलीज़ में अगली पीढ़ी के निर्भरता समाधानकर्ता का बीटा शामिल है। जब यह असंगत निर्देश प्राप्त करता है तो यह काफी सख्त और अधिक सुसंगत होता है, और कुछ प्रकार की बाधाओं वाली फाइलों के लिए समर्थन को कम करता है, इसलिए कुछ वर्कअराउंड और वर्कफ़्लो टूट सकते हैं। कृपया --use-feature=2020-resolver ध्वज के साथ इसका परीक्षण करें । परीक्षण और माइग्रेट कैसे करें, और समस्याओं की रिपोर्ट कैसे करें, इस बारे में कृपया हमारी मार्गदर्शिका देखें। नया डिपेंडेंसी रिज़ॉल्वर डिफ़ॉल्ट रूप से बंद है क्योंकि यह अभी तक रोजमर्रा के उपयोग के लिए तैयार नहीं है ।

हम अक्टूबर 2020 में पिप की अगली तिमाही रिलीज, 20.3 बनाने की योजना बना रहे हैं। हम डिफ़ॉल्ट निर्भरता समाधान व्यवहार को बदलने और नए रिज़ॉल्वर को पाइप 20.3 में डिफ़ॉल्ट बनाने की तैयारी कर रहे हैं।

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

(#988 से मेरा नोट कॉपी कर रहा हूं।)

@ ज़ूबा ने पूछा :

क्या आपको लगता है कि हमें इस स्तर पर (पहले आरसी के लिए) पायथन 3.9 के साथ बंडल किए गए पाइप के संस्करण को अपडेट करना चाहिए?

इसी तरह, क्या इसकी अगली रिलीज़ के लिए Python 3.8 को अपडेट करने की आवश्यकता है?

मेरी धारणा यह है कि, हाँ, अगले सप्ताह की शुरुआत में बगफिक्स रिलीज़ होने के बाद, हाँ, लेकिन @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft आप क्या सोचते हैं?

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

यहां भी, नए रिज़ॉल्वर तक आसान पहुंच के लिए 3.9 में 20.2.x शामिल करना अच्छा होगा।

क्या सोचते हो?

तुम सही हो, यही योजना है। :)

ठीक है, अजगर-देव पर उत्तर दिया - हाँ, पायथन 3.8 और 3.9 में बंडल किए गए पाइप के संस्करण को 20.2.x पर अपडेट किया जाना चाहिए।

अलग से, प्रचार पर, मैं यहां कुछ कार्य प्रगति पर ध्यान दूंगा:

अगले ~ 6-8 सप्ताह के लिए मैं व्यापक प्रचार पाने के लिए जोर दूंगा ताकि उपयोगकर्ता नए पाइप का उपयोग करने का प्रयास करें। मुझे संदेह है कि समस्या इतनी अधिक नहीं होगी "यह व्यक्तिगत पैकेज स्थापित नहीं होगा"; यह विशेष पैकेजों के बीच अप्रत्याशित संघर्ष होगा, शायद पर्यावरण और विशेष बाधाओं की फाइलों पर निर्भर। हम सर्वेक्षण के माध्यम से कुछ शुरुआती प्रतिक्रिया प्राप्त करने की कोशिश कर रहे हैं ताकि हम बग को ठीक कर सकें, अधिक स्वचालित परीक्षण सेट कर सकें, आदि, और ताकि उन अपस्ट्रीम पैकेजों को हेड-अप मिल सकें और पाइप 20.3 से पहले निश्चित पैकेजों को बाहर कर सकें (उदाहरण : https://github.com/pypa/pip/issues/8076#issuecomment-666493069 में TensorFlow/numpy/scipy मुद्दा)।

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

इसलिए मैं उन समूहों से संपर्क करने और उनका लाभ उठाने की योजना बना रहा हूं जो अपने स्वयं के विशेष डोमेन-विशिष्ट कोनों पर ध्यान देते हैं - डेटा वैज्ञानिक, शिक्षक, कलाकार, DevOps विशेषज्ञ, और इसी तरह।

मैं अनुमान लगाता हूं कि उनका ध्यान आकर्षित करने का एक तरीका उन विशिष्ट पैकेजों के माध्यम से है जिन पर वे भरोसा करते हैं।

कल मैंने व्यापक रूप से उपयोग किए जाने वाले पैकेजों की कुछ सूचियों को देखा और कुछ लोगों को मैन्युअल रूप से ईमेल किया और कुछ रिपॉजिटरी पर मुद्दों को यह सुझाव देने के लिए बनाया कि वे अपने उपयोगकर्ताओं को नए रिज़ॉल्वर के बीटा के साथ परीक्षण करने के लिए कहें, बॉल रोलिंग शुरू करने के लिए और कुछ को आज़माएं कुछ और प्रचार और परीक्षण पाने के लिए शब्द/दृष्टिकोण। इससे कम से कम एक मामले में भ्रम की स्थिति पैदा हुई - https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739 देखें - और एक बार 20.2 की बगफिक्स रिलीज हो जाने के बाद, मैं थोड़ा और हो जाऊंगा के बारे में व्यवस्थित और स्पष्ट

• हम क्यों पहुंच रहे हैं
• हमने किससे संपर्क करना चुना है/कब (सार्वजनिक मीडिया रणनीति से जुड़ने से मदद मिलेगी)
• हम स्वयं इन समस्याओं का पता लगाने के लिए स्वचालित परीक्षण का उपयोग क्यों नहीं कर सकते हैं

हमने ट्विटर ( 1 , 2 ) और रेडिट पर थोड़ा ध्यान दिया है (कोई भी पीपीए फंडिंग के बारे में इस सवाल का जवाब देना चाहता है?)

@zooba ने लिखा (बंडलिंग के संबंध में):

धन्यवाद। ऐसा लगता है कि हम इसे इस सप्ताह के अंत में कर सकते हैं और अगले दौर की रिलीज़ कर सकते हैं। कृपया हमें जल्द से जल्द बताएं यदि कुछ ऐसा सामने आता है जिसे आप रिहा नहीं करना चाहते हैं।

मुझे लगता है कि मेरे लिए --use-feature=2020-resolver आम तौर पर इसके कारण होने वाली समस्याओं से अधिक हल करता है।

क्या इसके माध्यम से प्रारंभिक रोलआउट का सुझाव देने में बहुत देर हो चुकी है:

प्रस्तावित 20.3 स्यूडोकोड

try:
    _2020_resolver()
except:
    legacy_resolver()

जिसका मतलब होगा कि कम से कम मेरी परियोजनाओं के लिए वे सभी बिना संशोधन के पारित हो जाएंगे

उसके बाद, एक बार जब लीगेसी रिज़ॉल्वर डिफ़ॉल्ट रूप से अक्षम हो जाता है, तो मेरे पास कुछ समय के लिए कुछ प्रोजेक्ट हो सकते हैं जो 2020-रिज़ॉल्वर के तहत काम करते हैं और कुछ लीगेसी-रिज़ॉल्वर के तहत नहीं हैं, मैं फ़ॉलबैक को सक्षम करने के लिए एक फ़्लैग सेट करने में सक्षम होना चाहता हूँ:

प्रस्तावित 20.4 स्यूडोकोड

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

हम इस महीने के अंत में 20.3 रोल आउट करने की योजना बना रहे हैं। हम अनुमान लगाते हैं कि इसके लिए बहुत सारे उपयोगकर्ता समर्थन की आवश्यकता होगी क्योंकि भ्रमित उपयोगकर्ता हमसे प्रश्न पूछते हैं।

@di ने स्वेच्छा से कुछ स्वयंसेवकों को पहली प्रतिक्रिया में मदद करने के लिए इकट्ठा करने में मदद की है। ट्विटर, स्टैक ओवरफ्लो, और गिटहब पर - ये स्वयंसेवक सवालों के जवाब देंगे और उपयोगकर्ता समर्थन लोड के साथ मदद करेंगे - और रखरखाव / योगदानकर्ता टीम के ध्यान में वास्तविक बग को बढ़ाएंगे।

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

यहाँ मेरी मोटा योजना है:

• चर्चा शुरू करें.python.org समर्थन मांगते हुए
• लोगों को सीधे स्लैक चैनल पर ले जाएं जो सभी के बीच संचार चैनल के रूप में काम कर सके
• कुछ अक्सर पूछे जाने वाले प्रश्नों और हमारे जवाबों को रेखांकित करते हुए एक दस्तावेज़ शुरू करें
• नए मुद्दे के लिए निर्णय वृक्ष शामिल करें -> त्रिकोणीय मुद्दा
• एक बार हमारे पास एक ज्ञात रिलीज की तारीख होने के बाद इसे चैनल के साथ साझा करें
• रिलीज के बाद के दिनों में स्वयंसेवकों को ऑनलाइन और ट्राइएजिंग करने का प्रयास करें और मोटे तौर पर शेड्यूल करें

धन्यवाद, @di. हम अन्य अनुरक्षकों से ओके प्राप्त करने के लिए कल तक का इंतजार कर रहे हैं। और हम बुधवार या गुरुवार, 28 या 29 अक्टूबर को पिप 20.3 जारी करने का लक्ष्य बना रहे हैं।

@di मैं देख रहा हूँ कि आपकी योजना स्वीकृत हो गई है। कृपया आगे जाएं!

@di रिलीज में संभावित देरी के बारे में सावधान रहें।

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

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

आज की टीम मीटिंग में हम इस बात पर सहमत हुए कि 20.3 रिलीज कल या शुक्रवार को होगी। अधिक जानकारी के लिए आप #8936 को फॉलो कर सकते हैं।

मैंने प्रति-पैकेज आउटरीच उतना नहीं किया जितना मैंने पहले एक टिप्पणी में सुझाया था। लेकिन इसका मतलब यह नहीं है कि हमने कोई आउटरीच नहीं की। हमारे द्वारा किए गए कुछ आउटरीच (जिनमें से कुछ #8511 या इस विकी पेज में सूचीबद्ध हैं):

• पॉडकास्ट: Podcast.__init__ , टेस्ट और कोड , फ्लॉस वीकली , सॉफ्टवेयर डेवलपर्स जर्नी , रियल पायथन
• ट्वीट्स का एक गुच्छा
• परिवर्तनों के बारे में एक छोटा YouTube वीडियो
• PyCon, PSF, और PyPI प्रायोजकों को उनके PSF प्रायोजन संपर्क से ईमेल, उन्हें अपने इंजीनियरिंग विभागों को आने वाले परिवर्तनों के बारे में बताने के लिए कहते हैं
• pypi-घोषणा और इसी तरह की सूचियों को ईमेल करें
• इस तरह के ब्लॉग पोस्ट
• सिविक टेक और इसी तरह के समूहों / थिंक टैंक को ईमेल

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

यहाँ मेरी मोटा योजना है:

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di मैं मानता हूं कि लगातार अनिश्चितता और देरी ने आपको शेड्यूलिंग करने में सक्षम होने से रोक दिया है। नई रिलीज की तारीख कल, सोमवार, 30 नवंबर है। यदि अब आपके पास साझा करने के लिए एक चर्चा सूत्र और एक निर्णय वृक्ष है, तो कृपया आगे बढ़ें और उन्हें साझा करें!

पाइप 20.3 जारी किया गया है, और इसमें डिफ़ॉल्ट रूप से नया रिज़ॉल्वर है! पीएसएफ ब्लॉग पर रिलीज की घोषणा यहां दी गई है: https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html