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

ताकि काफी संभव समाधान (3) IMO मारता है - बैकएंड, क्या एक में जगह बनाने के है की एक अवधारणा नहीं है, तो यह नहीं कह सकता कि क्या इस तरह के एक निर्माण सुरक्षित ¹ है।

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

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

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

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

मैंने समाधान जोड़ा 4। (पीआईपी को हमेशा जगह में बनाने के लिए बदलें) और 5। (पाइप को डिफ़ॉल्ट रूप से जगह में बनाने के लिए एक विकल्प के साथ आउट-ऑफ-ट्री बनाने के लिए बदलें)।

निम्नलिखित कारणों से sdist (समाधान 1.) के माध्यम से निर्माण के संबंध में मेरी मिश्रित भावनाएँ हैं:

1. कुछ परियोजनाओं में टूटा हुआ sdist-to-wheel पथ हो सकता है; जबकि मुझे यह सत्यापित करने का मूल्य दिखाई देता है कि sdists से इमारत काम करती है, इसे डिफ़ॉल्ट रूप से करने से निश्चित रूप से बहुत सारे अंतिम उपयोगकर्ता निर्माण टूट जाएंगे
2. यह अभी भी बड़े sdists वाली परियोजनाओं के लिए और अतिरिक्त सबप्रोसेस कॉल के कारण प्रदर्शन प्रभाव डालता है
3. मुझे व्यक्तिगत रूप से लगता है कि हमें sdists पर बहुत अधिक जोर नहीं देना चाहिए क्योंकि परियोजना के लिए निर्मित कलाकृतियों को प्रकाशित करना और उनके स्रोत रिलीज के लिए उनके पसंदीदा कोड होस्टिंग प्लेटफॉर्म को संदर्भित करना काफी आम है (उदाहरण के लिए, बैकएंड जो वीसीएस चेकआउट की उपस्थिति पर निर्भर करता है। इमारत को एक कार्यशील sdist बनाने के लिए हुप्स के माध्यम से कूदने की आवश्यकता है)। और पीईपी 517 विशेष रूप से बैकएंड को UnsupportedOperation लिए build_sdist बढ़ाने की अनुमति देता है।

चर्चा पर यह

मैं समाधान 3 के लिए मार्ग से सहमत हूं। स्पष्ट से बहुत दूर है।

मैं यह भी मानता हूं कि यदि हम कर सकते हैं तो हमें अतिरिक्त विकल्पों से बचना चाहिए।

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

• एक sdist जगह पर बनाएँ, sdist को एक अस्थायी स्थान पर अनपैक करें, फिर उससे निर्माण करें।

मुझे लगता है कि यह एक अच्छा तरीका है।

आईएमओ संभावना है, यह स्थानीय निर्देशिकाओं से जुड़े अधिकांश pip install रन में एक पैकेज के लिए चलाया जाएगा - आमतौर पर मैं pip install . कल्पना करता हूं। यह संभवतः पैकेज विकास कार्यप्रवाह के भाग के रूप में किया जाएगा।

यहाँ मुझे लगता है कि यह व्यवहार होना चाहिए:

• यदि बैकएंड एक sdist बनाने में असमर्थ है, तो स्थानीय-डीआईआर -> व्हील (इन-प्लेस) करें
  
  
  
  • मुझे लगता है कि यह सुनिश्चित करने के लिए बैकएंड पर बहुत अधिक है कि स्थानीय-डीआईआर -> पहिया इस मामले में एक बेकार ऑपरेशन है।
  
  
• यदि बैकएंड एक sdist बनाने में सक्षम है, तो local-dir -> sdist -> unpacked-sdist -> व्हील करें।

स्थानीय-डीआईआर -> sdist -> पहिया करना, हमारे पास कॉल का एक अतिरिक्त सेट है। हालाँकि, मुझे लगता है कि यह मान्य करना उचित है कि उत्पन्न sdists समझदार हैं, खासकर विकास के दौरान। tox पहले से ही इसे अपने वर्कफ़्लो के हिस्से के रूप में करता है, यहां सेटअपटूल के गैर-अनुकूल इंटरफेस के लिए कवर करने के लिए चेक-मैनिफेस्ट करें।

कुल मिलाकर, मुझे लगता है कि जब एक स्थानीय निर्देशिका दी जाती है तो एक sdist के निर्माण की लागत परियोजनाओं में ऐसी त्रुटियों को रोकने के लिए इसके लायक होती है, खासकर जब से स्थानीय निर्देशिका से स्थापित करने वाले लोग स्वयं परियोजना के डेवलपर्स होते हैं।

रोलआउट के संबंध में, मुझे लगता है कि हम प्रतीक्षा करना चाहते हैं और देखना चाहते हैं कि #6536 कैसे आता है। हम निश्चित रूप से कुछ चीजें सीखेंगे जिन्हें स्थानांतरित किया जा सकता है।

मैं sdist (इसलिए setup.py install या setup.py bdist_wheel या लागू होने पर PEP 517 बैकएंड पर build_wheel पर कॉल किए बिना इन-प्लेस बिल्डिंग/इंस्टॉल करना पसंद करता हूं) बनाम एक sdist बनाना, अनपैक करना और इंस्टॉल करना उसमें से। मेरे विशिष्ट कारण हैं:

1. बॉक्स से बाहर के उपयोगकर्ताओं की सबसे बड़ी संख्या का समर्थन करता है।
   
   
   
   1. मान लें कि पीआईपी स्थानीय-डीआईआर -> स्थापित (व्हील बिल्ड इन-प्लेस या setup.py install ) करता है। जो उपयोगकर्ता स्थानीय-डीआईआर -> स्थापित से जाना चाहते हैं, वे pip install local-dir निष्पादित कर सकते हैं। स्थानीय-डीआईआर -> sdist -> स्थापित से जाने के इच्छुक उपयोगकर्ता एक sdist बनाने और फिर निष्पादित करने के लिए स्वतंत्र हैं pip install ./path/to/sdist । बहुत सारे वैकल्पिक उपकरण हैं जो एक sdist का निर्माण कर सकते हैं, और यह कुछ ऐसा है जो उपयोगकर्ताओं के पास पहले से ही होने की अधिक संभावना होगी जब तक कि वे उन वितरणों को हाथ से तैयार नहीं कर रहे हैं जो वे PyPI पर अपलोड करते हैं।
   
   
   2. अब मान लें कि pip करता है local-dir -> sdist -> install। जो उपयोगकर्ता स्थानीय-डीआईआर -> स्थापित से जाना चाहते हैं, उनके पास कोई विकल्प नहीं है जिसमें पाइप शामिल हो। स्थानीय-डीआईआर -> sdist -> स्थापित से जाने के इच्छुक उपयोगकर्ता pip install local-dir निष्पादित कर सकते हैं। बिना विकल्प वाले उपयोगकर्ता व्यवहार को नियंत्रित करने के लिए पाइप से विकल्प मांगेंगे या उन्हें कोई अन्य उपकरण खोजना होगा जिसकी उन्हें अन्यथा आवश्यकता नहीं होती।
   
   
2. यदि हम स्थानीय-डीआईआर -> sdist -> स्थापित लागू करते हैं, तो संभवतः हम इसे वीसीएस-आधारित आवश्यकताओं के लिए भी करेंगे? यदि ऐसा है तो यह और काम है। यदि नहीं, तो यह कोड के माध्यम से अतिरिक्त पथ है और स्थापना को संभालने के तरीके में विचलन है जिसे उपयोगकर्ताओं द्वारा या समर्थन प्रदान करते समय याद रखना होगा।
3. लागू करने के लिए कम से कम काम। स्थानीय-डीआईआर -> स्थापित ( यहां , यहां , और यहां ) को लागू करने के लिए बदलने के लिए तीन स्थान हैं। स्थानीय-डीआईआर के लिए -> sdist -> स्थापित मैं इसे तब तक लागू नहीं करना चाहता जब तक कि # 6607 नहीं किया जाता है, अन्यथा मुझे लगता है कि यह कोड बेस में कई जगहों पर आर्टिफैक्ट डाउनलोडिंग/हैश चेकिंग के समान समाप्त हो जाएगा।
4. परीक्षण के लिए कम से कम काम, आईएमओ, मौजूदा परीक्षण स्थानीय-डीआईआर -> स्थापित कोड पथ को कवर करने के लिए पर्याप्त हैं। स्थानीय-डीआईआर -> sdist -> स्थापित पथ के लिए हम यह सत्यापित करना चाहेंगे कि हम वास्तव में एक sdist का निर्माण कर रहे हैं, और यह कि फ़ॉलबैक सीधे एक पहिया बनाने के लिए काम करता है।
5. काम की न्यूनतम राशि (कम्प्यूटेशनल रूप से)। जैसा कि कहीं और उल्लेख किया गया है, स्थानीय-डीआईआर -> sdist -> स्थापित एक अतिरिक्त उप-प्रक्रिया कॉल है (और वह उप-प्रक्रिया काम कर रही है)। इसका मतलब यह भी है कि पहिया निर्माण करने से पहले पाइप को sdist (हैलो वायरस स्कैनर और अन्यथा धीमी डिस्क) को खोलना होगा।

दृष्टिकोण के बावजूद, केवल एक ही मुद्दा जो मैं चीजों को करने के साथ देखता हूं, वह यह है कि सेटपूल के निर्माण के लिए (मुझे लगता है कि यह विरासत और पीईपी 517 के लिए लागू होता है) हम परियोजना निर्देशिका में .egg-info साथ समाप्त हो जाएंगे जो गलत हो जाएगा एक "स्थापित पैकेज" के रूप में जब उस निर्देशिका में python -m pip साथ पाइप लगाया जाता है। यह #4575 द्वारा तय किया जाएगा जो संभवतः किसी भी योजना के लिए स्थापित पैकेज के लिए क्वेरी में वर्तमान निर्देशिका को शामिल नहीं करेगा।

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

फेडोरा में, जब हम पायथन आरपीएम पैकेज बनाते हैं, तो हम डायनासोर होते हैं और थिन करने का मानक तरीका python setup.py build । पीईपी 517 के साथ हमने इसके बजाय pip wheel का उपयोग करने का "अनंतिम" तरीका जोड़ा। हालांकि एक्सटेंशन मॉड्यूल के साथ हमें "स्रोतों को tmp पर ले जाएं, वहां से बनाएं" दृष्टिकोण के साथ समस्या है जो पाइप उन्हें बनाने के लिए उपयोग करता है।

हमारी बिल्ड मशीनरी कुछ कंपाइलर फ़्लैग्स को इंजेक्ट कर रही है ताकि बिल्ड आर्टिफ़ैक्ट्स (इस मामले में .so एक्सटेंशन मॉड्यूल) में उनके स्रोतों के बारे में मेटाडेटा हो। बाद में एक शेल स्क्रिप्ट होती है जो बिल्ड कलाकृतियों का पता लगाती है, इस जानकारी को निकालती है और एक विशेष *-debugsource RPM के माध्यम से स्थापित करने के लिए स्रोतों को /usr/src/debug कॉपी करती है। महसिनरी को उम्मीद है कि सब कुछ काम करने वाले पेड़ के भीतर बनाया जाएगा और बाहर बनाए जाने पर यह वास्तव में अच्छा काम नहीं करता है। यहां वे चीजें हैं जो हमारी तरफ से समस्या को कम करने के लिए (एक साथ) की जा सकती हैं:

1. $TMPDIR पर्यावरण चर को उस स्थान पर रखने के लिए सेट करें जहां आरपीएम स्क्रिप्ट इसकी अपेक्षा करती है (यानी export TMPDIR=%{_builddir}/.tmp (और इसे बनाएं))
2. कॉपी किए गए स्रोतों को $TMPDIR में रखने के लिए pip wheel साथ --no-clean विकल्प का उपयोग करें
3. सही स्थान पर "मेरा स्रोत क्या है" जानकारी को फिर से लिखने के लिए कुछ शेल कुंग फू चलाएँ: find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"
4. (वैकल्पिक: $TMPDIR मैन्युअल रूप से साफ़ करें।)

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

• /usr/lib/rpm/debugedit एपीआई और स्थान (और अस्तित्व)
• pip-req-build नाम
• वह तंत्र जिसके साथ पाइप स्रोत बनाता है

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

डाउनस्ट्रीम रिपोर्ट: https://bugzilla.redhat.com/show_bug.cgi?id=1806625

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

मैं इन-प्लेस व्हील बिल्ड करने के विचार को स्वीकार करने के लिए भी इच्छुक हो रहा हूं। मेरे शेष आरक्षण हैं:

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

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

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

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

क्या "क्लीन" हुक को शामिल करने के लिए PEP 517 इंटरफ़ेस का विस्तार करना समझदारी होगी?

शायद? लेकिन अगर पीआईपी स्वचालित रूप से clean कॉल करता है, तो कोई ऐसा व्यक्ति होना चाहिए जो ऐसा

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

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

मैं इसे एक स्पष्ट आवश्यकता बनाने के लिए PEP-517 का विस्तार करने का लुत्फ उठाऊंगा।

मैं इसे एक स्पष्ट आवश्यकता बनाने के लिए PEP-517 का विस्तार करने का लुत्फ उठाऊंगा।

यह पहले से ही यह कहता है:

बैकएंड मध्यवर्ती कलाकृतियों को कैश स्थानों या अस्थायी निर्देशिकाओं में संग्रहीत कर सकता है। किसी भी कैश की उपस्थिति या अनुपस्थिति से बिल्ड के अंतिम परिणाम में कोई महत्वपूर्ण अंतर नहीं आना चाहिए।

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

फेडोरा के लिए कोई समाधान निकालने की कोशिश करते समय, हम https://github.com/pypa/pip/issues/7872 से प्रभावित हुए हैं

चूंकि हमने #7731 और दोस्तों के साथ ".egg-info in cwd" समस्या का समाधान कर लिया है, इसलिए निर्माण करते समय चिंता की कोई बात नहीं है।

तो #7882 में विकल्प 4 (हमेशा बिल्ड इन प्लेस) लागू किया गया था।

हमने अब (प्रति #7951) पीआईपी, पीआईपी 20.1बी1 का बीटा रिलीज प्रकाशित किया है। इस रिलीज़ में #7882 शामिल है, जिसने इस समस्या का समाधान लागू किया।

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

मैं "याय, यह अब बेहतर काम करता है!" की तर्ज पर सकारात्मक प्रतिक्रिया का भी स्वागत करता हूं। साथ ही, चूंकि इश्यू ट्रैकर आमतौर पर "मुद्दों" से भरा होता है। :)

हम पूरी तरह से फेडोरा में इसका परीक्षण करने की योजना बना रहे हैं (हमने आपकी टिप्पणी से पहले ही इसकी योजना बनाई है), हालांकि मंगलवार की समय सीमा शायद यथार्थवादी नहीं है।

@hroncok कोई विचार जब फेडोरा इन परिवर्तनों का परीक्षण करने में सक्षम हो सकता है?

मैं इसे सोमवार को किसी तरह करने की पूरी कोशिश करूंगा, हालांकि मैं कोई वादा नहीं कर सकता।

दरअसल, 20.1b1 हमारी समस्याओं को दूर कर देता है।

अधिक सामान्य 20.1b1 फ़ीडबैक https://mail.python.org/archives/list/[email protected]/message/5EAUIYYIRKXEHTAG5GQ7EJHSXGZIW2F7/ में

हुर्रे! @hroncok बीटा को आज़माने के लिए बहुत-बहुत धन्यवाद! बहुत सराहना की! ^>^

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

@manthe कि चर्चा #8168 . के तहत है

तो अब 10 दिन से अधिक हो गए हैं। परिवर्तन के बारे में कुछ मुद्दे उठाए गए थे (सभी अपेक्षित थे कि मैं कहूंगा - #8165, #8168, #8196)। ऐसे लोग भी थे जो स्पष्ट रूप से परिवर्तन का उल्लेख कर रहे थे जिससे उन्हें मदद मिल रही है।

• प्रदर्शन के मुद्दों के अलावा, पिछले व्यवहार (अस्थायी डीआईआर की प्रतिलिपि) में शुद्धता के मुद्दे थे (ऊपर लिंक किए गए) जो कि संदर्भ ज्ञान के बिना पीआईपी द्वारा ठीक करना असंभव है जो केवल कॉलर के पास है (और, एक साइड नोट के रूप में, कॉपीट्री कोड पहले से ही भरा हुआ था अजीब स्थितियों से निपटने के लिए बैंड-एड्स - पेड़, सॉकेट आदि में tmpdir)।
• पिछले व्यवहार को सक्रिय करने के विकल्प में अभी भी शुद्धता और प्रदर्शन संबंधी समस्याएं होंगी।
• एक सही समाधान में बिल्ड निर्देशिका को नियंत्रित करने के लिए बैक-एंड समर्थन शामिल होगा जो आज पूरी तरह से मौजूद नहीं है (उदाहरण के लिए, setuptools bdist_wheel में --bdist-dir , लेकिन फिर भी .egg-info में लिखता है जगह, https://github.com/pypa/setuptools/issues/1816, https://github.com/pypa/setuptools/issues/1825) भी देखें। तो अब जब पाइप सही ढंग से व्यवहार करता है तो चर्चा यह देखने के लिए स्थानांतरित हो सकती है कि, उदाहरण के लिए, सेटअपटूल स्रोत निर्देशिका को छूए बिना निर्माण करने का विकल्प विकसित कर सकता है और फिर देखें कि उस विकल्प को नियंत्रित करने के लिए पीईपी 517 परिवर्तन की आवश्यकता है या नहीं।
• इस बीच, रिपोर्ट किए गए मुद्दों को कॉल करने वालों द्वारा काम करना अपेक्षाकृत आसान है (उदाहरण के लिए खुद को एक अस्थायी निर्देशिका में कॉपी करके, या एक अस्थायी टैरबॉल बनाकर, जो वे संदर्भ के पूर्ण ज्ञान के साथ सही ढंग से कर सकते हैं)।
• अंत में, हमारे पास मौजूद डेटा के साथ निश्चित रूप से बताना मुश्किल है, लेकिन मेरा अंतर्ज्ञान यह है कि यह परिवर्तन अधिक लोगों की मदद करता है जितना कि इससे नुकसान होता है।

इसलिए मुझे परिवर्तनों को तोड़ने से नफरत है, लेकिन यह हल्के ढंग से नहीं किया गया था, और इन कारणों से, मैं व्यक्तिगत रूप से इसे रखने के लिए इच्छुक हूं।

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

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

मैंने "सही ढंग से" शब्द का इस्तेमाल किया, क्योंकि pip wheel <localdir> और pip install <localdir> से पहले कुछ मामलों में cd <localdir> ; setup.py bdist_wheel तुलना में एक अलग पहिया उत्पन्न कर रहे थे: सिम्लिंक की उपस्थिति में विभिन्न लापता फाइलों के साथ (# 3500), या setuptools_scm (#7549), या https://github.com/pypa/pip/issues/7555#issuecomment -595180864, ​​या #6276, या सामान्य त्रुटियों के साथ एक अलग संस्करण। मुझे नहीं लगता कि पीआईपी 20.1 ऐसे खराब पहिये/इंस्टॉल उत्पन्न करता है, इसलिए उस अर्थ में मेरा मानना ​​​​है कि यह वास्तव में अधिक सही है।

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

और यह अभी भी setup.py sdist && pip install dist/*.tar.gz से भिन्न पहियों का उत्पादन कर सकता है।

मेरा सुझाव होगा कि पीआर को वापस लाया जाए और पहले एसडिस्ट के माध्यम से फेरबदल करके और फिर परिणामी एसडिस्ट से एक पहिया का निर्माण करके फिक्स को लागू किया जाए।

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

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

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

जैसा कि पुरानी कहावत है, पहले इसे सही करें, फिर इसे तेज करें। मुझे डर है कि इस पीआर के साथ हमने इसे तेज कर दिया है और इसे सही करने की हमारी क्षमता को बंद कर दिया है।

मैं अभी भी सहमत हूं कि sdists को मान्य करना वांछनीय है लेकिन पाइप स्थापित समय पर नहीं। हो सकता है कि यह भविष्य के sdist बिल्डर टूल या pip बिल्ड कमांड की विशेषता हो।

साथ ही, setup.py sdist स्थानीय निर्देशिका में .egg-info बनाता है, इसलिए केवल-पढ़ने के लिए स्रोत डीआईआर या समवर्ती बिल्ड के साथ रिपोर्ट की गई समस्याएं बनी रहेंगी।

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

कुछ प्रदर्शन मुद्दे वास्तव में फिर से प्रकट हो सकते हैं यदि/जब sdist के माध्यम से निर्माण किया जाता है, लेकिन वे शायद पाइप <20.1 में हमारे पास की तुलना में कम परिमाण का एक क्रम होगा। वास्तव में इसमें से अधिकांश अक्सर .git , या एक venv , या अन्य असंबंधित स्वैच्छिक सामान की नकल करने से निकले जो sdist में नहीं होंगे।

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

साथ ही, setup.py sdist स्थानीय निर्देशिका में .egg-info setup.py sdist बनाता है, इसलिए केवल-पढ़ने के लिए स्रोत डीआईआर या समवर्ती बिल्ड के साथ रिपोर्ट की गई समस्याएं बनी रहेंगी।

मुझे लगता है (कम से कम एक त्वरित परीक्षण मेरे साथ सहमत है) कि केवल setuptools (नहीं distutils ) ऐसा करता है, और यह व्यवहार कहीं और डीआईआर बनाने के लिए कॉन्फ़िगर करने योग्य है। अन्य बैकएंड के समान, हम उन्हें एक स्वच्छ sdist पीढ़ी करने के लिए अनुशंसा करने में सक्षम होना चाहिए।

एफडब्ल्यूआईडब्ल्यू, मुझे नहीं लगता कि हमें sdist- पीढ़ी --egg-info निर्देशिका को कार्यशील निर्देशिका में डंप करने की आवश्यकता होगी, अगर हम जनरेट-एसडीडिस्ट-अनपैक-इट-बिल्ड-व्हील दृष्टिकोण को नीचे जाते हैं, क्योंकि हम कर सकते हैं उसे एक अस्थायी निर्देशिका में डंप करें, जैसे हम generate_metadata ।

@pradyunsg को sdist कमांड में .egg-info आधार स्थान निर्दिष्ट करने का विकल्प नहीं था, इसके विपरीत egg_info जिसमें --egg-base विकल्प है जिसका हमने लाभ उठाया है # 7978 में।

वास्तव में! मैं setuptools में गलत फाइल देख रहा था। मैं सही खड़ा हूँ।

इस अंतरिक्ष में सब कुछ इतना जटिल क्यों है? :(

$  ls -la
total 8
drwxr-xr-x  3 dstufft  staff   96 May  6 14:26 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

$  py setup.py egg_info --egg-base /tmp/foo sdist
/Users/dstufft/.pyenv/versions/3.8.2/lib/python3.8/site-packages/setuptools/dist.py:471: UserWarning: Normalizing '2020.04.23.3' to '2020.4.23.3'
  warnings.warn(
running egg_info
creating /tmp/foo/dstufft.testpkg.egg-info
writing /tmp/foo/dstufft.testpkg.egg-info/PKG-INFO
writing dependency_links to /tmp/foo/dstufft.testpkg.egg-info/dependency_links.txt
writing top-level names to /tmp/foo/dstufft.testpkg.egg-info/top_level.txt
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
reading manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
running sdist
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
warning: Check: missing required meta-data: url

warning: Check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

creating dstufft.testpkg-2020.4.23.3
copying files to dstufft.testpkg-2020.4.23.3...
copying setup.py -> dstufft.testpkg-2020.4.23.3
Writing dstufft.testpkg-2020.4.23.3/setup.cfg
creating dist
Creating tar archive
removing 'dstufft.testpkg-2020.4.23.3' (and everything under it)

$ ls -la                                        
total 8
drwxr-xr-x  4 dstufft  staff  128 May  6 14:28 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
drwxr-xr-x  3 dstufft  staff   96 May  6 14:28 dist
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

https://github.com/pypa/pip/issues/8165#issuecomment -624669107 यह एक सुंदर शो स्टॉपिंग बग की तरह लगता है, यकीनन हमारी बग नहीं है, लेकिन यह एक प्रकार की बग है जो मैंने तर्क दिया कि पीईपी 517 चर्चा के दौरान होगा जब जगह में करना डिफ़ॉल्ट रूप से बनाता है।

bdist_wheel को अतीत में अपनी बिल्ड निर्देशिका को स्वचालित रूप से साफ़ करने के लिए कहा गया है। उस सुविधा में जाना चाहिए। क्या अन्य डिस्टुटिल्स स्वच्छ बनाता है?

यदि यह स्कैन था तो यह उन फाइलों को याद रखेगा जिनके बारे में यह परवाह करता है और व्हील से बिल्ड/निर्देशिका में अतिरिक्त फाइलों को छोड़ देगा, भले ही वे फाइल सिस्टम में मौजूद हों।

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

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

निश्चित रूप से अंतर्निहित setuptools कमांड के लिए पर्याप्त झंडे के साथ आप इसका समाधान कर सकते हैं ( py setup.py egg_info --egg-base /tmp/foo build --build-base /tmp/foo/build-base bdist_wheel --bdist-dir /tmp/foo/bdist जैसा कुछ ऐसा करेगा)।

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

मैंने enscons का परीक्षण करने का प्रयास किया लेकिन मुझे त्रुटि के बिना rsalette बनाने के लिए बिल्कुल भी नहीं मिला।

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

ठंडा। क्षमा करें दुर्भाग्य से enscons अद्यतन हो गया है और rsalette नहीं है।

बुध, 6 मई, 2020 को शाम 4:18 बजे, डोनाल्ड स्टफ ने लिखा:

मैंने enscons का परीक्षण करने का प्रयास किया लेकिन मुझे त्रुटि के बिना rsalette बनाने के लिए बिल्कुल भी नहीं मिला।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/pypa/pip/issues/7555#issuecomment-624867490 पर https://github.com/notifications/unsubscribe-auth/AABSZERIEDAPUIXCPAKBBUDRQHAXRANCNFSM4KCV5MHQ की सदस्यता समाप्त

क्षमा करें दुर्भाग्य से enscons अद्यतन हो गया है और rsalette नहीं है।

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

rsalette साथ एकमात्र समस्या यह है कि इसे स्कैनस्ट्रक्चर में पर्यावरण को ROOT_IS_PURELIB पास नहीं करना चाहिए। इसमें C एक्सटेंशन नहीं है। cryptacular ठीक लग रहा है।

#8165 (टिप्पणी)

इसके साथ, मुझे लगता है कि मैं इस बात से सहमत हूं कि हमें इस बदलाव को वापस लाना चाहिए।

मुझे लगता है कि नई समस्याएं अपेक्षा से बहुत बड़ी हैं। शायद एक त्वरित 20.1.1 वापस लौटने के लिए और फिर हम इन-ट्री और आउट-ऑफ-ट्री बिल्ड दोनों की समस्याओं को हल करने के बारे में लंबी चर्चा कर सकते हैं?

मैं इसके लिए एक समाधान के रूप में https://discuss.python.org/t/proposal-adding-a-persistent-cache-directory-to-pep-517-hooks/2303/15 को वापस करने और उसका अनुसरण करने के लिए भी वोट करता हूं (जो होगा बैकएंड को जगह में नहीं बनाने दें, इसलिए ऐसे मुद्दों को उजागर न करें)। यदि आप वहां के सुझाव से सहमत हैं तो उस सूत्र पर भी ध्यान दें।

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

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

ठीक है! मुझे लगता है कि आम सहमति वापस लौटने और पुनर्मूल्यांकन करने के लिए है। मैं इसके लिए पीआर फाइल करूंगा। :)

यदि आप वहां के सुझाव से सहमत हैं तो उस सूत्र पर भी ध्यान दें।

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

https://github.com/pypa/pip/issues/8165#issuecomment -625401463 में बस कुछ बड़े-बूँद-पाठ को छोड़ दिया। मैं आज के लिए दूर जा रहा हूँ... अंत में व्यक्तिगत नोट्स लिखते समय मुझे थोड़ी निराशा हुई। # 5599 को समाप्त होने और नकारात्मक उपयोगकर्ता टिप्पणियों को पढ़ने से निश्चित रूप से मदद नहीं मिली।

हाय दोस्तों, मैंने इस पर कुछ और विचार किया, इस मामले पर मेरा वर्तमान दृष्टिकोण है।

1. एक sdist जगह पर बनाएँ, sdist को एक अस्थायी स्थान पर अनपैक करें, फिर उससे निर्माण करें।

मेरा अब भी मानना ​​है कि खराब एसडीस्ट को पकड़ने और पकड़ने के लिए पाइप इंस्टाल/पाइप व्हील सही जगह नहीं है। क्या यह एक बैक-एंड जिम्मेदारी नहीं होनी चाहिए कि पहली जगह में खराब sdists न बनाएं? इसके अलावा मुझे लगता है कि sdist के माध्यम से बिना शर्त निर्माण शायद जगह में निर्माण के रूप में विघटनकारी है।

1. जगह बनाने के लिए एक पिप विकल्प जोड़ें।

मुझे सबसे अच्छा शॉर्ट टर्म पसंद है, क्योंकि समाधान 4 ने इसे नहीं बनाया। क्या इसे पिप 20.1.1 में जोड़ना समय से पहले है?

1. PEP 517 को किसी प्रकार के तंत्र के साथ अपडेट करें ताकि बैक-एंड फ्रंट-एंड से संचार कर सकें यदि वे इन-प्लेस बिल्ड के लिए "सुरक्षित" हैं।

इस पाइप के साथ अभी भी अपने टूटे और अपरिवर्तनीय कॉपीट्री पर वापस गिरने की आवश्यकता होगी, इसलिए मैं इसके पक्ष में नहीं हूं।

1. हमेशा जगह में निर्माण करने के लिए पाइप बदलें।

इसलिए इसे बहुत अधिक विघटनकारी माना जाता है और हम 20.1.1 में वापस आ जाएंगे।

1. आउट-ऑफ़-ट्री बनाने के विकल्प के साथ डिफ़ॉल्ट रूप से निर्माण के लिए पाइप बदलें।

यह दीर्घकालिक लक्ष्य हो सकता है, कैश निर्देशिका अवधारणा के साथ आउट-ऑफ-ट्री सम्मिश्रण बनाने का विकल्प?

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

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

sdist के माध्यम से निर्माण करना वास्तव में खराब sdists को पकड़ने के बारे में नहीं है। बड़े हिस्से में यह "पथ" की संभावित विविधताओं को कम करने के बारे में है जो एक परियोजना स्थापित होने से पहले समाप्त हो सकती है। कुछ तरीकों से झंडा जोड़ना उस समस्या को बेहतर नहीं बल्कि बदतर बना देता है।

मेरा मतलब है कि हमारे पास कुछ "पथ" हैं जो इंस्टॉल हो सकते हैं:

1. वीसीएस -> एसडिस्ट -> व्हील -> स्थापित
2. वीसीएस -> व्हील -> स्थापित
3. वीसीएस -> स्थापित (विरासत)

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

हम या तो एक sdist या एक पहिया पर विचार कर सकते हैं जिसे PyPI पर अपलोड किया जा रहा है और उस से उसी "पथ" का हिस्सा बनने तक स्थापित किया जा रहा है, आप बस इसे रोक रहे हैं और इसे किसी अन्य कंप्यूटर पर समाप्त कर रहे हैं।

इस तरह के कई "पथ" होने में समस्या यह है कि यह अंतिम परिणामी स्थापना में विसंगतियों का परिचय देता है। वे हमेशा नहीं होते हैं, लेकिन यह आसानी से देखा जा सकता है कि यह अक्सर होता है। कई बार ये विसंगतियां कोई बड़ी बात नहीं होती हैं, लेकिन कभी-कभी होती हैं।

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

एक अतिरिक्त लाभ के रूप में, यह यह सुनिश्चित करने में मदद करने के लिए एक जबरदस्त कार्य के रूप में भी कार्य कर सकता है कि खुश पथ खुश रहे।

अधिकतर मैं @dstufft से सहमत

हालाँकि, मैं एक बिंदु पर उठाना चाहता हूँ:

क्या होगा यदि मैं अपने स्थानीय एफएस पर दो पैकेज सूचीबद्ध करता हूं और मुझे एक जगह बनाने की जरूरत है और एक नहीं?

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

ध्यान दें कि जब (यदि) हम वापस लौटते हैं, तो हमें #6276 जैसे मुद्दों को फिर से खोलना होगा जो इन-ट्री बिल्ड को लागू करने के परिणामस्वरूप बंद हो गया था।

समस्या का एक हिस्सा यह है कि पीआईपी इस बात पर विचार नहीं करता है कि निर्भरता को हल करते समय पहले से ही क्या स्थापित है (मुझे यकीन नहीं है कि नया रिज़ॉल्वर काम करता है या नहीं?) निर्भरता "सही ढंग से" (हद तक हमारे वर्तमान समाधानकर्ता कुछ भी सही ढंग से करता है)।

यदि नया रिज़ॉल्वर लेता है जो पहले से ही खाते में स्थापित है तो pip install foo bar और pip install foo && pip install bar मोटे तौर पर बराबर होंगे और इससे कोई फर्क नहीं पड़ता, लेकिन अगर ऐसा नहीं होता है (और वही अब लगभग सच है) यदि दोनों प्रोजेक्ट "स्पैम" पर निर्भर हैं, लेकिन फू की आवश्यकता है <2 और बार आवश्यक> 1 तो हमें एक अमान्य इंस्टॉल मिलेगा।

हालांकि यह एक स्पर्शरेखा है :)

(मुझे यकीन नहीं है कि क्या नया रिज़ॉल्वर काम बदलता है?)

#7744 पर इनपुट्स का स्वागत है। :)

1. हमेशा जगह में निर्माण करने के लिए पाइप बदलें।

इसलिए इसे बहुत अधिक विघटनकारी माना जाता है और हम 20.1.1 में वापस आ जाएंगे।

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

1. जगह बनाने के लिए एक पिप विकल्प जोड़ें।

@dstufft @pfmoore मैं उस तरह के विकल्प को एक ऑप्ट-इन तंत्र के रूप में https://github.com/pypa/pip/issues/8165#issuecomment -625501216

मैं इसके लिए पीआर फाइल करूंगा। :)

8221 है।

20.1.1 जारी किया गया है, जिसमें पूर्ववत परिवर्तन शामिल हैं।

फेडोरा में, जब हम पायथन आरपीएम पैकेज बनाते हैं, तो हम डायनासोर होते हैं और थिन करने का मानक तरीका python setup.py build । पीईपी 517 के साथ हमने इसके बजाय pip wheel का उपयोग करने का "अनंतिम" तरीका जोड़ा। हालांकि एक्सटेंशन मॉड्यूल के साथ हमें "स्रोतों को tmp पर ले जाएं, वहां से बनाएं" दृष्टिकोण के साथ समस्या है जो पाइप उन्हें बनाने के लिए उपयोग करता है।

हमारी बिल्ड मशीनरी कुछ कंपाइलर फ़्लैग्स को इंजेक्ट कर रही है ताकि बिल्ड आर्टिफ़ैक्ट्स (इस मामले में .so एक्सटेंशन मॉड्यूल) में उनके स्रोतों के बारे में मेटाडेटा हो। बाद में एक शेल स्क्रिप्ट होती है जो बिल्ड कलाकृतियों का पता लगाती है, इस जानकारी को निकालती है और एक विशेष *-debugsource RPM के माध्यम से स्थापित करने के लिए स्रोतों को /usr/src/debug कॉपी करती है। महसिनरी को उम्मीद है कि सब कुछ काम करने वाले पेड़ के भीतर बनाया जाएगा और बाहर बनाए जाने पर यह वास्तव में अच्छा काम नहीं करता है। यहां वे चीजें हैं जो हमारी तरफ से समस्या को कम करने के लिए (एक साथ) की जा सकती हैं:

1. set the `$TMPDIR` environment variable to have it within the place where the RPM script expects it (i.e. `export TMPDIR=%{_builddir}/.tmp` (and create it))

2. use `pip wheel` with the `--no-clean` option to keep the copied sources in `$TMPDIR`

3. run some shell kung fu to rewrite the "what is my source" information to the correct location: `find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"`

4. (Optional: clean `$TMPDIR` manually.)

यह प्रभावी रूप से वह रास्ता है जिसे मैंने पाइप एकीकरण, #6505, आदि को देखते हुए शुरू किया था।

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

pip को build कमांड की आवश्यकता है और build कमांड का अंतिम परिणाम अन्य उप-आदेशों के साथ-साथ चलने योग्य होना चाहिए, जैसे wheel , install , आदि।

अभी pip प्रभावी ढंग से install को build और install pip रूप में व्यवहार करता है, जो कि _not_ है जो कुछ लोग चाहते हैं जो बाइनरी कलाकृतियों का निर्माण और कैशिंग कर रहे हैं, पढ़ने पर बाइनरी स्थापित कर रहे हैं -केवल माउंट, आदि।

मैं वास्तव में चाहता हूं कि बाइनरी बनाने के लिए setup.py का उपयोग करने का एक तरीका था, फिर pip install उन्हें bdist बनाने का सहारा लिए बिना, लेकिन यह आज संभव नहीं लगता है , चूंकि pip और distutils / setuptools इस बात पर सहमत नहीं हैं कि बाइनरी कलाकृतियों को कहां खोजा जाए।

मैं वास्तव में चाहता हूं कि बायनेरिज़ बनाने के लिए setup.py का उपयोग करने का एक तरीका था, फिर pip उन्हें bdist बनाने का सहारा लिए बिना स्थापित करें, लेकिन यह आज संभव नहीं लगता है, क्योंकि pip और distutils/setuptools इस पर सहमत नहीं हैं बाइनरी कलाकृतियों को कहां खोजें।

मुझे यकीन नहीं है कि मैं अनुसरण करता हूं - आप कह रहे हैं कि आप बाइनरी का उपयोग करने का एक तरीका चाहते हैं लेकिन पहले से मौजूद बाइनरी वितरण प्रारूपों का उपयोग नहीं करना चाहते हैं। ऐसा क्यों है?

मैं वास्तव में चाहता हूं कि बायनेरिज़ बनाने के लिए setup.py का उपयोग करने का एक तरीका था, फिर pip उन्हें bdist बनाने का सहारा लिए बिना स्थापित करें, लेकिन यह आज संभव नहीं लगता है, क्योंकि pip और distutils/setuptools इस पर सहमत नहीं हैं बाइनरी कलाकृतियों को कहां खोजें।

मुझे यकीन नहीं है कि मैं अनुसरण करता हूं - आप कह रहे हैं कि आप बाइनरी का उपयोग करने का एक तरीका चाहते हैं लेकिन पहले से मौजूद बाइनरी वितरण प्रारूपों का उपयोग नहीं करना चाहते हैं। ऐसा क्यों है?

bdist प्रारूप अत्यंत सीमित हैं। मेरे समूह को टैर की तरह एक गूंगा प्रारूप का सहारा लेना है, फिर इसे शब्दशः अनपैक करें (बीएसडी में से कोई भी समर्थित नहीं है, डेबियन समर्थित नहीं है, आदि)।

मैंने कल रात जो खोजा वह यह है कि एक गूंगा bdist का उपयोग करना pip माध्यम से इंस्टॉल करने योग्य नहीं है। डंब बायनेरिज़ में pip , AFAICT के माध्यम से स्थापित करने के लिए आवश्यक मेटाडेटा की कमी होती है, जहां मुझे लगता है कि पाइप व्हील चलन में आते हैं।

मैंने अंडे और ज़िप की भी कोशिश की, लेकिन उनके पास केवल file:// यूआरआई का उपयोग करके स्थापित करने के लिए आवश्यक मेटाडेटा की कमी है।

मैं distutils, setuptools के माध्यम से निर्माण का उपयोग करके एक बड़े निर्माण प्रणाली में शूहॉर्न बिल्डिंग की कोशिश कर रहा हूं, इसलिए मैं यह नहीं बता सकता कि मैंने चीजों को मानक bdist के तरीके से काम करने के लिए "सभी सही चीजें" की हैं या नहीं

https://github.com/pypa/pip/issues/2195#issuecomment -664728481 से आ रहा हूं, मैं कह सकता हूं कि मैं --use-feature=in-tree-build पीछे #7882 फिर से करने के लिए खुश हूं।

हुर्रे! एक योजना की तरह लगता है!

आइए इस बार --build के डॉकस्ट्रिंग को भी अपडेट करें। ;)

#2195 से आ रहा है (टिप्पणी) मैं कह सकता हूं कि मैं #7882 को --use-feature=in-tree-build के पीछे फिर से करने के लिए खुश हूं।

जिज्ञासु अगर यह और साथ ही कमांड-लाइन द्वारा in-tree-build विकल्प को pyproject.toml में सेट करना उचित होगा? पाइप को लपेटने के लिए बैश स्क्रिप्ट या मेकफ़ाइल बनाने की आवश्यकता के बिना # 6276 को हल करने के लिए यह बहुत अच्छा होगा। (ऐसा नहीं है कि यह एक विशेष रूप से बड़ा मुद्दा है।)

pyproject.toml में एक इन-ट्री-बिल्ड विकल्प सेट करें

@davidhewitt इस मुद्दे के मूल विवरण में यह कमोबेश विकल्प 3 है। मेरी समझ यह है कि वर्तमान सर्वसम्मति यह है कि यदि हम कर सकते हैं तो अतिरिक्त विकल्प से बचना बेहतर है। इसलिए संक्रमण अवधि के दौरान --use-feature के साथ इन-ट्री बिल्ड को सक्षम करने का विचार, इसे डिफ़ॉल्ट और एकमात्र तंत्र बनाने के दीर्घकालिक लक्ष्य के साथ।

BTW, मैं इसे 20.3 के लिए समय पर लागू नहीं कर पाऊंगा, लेकिन मैं अभी भी इसे करने का इरादा रखता हूं, उम्मीद है कि 20.4 में।

@sbidoul मैंने इस सुविधा को प्राप्त करने में सहायता के लिए एक पैच लिखा - # 9091 देखें।