4799 वह जगह है जहां बहुत बहस हो रही है। यह ज्यादातर द्वारा प्रेरित किया गया था:

1. मैं समझ गया था कि पीईपी 518 समर्थन के लिए एकमात्र बकाया अवरोधक #4764 था (https://github.com/pypa/pip/pull/4144#issuecomment-302711736 के माध्यम से)
2. फिर #4799 आया, और मैंने इसे देखने के लिए देखा कि क्या मैं @xoviat द्वारा किए जा रहे सभी प्रगति कार्यों के बारे में कुछ समझ सकता हूं।
3. उस दौरान, #4647 एक रिलीज अवरोधक के रूप में यह कहते हुए सामने आया कि पीईपी 518 समर्थन टूट गया था।

जैसा कि मैंने यह पता लगाने की कोशिश की कि @xoviat #4799 में क्या कह रहा था, यह स्पष्ट हो गया कि हमारे पास बिल्ड वातावरण के पुनरावर्ती भवन के आसपास कुछ मुद्दे थे (X को बनाने के लिए Y की आवश्यकता है, और Y को Z की आवश्यकता है, ...) हालांकि I' मैं अभी भी स्पष्ट नहीं हूं कि क्या ये कार्यान्वयन बग, गहरी डिजाइन समस्याएं, या खराब कोने के मामले हैं जिन्हें हम बहुत अधिक समस्या के बिना स्थगित कर सकते हैं।

निजी तौर पर, मैं उस बिंदु पर हूं जहां मैं अपनी गहराई से बाहर हूं। मुझे समझ नहीं आ रहा है कि @xviat के क्रियान्वयन की आवश्यकता है या नहीं, या यदि हमें अभी भी #4764 को मर्ज करने और जाने के लिए तैयार होने के लिए #4647 को ठीक करने की आवश्यकता है। न ही मुझे पता है कि #4647 को ठीक करना कितना आसान होगा ( @xoviat यह कह रहा है कि #4647 को ठीक करने के लिए हमें #4799 को मर्ज करने की आवश्यकता है, लेकिन यह अपनी समस्याएं लाता है)।

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

एक बहुत ही उपयोगी सारांश @pfmoore के लिए धन्यवाद।

@ncoghlan @dstufft @xoviat क्या हम कृपया यहां चर्चा ला सकते हैं? इसे बंद पीआर पर करना मुझे अजीब लगता है। ._.

ज़रूर।

@pradyunsg मुझे पता है कि आपके पास इसके लिए समय नहीं है। लेकिन आप मेरी तुलना में पीआर को स्वीकृत करने में अधिक सफल रहे हैं, इसलिए यदि आप चाहते हैं, तो मुझे आपको वर्तमान कार्यान्वयन, यह कैसे काम करता है, और इसकी संभावित समस्याओं के बारे में बताकर बहुत खुशी होगी। मैं समझाऊंगा कि मैंने इन समस्याओं में से कुछ (लेकिन सभी नहीं) को कैसे हल किया और मेरे विचारों को पूरी तरह से ठीक करने के लिए (जो फिर से, मैं पीईपी 517 के बाद कर सकता हूं अगर यह नहीं किया जाता है)। मैं ईमानदारी से परवाह नहीं करता कि कौन काम करता है जब तक यह किया जाता है।

वास्तव में, आप AWOL हैं, इसलिए मुझे एक सारांश लिखने दें:

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

मैं किसी वस्तु के "दायरे" को एक प्रकार के जीवनकाल के रूप में परिभाषित करूँगा। यह वह अवधि है जब कोई वस्तु मौजूद होती है। अभी, pip में PEP 518 का दायरा WheelBuilder है। PEP 518 वातावरण को bdist_wheel के लिए सेट किया गया है, फिर उस वातावरण में bdist_wheel चलाया जाता है, और फिर पर्यावरण को तोड़ दिया जाता है।

तो इसमें दिक्कत क्या है? समस्या यह है कि पीईपी 518 पर्यावरण का दायरा setup.py पर सभी कॉलों के दायरे के बराबर या उससे अधिक होना चाहिए। अधिक विशेष रूप से, इसे एक ऐसी वस्तु को समाहित करने की आवश्यकता है जो setup.py कॉल की अवधि के दौरान मौजूद हो। वह वस्तु है Requirement ।

आपके सामने पहला स्पष्ट निर्णय यह होगा: BuildEnvironment का संदर्भ क्या होना चाहिए, और Requirement किसी भी तरह एक अच्छी जगह है। वास्तव में, यह संदर्भ देने के लिए IMHO की सबसे अच्छी जगह है क्योंकि setup.py को कॉल किया जाता है यदि और केवल Requirement मौजूद है।

आपके सामने आने वाली अगली समस्या यह है: हम BuildEnvironment आवश्यकताओं को कैसे स्थापित करते हैं? हम केवल pip तक खोल सकते हैं। और यही वह निर्णय है जो मूल कार्यान्वयनकर्ता द्वारा किया गया था। लेकिन इसमें एक समस्या है: pip के पास यह जानने का कोई तरीका नहीं है कि यह कितने शेल कॉल कर रहा है क्योंकि प्रत्येक pip खुद को फिर से कॉल कर सकता है। वास्तव में, यदि pip बहुत अधिक प्रक्रियाओं को जन्म देता है, तो परिपत्र निर्भरता के साथ दुर्भावनापूर्ण रूप से निर्मित पैकेज किसी के कंप्यूटर को क्रैश कर सकता है।

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

किसी प्रकार के प्रबंधक वर्ग के बिना अपने आप को एक बच्चे को बाहर निकालना जो बच्चों को मार सकता है जब उपयोगकर्ता ctrl + C दबाता है, यह गलत नहीं है, यह दुर्भावनापूर्ण है, खासकर जब आप नहीं जानते कि आपने कितनी प्रक्रियाएं पैदा की हैं। मैं व्यक्तिगत रूप से नहीं जानता कि बच्चे वर्तमान कार्यान्वयन में मर जाते हैं (यह एफयूडी हो सकता है), लेकिन यदि वे नहीं करते हैं, तो वर्तमान कार्यान्वयन आईएमएचओ गलत है (अन्य चिंताओं से अलग)।

उस समस्या के कुछ संभावित समाधान निम्नलिखित हैं:

1. यदि आप पीईपी 518 को दरवाजे से बाहर निकालना चाहते हैं, तो आपकी सबसे अच्छी शर्त शायद किसी प्रकार की लॉकफाइल है जो केवल 10 ताले तक की अनुमति देती है या यह सुनिश्चित करने के लिए कि पाइप अनंत रूप से गुणा नहीं कर रहा है। फिर आप कमांड लाइन तर्कों के साथ बच्चे को सटीक आवश्यकताओं को पास कर सकते हैं।

2. एक उचित समाधान, जिसे मैं पीईपी 517 के बाद लागू करना चाहता हूं, एक BuildEnvironmentManager वर्ग होना चाहिए जो सीधे install कमांड में प्रारंभ किया गया हो। BuildEnvironmentManager में सभी वस्तुओं का संदर्भ होगा ( RequirementPreparer , WheelBuilder , आदि), और एक ही विधि होगी: get_build_environment(requirement_set) । फिर आप RequirementPreparer पर एक विधि लागू कर सकते हैं जो कि set_build_environment_manager जैसा कुछ है, जिसका उपयोग वह बिल्ड वातावरण प्राप्त करने के लिए कर सकता है। BuildEnvironmentManager एक ही वातावरण के कई उपयोगों का भी पता लगा सकता है (आमतौर पर ['setuptools', 'wheel'] ) और एक ही वातावरण प्रदान करता है यदि इसकी कई बार आवश्यकता होती है ताकि आपको इसे बनाने की आवश्यकता न हो (शुरू में बहुत सामान्य परियोजनाओं के साथ pyproject.toml नहीं)। आदर्श रूप से सर्कुलर संदर्भों (तुच्छ नहीं) को हटाने का प्रयास करने के लिए कुछ ओओपी डिज़ाइन भी होंगे।

@xoviat हालांकि यह जानबूझकर द्वेष के मामले को कवर नहीं कर सकता है, क्या मैं यह सोचने में सही हूं कि एक बिल्ड कैश (जिसका उपयोग तब भी किया गया था जब --no-binary :all: निर्दिष्ट किया गया था) न केवल पूर्ण किए गए बिल्ड को ट्रैक करने की क्षमता के साथ, बल्कि इसमें भी -प्रगति वाले, यह सुनिश्चित करने के लिए पर्याप्त होंगे कि निर्माण निर्भरता चक्र समाप्त हो गया है? यह आपके पहले सुझाव का एक प्रकार होगा (समवर्ती पाइप आमंत्रणों की संख्या पर एक क्रॉस-प्रोसेस सीमा), लेकिन इस प्रकार सुधार किया गया:

1. मशीन पर केवल एक प्रक्रिया को एक ही समय में एक ही पैकेज बनाने की अनुमति है
2. एक शीर्ष स्तर "बिल्ड आईडी" है जो पाइप किसी भी उप-बिल्ड के पास जाता है जो इसे पैदा करता है (उदाहरण के लिए शीर्ष स्तर की प्रक्रिया का पीआईडी ​​​​बनाए जा रहे पैकेज के नाम के साथ संयुक्त)
3. यदि बिल्ड कैश इंगित करता है कि किसी भिन्न बिल्ड आईडी द्वारा कुछ बनाया जा रहा है, तो उस बिल्ड के समाप्त होने की प्रतीक्षा करें
4. यदि बिल्ड कैश इंगित करता है कि एक ही बिल्ड आईडी के लिए पहले से ही कुछ बनाया जा रहा है, तो सर्कुलर निर्भरता की रिपोर्ट करने में त्रुटि के साथ जमानत दें, और यह दर्शाता है कि बिल्ड को काम करने के लिए --binary <name> की आवश्यकता होगी

pip को भी setuptools और wheel को setuptools और wheel की आवश्यकता के डिफ़ॉल्ट तर्क से छूट देने के @pfmoore के सुझाव को लागू करने की आवश्यकता होगी। wheel बिल्ड निर्भरता के रूप में, अन्यथा अंतर्निहित बिल्ड निर्भरता इंजेक्शन स्वाभाविक रूप से परिपत्र निर्भरता पहचान तर्क को ट्रिगर करेगा।

OOP डिज़ाइन समस्याओं का पता लगाने से बचने के लिए डिस्क का उपयोग करना एक बुरा विचार नहीं है। यह पीईपी 518 को पूरी तरह से सही ढंग से लागू करने और बस एक साथ कुछ हैक करने के बीच एक मध्यवर्ती विकल्प की तरह है।

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

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

मैंने वास्तव में पहले #4144 का कोड नहीं देखा था। मैंने अभी किया और मैं वास्तव में नहीं चाहता कि वह शिपिंग हो।

PEP 518 को पूरी तरह से सही तरीके से लागू करना और बस एक साथ कुछ हैक करना।

ईमानदारी से, मुझे लगता है कि यह नीचे आता है। पीईपी 518 को पूरी तरह से और ठीक से लागू करना एक ऐसा कार्य है जो अगर हम इस तरह से जाते हैं तो पीआईपी 10 ए (निष्पक्ष) बिट में देरी हो सकती है।

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

यह कैसा लगता है?

यह प्रतिबंधित है लेकिन मुझे लगता है कि एक प्रतिबंधित पहला कार्यान्वयन आप-कर सकते हैं-खुद-में-द-पैर-अगर-आप-सावधान पहले कार्यान्वयन से बेहतर है।

पीईपी 518 को पूरी तरह से और ठीक से लागू करना एक ऐसा कार्य है जो अगर हम इस तरह से जाते हैं तो पीआईपी 10 ए (निष्पक्ष) बिट में देरी हो सकती है।

इसकी पुष्टि करने के लिए धन्यवाद - यही मेरा डर था।

हालांकि, अब मैं उलझन में हूं , क्योंकि मैंने सोचा था कि कम से कम आंशिक पीईपी 518 पहले से ही मास्टर में था। विशेष रूप से, जैसा कि मैं इसे समझता हूं #4647 मास्टर में पीईपी 518 समर्थन में एक बग प्रदर्शित करता है - तो स्पष्ट रूप से हमारे पास पहले से ही कुछ है , क्योंकि जो कुछ भी है वह सही नहीं है ...

तो हमें कुछ करना है, और ऐसा लगता है कि विकल्प हैं:

1. इस समय हमारे पास PEP 518 समर्थन के लिए जो कुछ भी है, उसे निकाल दें।
2. हमारे पास जो कुछ है उसे व्यवस्थित करें और आंशिक समर्थन भेजें।
3. पीईपी 518 को पूरी तरह से लागू करें इससे पहले कि हम पिप 10 जारी करें।

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

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

इसलिए मुझे लगता है कि मुझे लगता है कि हम जो कुछ भी करते हैं, उसमें फंस गए हैं, लेकिन आंशिक समर्थन केवल पहियों को कवर करता है क्योंकि बिल्ड निर्भरता एक खराब लॉट से सबसे अच्छा विकल्प है :-(

मेरे प्रश्न के उत्तर में पीईपी लेखक (https://github.com/pypa/pip/pull/4799#issuecomment-338331267 और https://github.com/pypa/pip/pull/4799#issuecomment-338332575 में) https://github.com/pypa/pip/pull/4799#issuecomment-338325354) काफी निश्चित थे कि पूर्ण पीईपी समर्थन के लिए किसी भी निर्माण निर्भरता के निर्माण की आवश्यकता है, हालांकि, इसे केवल एक स्टॉपगैप होना चाहिए।

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

(और इस मुद्दे के लिए ऑफ-टॉपिक, लेकिन क्या मैं सुझाव दे सकता हूं कि जब हम पीईपी 517 को लागू करना शुरू करते हैं तो हम वही गलतियां नहीं करने के लिए सावधान हैं? आइए सुनिश्चित करें कि हम कोडिंग में बहुत गहराई से पहले सभी कार्यान्वयन प्रभावों को समझते हैं - मेरी प्रवृत्ति यह है कि पीईपी 517 पीईपी 518 से भी अधिक जटिल डिजाइन समस्या होने जा रही है ...)

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

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

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

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

मुझे लगता है कि यहां एक सुरक्षित-आश मध्य मैदान को पहियों के रूप में उपलब्ध होने के लिए बिल्ड-निर्भरता की आवश्यकता होगी।

वास्तव में यही #4799 करता है। यदि आप चाहें तो मैं उस शाखा को पुनर्स्थापित कर सकता हूं और फिर आप इसे फोर्क कर सकते हैं और इसे पीआर के रूप में जमा कर सकते हैं।

(2) की चीजों के कार्यान्वयन पक्ष पर दो चीजें अभी भी खड़ी हैं - जैसा कि @xoviat ने ऊपर बताया था:

1. यह पता लगाना कि सबप्रोसेस कैसे बनाया जाता है (तर्क एट अल)
   मुझे लगता है कि करने योग्य होना चाहिए।

2. कौन सा पैकेज संस्करण स्थापित किया जाना है।
   यह शायद उसी मूल प्रक्रिया में किया जाना चाहिए, हालांकि मुझे यकीन नहीं है कि यह वास्तव में कैसे होगा, इस तथ्य को देखते हुए कि वर्तमान रिज़ॉल्वर कोड अभी भी pip._internal.operations.prepare में कोड के साथ जुड़ा हुआ है। मैं इस सप्ताह इस पर गौर करूंगा।

मुझे यकीन नहीं है कि किसके पास ऐसा करने का समय होगा।

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

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

आपने (1) का उल्लेख नहीं किया है, और मुझे यकीन नहीं है कि ऐसा इसलिए है क्योंकि आपने सोचा था कि हमारे पास कोई पीईपी 518 समर्थन नहीं था, या आपने मान लिया था कि इसका समर्थन करना कोई विकल्प नहीं था।

मैंने मान लिया कि पीछे हटना कोई विकल्प नहीं है।

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

@dstufft @xavfernandez विचार?

@ncoghlan का बिल्ड-कैश का विचार मेरे लिए एक अच्छा विचार लगता है, हालांकि मुझे यकीन नहीं है कि मैं इसके सभी प्रभावों को समझता हूं।

यदि आप चाहें तो मैं उस शाखा को पुनर्स्थापित कर सकता हूं और फिर आप इसे फोर्क कर सकते हैं और इसे पीआर के रूप में जमा कर सकते हैं।

मेरे पास शायद समय नहीं होगा और अगर मैं करता हूं तो भी मैं किसी मौजूदा काम का पुन: उपयोग नहीं कर रहा हूं। लेकिन उस शाखा को बहाल करने से चोट नहीं लग सकती। :)

मेरा मुख्य आरक्षण यह है कि मुझे नहीं पता कि यह प्रतिबंध उन लोगों के लिए कितना समस्याग्रस्त होगा जो पीईपी 518 का उपयोग करना चाहते हैं।

हमने यह सटीक चर्चा की है सिवाय इसके कि आप शायद इसे जानते भी नहीं थे। यह स्थिति स्थिति X है। निर्माण वातावरण स्थापित होने से पहले अंडे_इन्फो को कॉल करना स्थिति वाई (#4799) है।

लेकिन यह मैं नहीं हूं जो इसे लागू कर रहा है, इसलिए जो कोई भी करता है उसके फैसले के साथ जाने में मुझे खुशी है।

मुझे लगता है कि इसका मतलब है कि #4799 टेबल पर वापस आ गया है? जब तक यह सभी परीक्षणों को पास करता है और वह करता है जो वह करने का दावा करता है?

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

@xviat मेरे कुछ प्रश्न हैं। यह बहुत अच्छा होगा यदि आप एक नया पीआर बनाने से पहले उनका जवाब देंगे। :)

• आप यह कैसे निर्धारित करने जा रहे हैं कि कौन से पैकेज स्थापित हो गए हैं?
• क्या आप बाइनरी-ओनली बिल्ड डिपेंडेंसीज़ तक सीमित रहेंगे?

मैंने बहुत सी वैज्ञानिक परियोजनाओं के साथ काम किया है, इसलिए हो सकता है कि मैं पक्षपाती हूं। लेकिन मैं पहिया निर्माण निर्भरताओं के साथ परियोजनाओं की एक सूची को खराब कर सकता हूं और मैं वास्तव में स्रोत निर्भरताओं के साथ एक परियोजना के बारे में नहीं सोच सकता। शायद मैं गलत हूँ।

@rgommers क्या आप PEP 518 के साथ ठीक रहेंगे, यदि यह अगले पाइप में होता तो केवल पहियों के रूप में उपलब्ध बिल्ड निर्भरता का समर्थन करता?

आप यह कैसे निर्धारित करने जा रहे हैं कि कौन से पैकेज स्थापित हो गए हैं?

सबप्रोसेस को आवश्यकताओं की सूची बिल्कुल निर्दिष्ट के रूप में मिलती है। इस तरह यह रिज़ॉल्वर से होकर जाता है।

क्या आप बाइनरी-ओनली बिल्ड डिपेंडेंसीज़ तक सीमित रहेंगे?

हाँ, यही कारण है कि परीक्षण xfailed था। परीक्षण में निर्माण निर्भरता एक पहिया नहीं है।

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

हम क्या महसूस करते हैं कि क्या हम किसी के पास पीईपी 517 और 518 पीआईपी 11 के लिए करने का समय है? मैं आशावादी नहीं हूं। मुझे ऐसा लगता है कि वे दोनों काम के बड़े हिस्से हैं, और हमारे पास रिज़ॉल्वर का काम भी चल रहा है। हालांकि मैं आवश्यकता से अधिक समय तक पीआईपी 10 को बनाए रखने के पक्ष में नहीं हूं, लेकिन जब हम अनिवार्य रूप से मामूली रिलीज की एक श्रृंखला जारी करते हैं, तो हम अपनी सभी प्रमुख फीचर योजनाओं को बहाव देने में समान रूप से असहज होते हैं।

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

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

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

मैंने बहुत सी वैज्ञानिक परियोजनाओं के साथ काम किया है, इसलिए हो सकता है कि मैं पक्षपाती हूँ

धन्यवाद, कभी-कभी लोगों की पृष्ठभूमियों को जानना कठिन होता है। यदि आप वैज्ञानिक परियोजनाओं से परिचित हैं, तो इससे मेरी चिंताएँ बहुत कम हो जाती हैं।

हम जो कर सकते थे, वह "पाइप 9.1" जारी कर सकता है, जो हमारे पास तैयार किए गए वृद्धिशील सुधारों के साथ है, और 3 बड़ी टिकट सुविधाओं के कार्यान्वयन के लिए संस्करण संख्या "पाइप 10" आरक्षित करें जो पाइपलाइन में हैं।

मुझे वास्तव में पसंद है। पिप 10.0.0 के बजाय पिप 9.1.0 के लिए +1

मैं 2018 की पहली तिमाही में एक पीआईपी 10 रिलीज के लिए प्रतिबद्ध [1] की कोशिश करना चाहता हूं। मैं एक दृष्टिकोण के रूप में इसके साथ ठीक रहूंगा।

मेरे पास एक बहुत ही दिलचस्प दिमागी लहर थी - 12 अक्टूबर 2018 को पिप 10 साल का हो गया। यह एक पीआईपी 10.0.0 रिलीज करने के लिए एकदम सही तारीख होगी। यह पूरी तरह से अलग समयरेखा है। मैं यह नहीं कह रहा हूं कि हमें तब तक व्हाइट-व्हेल सुविधाओं में देरी करनी चाहिए, लेकिन मेरा कुछ हिस्सा वास्तव में चाहता है कि यह संस्करण संख्या और उम्र की बात भी मेल खाए।

मुझे संदेह है कि पीईपी 518 फिर से गति खो देता है।

मैं यह सुनिश्चित करने के लिए जो कर सकता हूं वह करूंगा। उम्मीद है कि @xoviat भी इसके लिए तैयार है। :)

क्या किसी को इस बात का अहसास है कि हमारे पास वर्तमान में मास्टर में आंशिक समर्थन का समर्थन करने में क्या शामिल होगा?

मुझे कल इस पर एक नज़र डालने में कोई आपत्ति नहीं होगी। चूंकि @dstufft की #4144 पर समीक्षा की गई थी, मुझे लगता है कि इस पर उनका इनपुट मूल्यवान होगा।

नोट - मैं @dstufft और @xavfernandez से सहमति के बिना चीजों का समर्थन करने के रूप में कठोर कुछ भी नहीं करना चाहता - तो आइए देखें कि उन्हें भी क्या कहना है।

@dstufft के पास दिन में पर्याप्त समय नहीं है। उसे यह भी सुनिश्चित करना होगा कि गोदाम नीचे न जाए।

आइए देखें कि उनका क्या कहना है।

हाँ कृपया। :)

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

इसलिए मुझे लगता है कि पीपी 10 के लिए यह कहना पूरी तरह से उचित है कि --no-binary :all: केवल रनटाइम निर्भरताओं पर लागू होता है, निर्भरता बनाने के लिए नहीं । यदि लोग स्पष्ट रूप से स्रोत से अपने बिल्डरूट का निर्माण करना चाहते हैं, तो वे अभी भी कर सकते हैं - यह सिर्फ इतना है कि पाइप 10 आपके निर्माण निर्भरता के लिए अंतर्निहित स्रोत बनाने की अनुमति देने में शामिल अंतर्निहित पुनरावर्ती बूटस्ट्रैपिंग समस्याओं के कारण उनके लिए इसे स्वचालित रूप से स्वचालित नहीं करेगा।

लोगों को यह इंगित करने की अनुमति देने के लिए कि वे बिल्ड वातावरण को पूरी तरह से पूर्व-कॉन्फ़िगर किए जाने की उम्मीद करते हैं, यह एक अलग --no-implicit-builddeps विकल्प जोड़ने के लिए उचित होगा ताकि एक स्रोत निर्माण के हिस्से के रूप में निहित बाइनरी बूटस्ट्रैपिंग की आवश्यकता होने पर इंस्टॉलेशन पूरी तरह से विफल हो जाए। . इस तरह, लोग यह सुनिश्चित करने की कोशिश कर रहे हैं कि सब कुछ स्रोत से बनाया गया है (निर्माण निर्भरता सहित) इसके बराबर कर सकता है:

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

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

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

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

मैंने एक और विकल्प के बारे में सोचा है, जो उचित लगता है और इसके लिए बहुत अधिक रिफैक्टरिंग की आवश्यकता नहीं होती है: अनिवार्य रूप से मल्टी-थ्रेडिंग का उपयोग करके मुख्य थ्रेड को होल्ड पर रखने के लिए, जबकि बिल्ड वातावरण सेट-अप होता है। विचार इस प्रकार है: install.py में, आपके पास BuildEnvironmentManager होगा:

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

तब आपके पास एक और फाइल होगी, (मैं backend.py का उपयोग करता हूं क्योंकि यह पर्याप्त नहीं है और शायद इसमें और चीजों का उपयोग कर सकता है, और यह पेड़ के निचले सिरे पर है):

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

और संचालन में/prepare.py:

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

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

क्यू के बारे में अपने स्वयं के प्रश्न का उत्तर देना। क्यू आधारित दृष्टिकोण: समवर्ती पर भरोसा करने से बचना सबसे अच्छा है। फ्यूचर्स, इसका उपयोग करने के लिए पायथन 2.7 में https://pypi.org/project/futures/ विक्रेता की आवश्यकता होगी।

pip कोड आधार को अच्छी तरह से जाने बिना, निर्माण पर्यावरण प्रबंधन को एक ही स्थान पर समेकित करने की धारणा अभी भी एक आकर्षक विकल्प की तरह लगती है।

उस दृष्टिकोण के लिए concurrent.futures की आवश्यकता नहीं है। Future सिर्फ एक अधिक वर्णनात्मक आवरण है।

केवल आदिम आवश्यक एक कतार है: https://docs.python.org/2/library/queue.html

मुझे लगता है कि हम इन पंक्तियों को केवल BuildEnvironmentManager में स्थानांतरित कर सकते हैं।

मैंने बहुत सी वैज्ञानिक परियोजनाओं के साथ काम किया है, इसलिए हो सकता है कि मैं पक्षपाती हूं। लेकिन मैं पहिया निर्माण निर्भरताओं के साथ परियोजनाओं की एक सूची को खराब कर सकता हूं और मैं वास्तव में स्रोत निर्भरताओं के साथ एक परियोजना के बारे में नहीं सोच सकता। शायद मैं गलत हूँ।

खैर, एक के लिए हर OS है जो [Windows, macOS, Linux], IIRC नहीं है जो manylinux1 द्वारा कवर नहीं किए गए हैं।

@rgommers क्या आप PEP 518 के साथ ठीक रहेंगे, यदि यह अगले पाइप में होता तो केवल पहियों के रूप में उपलब्ध बिल्ड निर्भरता का समर्थन करता?

मेरी कॉल नहीं, लेकिन मुझे यहां किसी भी कदम को आगे बढ़ाने में खुशी होगी। पीईपी 518 समर्थन वैसे भी वैकल्पिक है, इसलिए यह केवल तभी काम करता है जब पहिए उपलब्ध हों (कवर> 90% मामलों में मैं कहूंगा) अभी भी एक महत्वपूर्ण सुधार है।

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

लेकिन क्या किसी को इस बात का अहसास है कि हमारे पास वर्तमान में मास्टर में आंशिक समर्थन का समर्थन करने में क्या शामिल होगा?

मैंने इस पर गौर किया; यह बहुत कठिन नहीं लगता। अगर हम इस तरह से जाने का फैसला करते हैं तो मुझे इसके लिए पीआर बनाने में खुशी होगी।

पिप 10.0.0 के बजाय पिप 9.1.0 के लिए +1

मुझे अंततः डिस्टुटिल्स-सिग थ्रेड को ठीक से पढ़ने और प्रासंगिक पीआर और चर्चाओं को देखने का समय मिला (#4351, #4144, #4799 और एक गुच्छा अन्य)। अब मुझे लगता है कि हमने पिप 10 की घोषणा की है; हमें यही करना चाहिए, आंशिक PEP 518 समर्थन के साथ -- नहीं 9.1.0।

यह संस्करण संख्या और उम्र की बात मेल खाती है

बमर। :(

@ncoghlan शायद यह टिप्पणी रडार के नीचे फिसल गई - https://github.com/pypa/pip/pull/4799#issuecomment -338416543

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

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

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

इसमें निर्माण निर्भरता लूप शामिल नहीं है,

यह बाइनरी-केवल निर्माण निर्भरताओं के साथ नहीं होगा?

@pradyunsg लिंक की गई टिप्पणी स्रोत निर्भरता के निर्माण की अनुमति देने के तरीके के बारे में थी, जिसका अर्थ है कि परिपत्र निर्भरता एक संभावित चिंता बन जाती है। यदि हमें बाइनरी निर्भरता की आवश्यकता है, तो pip फिलहाल मौजूदा व्हील कैश पर भरोसा कर सकता है।

ठीक है। धन्यवाद! :)

मैं आंशिक पीईपी 518 कार्यान्वयन के साथ एक पीआईपी 10 के पक्ष में हूं जो केवल बाइनरी बिल्ड निर्भरताओं तक सीमित है (या पहले से ही पाइप व्हील कैश में उपलब्ध है) यदि हम इसे शामिल करने का प्रबंधन करते हैं।

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

• कोई भी लिनक्स जो ग्लिबक का उपयोग नहीं करता है (डॉकर के अंदर अल्पाइन लिनक्स एक लोकप्रिय है)।
• कोई भी *nix ऑपरेटिंग सिस्टम जो Linux नहीं है, जैसे FreeBSD आदि।

इसका मतलब यह होगा कि उदाहरण के लिए कोई भी CFFI आधारित परियोजना या तो PEP 518 का उपयोग करने में सक्षम नहीं होगी या उन प्लेटफार्मों पर अनइंस्टॉल करने योग्य होगी।

हो सकता है कि यह पहले ही लाया जा चुका हो! मैं इस धागे को बाद में पढ़ूंगा।

@dstufft यह सही है। लेकिन हम जो प्रस्ताव दे रहे हैं वह यह है कि पिप कैश का उपयोग करना एक विकल्प है। तो आप केवल pip wheel या pip install अपनी बिल्ड निर्भरता पहले कर सकते हैं और फिर उन्हें कैश में संग्रहीत किया जाएगा।

हो सकता है कि यह पहले ही लाया जा चुका हो!

नहीं। :)

इसका मतलब यह होगा कि उदाहरण के लिए कोई भी CFFI आधारित परियोजना या तो PEP 518 का उपयोग करने में सक्षम नहीं होगी या उन प्लेटफार्मों पर अनइंस्टॉल करने योग्य होगी।

वास्तव में। :-(

मेरे दिमाग में इसके चारों ओर यह होगा कि हम पीईपी 518 व्यवहार को ऑप्ट-इन कर सकते हैं - अगर कोई pyproject.toml फ़ाइल है, तो हम अलगाव + बिल्ड वातावरण का उपयोग करते हैं अन्यथा setup.py का उपयोग करने के वर्तमान व्यवहार पर वापस आ जाते हैं

मैं इस धागे को बाद में पढ़ूंगा।

करने की कृपा करे। :)

मेरी डोनाल्ड जैसी ही टिप्पणी थी; इस सूत्र के बारे में मेरी समझ यह है कि बाइनरी-ओनली अस्थायी है क्योंकि इसे पाइप 10 के लिए लागू करने का कोई समय नहीं है। सही?

यदि इसके बजाय इसे स्थायी निर्णय के रूप में प्रस्तावित किया गया था, तो निश्चित रूप से -1।

मेरी डोनाल्ड जैसी ही टिप्पणी थी; इस सूत्र के बारे में मेरी समझ यह है कि बाइनरी-ओनली अस्थायी है क्योंकि इसे पाइप 10 के लिए लागू करने का कोई समय नहीं है। सही?

यह सही है। pip को स्रोत निर्भरता का समर्थन करना चाहिए लेकिन हमारे पास जनशक्ति की कमी है।

मेरे दिमाग में इसका तरीका यह होगा कि हम पीईपी 518 व्यवहार को ऑप्ट-इन कर सकते हैं - अगर कोई pyproject.toml फ़ाइल है, तो हम आइसोलेशन + बिल्ड एनवायरनमेंट का उपयोग करते हैं अन्यथा setup.py का उपयोग करने के वर्तमान व्यवहार पर वापस आ जाते हैं।

मैंने इस टिप्पणी को दोबारा पढ़ा और मैं यहां असहमत होने जा रहा हूं। पीईपी 518 समर्थन वैकल्पिक नहीं होना चाहिए, (पीईपी 517 से संबंधित कार्यान्वयन कारणों के लिए) आईएमएचओ, लेकिन इन प्लेटफार्मों पर परियोजना की स्थापना रद्द नहीं होनी चाहिए।

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

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

मेरे अपने दृष्टिकोण को सारांशित करना:

1. मैं समस्या के कुछ वर्गों (उदाहरण के लिए निर्भरता लूप का निर्माण) को सुविधा के पहले जारी पुनरावृत्ति में असंभव बनाने के लिए पाइप 10 में अस्थायी सीमा के रूप में "बिल्ड निर्भरताओं के लिए कोई अंतर्निहित निर्माण समर्थन नहीं" देखता हूं। प्लग करने योग्य बिल्ड बैकएंड समर्थन के भविष्य के पुनरावृत्तियों, अंतर्निहित स्रोत बिल्ड निर्भरता के लिए निर्माण की अनुमति दे सकते हैं, जबकि आपके द्वारा अनुमति देने के बाद उत्पन्न होने वाली नई समस्याओं से बचने के लिए उपयुक्त उपाय किए जा सकते हैं।
2. एक त्रुटि संदेश में प्रासंगिक python -m pip wheel X Y Z कमांड को वास्तव में अंतर्निहित रूप से बिल्ड को चलाए बिना उत्सर्जित करना अभी के लिए एक पर्याप्त समाधान है, क्योंकि यह सुनिश्चित करता है कि पाइप अनजाने में एक मशीन को बम से उड़ा नहीं सकता है।
3. आइसोलेटेड बिल्ड शायद अभी तक डिफ़ॉल्ट नहीं होना चाहिए, जब तक कि बनाए जा रहे विशिष्ट व्हील में pyproject.toml फ़ाइल न हो, या अलग-अलग बिल्ड को कमांड लाइन से स्पष्ट रूप से अनुरोध किया जाता है। यह एक पिछड़ा संगतता मुद्दा है, क्योंकि मौजूदा परियोजनाएं गैर-पृथक व्यवहार की अपेक्षा कर रही हैं। एक बार रिलीज या दो के लिए अलग-अलग बिल्ड उपलब्ध हो जाने के बाद, और उनके साथ किसी भी उपयोगिता के मुद्दों पर काम किया गया है, तो वे आम तौर पर डिफ़ॉल्ट बन सकते हैं (शायद एक विशेष निर्माण वातावरण निर्दिष्ट करने के लिए कमांड लाइन विकल्प के साथ अंतर्निहित रूप से पृथक उत्पन्न करने के बजाय उपयोग करने के लिए वाले)

@ncoghlan बस आपको एक हेड-अप देने के लिए: कोई डिफ़ॉल्ट बिल्ड अलगाव का मतलब कोई पीईपी 517 नहीं है (कम से कम मेरे दृष्टिकोण के साथ) क्योंकि सेटअपटूल का केवल नवीनतम संस्करण इसका समर्थन करता है (हमें एक नया सेटपूल स्थापित करने की आवश्यकता है, भले ही व्यक्ति पर क्या है संगणक)। व्यावहारिक रूप से मुझे लगता है कि पीईपी 517 में कम से कम एक वर्ष की देरी हो सकती है क्योंकि यह नाटकीय रूप से इसे लागू करने के लिए आवश्यक प्रयासों की मात्रा में वृद्धि करेगा (पीईपी 517 और गैर-पीईपी 517 कोड की आवश्यकता है)।

यह एक पिछड़ा संगतता मुद्दा है, क्योंकि मौजूदा परियोजनाएं गैर-पृथक व्यवहार की अपेक्षा कर रही हैं।

अधिकांश लोगों के पास सीआई-स्क्रिप्ट हैं जो pip install X चलती हैं और फिर pip install Y चलती हैं। इन परियोजनाओं के लिए एक pypproject.toml जोड़ना होगा। लेकिन pyproject.toml जोड़ना इतना काम नहीं है, और यदि आवश्यक हो तो हम बिल्ड अलगाव को अक्षम करने के लिए कमांड लाइन ध्वज जोड़ सकते हैं।

अगर किसी प्रोजेक्ट में पाइप 10 में pyproject.toml नहीं है तो हमें कम से कम एक चेतावनी देनी चाहिए (ऐसा लगता है कि पीईपी 517 समर्थन वैसे भी नहीं होने वाला है)।

@xviat "यह समायोजित करने के लिए इतना काम नहीं होगा" यह नहीं है कि पिछड़ा संगतता कैसे काम करती है। यदि ऐसा होता, तो पाइप अब तक डिफ़ॉल्ट गैर-वेनव इंस्टॉलेशन मॉडल के रूप में --user पर स्विच हो जाता :)

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

क्या आप चेतावनी देने से ठीक होंगे?

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

पीईपी 518 और 517 को जानबूझकर मौजूदा परियोजनाओं के लिए शून्य व्यवधान पैदा करने के लिए डिज़ाइन किया गया था, जिसमें शामिल सभी प्रकाशक पूरी तरह से सेटअप टूल पर निर्भर थे।

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

मेरी डोनाल्ड जैसी ही टिप्पणी थी; इस सूत्र के बारे में मेरी समझ यह है कि बाइनरी-ओनली अस्थायी है क्योंकि इसे पाइप 10 के लिए लागू करने का कोई समय नहीं है। सही?

हां। बिल्कुल।

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

+1

मुझे लगता है कि हमें 2 प्रमुख रिलीज की तरह पुराने रास्ते को हटाने का लक्ष्य रखना चाहिए। जब पाइप भूमि पूर्ण और उचित पीईपी 518 समर्थन; हमें पुराने निर्माण तर्क को हटा देना चाहिए और इसे मानक बहिष्करण नीति के अनुसार हटा देना चाहिए।

मैं निक के सारांश से सहमत हूं और...

क्योंकि यह इसे लागू करने के लिए आवश्यक प्रयासों की मात्रा में नाटकीय रूप से वृद्धि करेगा

नहीं, मुझे नहीं लगता कि पीईपी 518 को इस तरह से लागू करने से कोई बड़ी सड़क ब्लॉक हो गई है; मैंने https://github.com/pypa/pip/pull/4799#issuecomment -339219397 पर एक संक्षिप्त टिप्पणी की कि इसे पाइप के भीतर कैसे लागू किया जा सकता है।

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

संग्रह में pyproject.toml फ़ाइल डालने का अर्थ यह होगा कि पैकेज नए मानक को चुन रहा है और नए व्यवहार के लिए समर्थन का परीक्षण करने के लिए तैयार है - अलगाव और बाइनरी-ओनली बिल्ड के साथ बिल्ड वातावरण से गुजरना -निर्भरता (अभी के लिए)।

नहीं, मुझे नहीं लगता कि पीईपी 518 को इस तरह से लागू करने से कोई बड़ी सड़क ब्लॉक हो गई है;

पीईपी 517 पर यहां चर्चा कर रहे हैं। गलतफहमी के लिए खेद है।

दोनों कोड पथों की जांच के लिए हमें दो बार परीक्षण चलाने होंगे। आह अच्छी तरह से पीईपी 517 शायद आस्थगित है।

आईएमओ,

1. चेतावनी अगर किसी प्रोजेक्ट में pyproject.toml नहीं है तो यह बहुत बुरा विचार लगता है। आखिरकार, पीईपीआई पर 99% परियोजनाओं में वर्तमान में pyproject.toml नहीं है, और हम अंतिम उपयोगकर्ताओं को चेतावनी के साथ स्पैम नहीं कर सकते हैं कि वे कुछ भी नहीं कर सकते हैं (परियोजना को समस्या की रिपोर्ट करने के अलावा) )। क्या मैं कुछ भूल रहा हूँ?
2. मुझे विश्वास नहीं है कि पीईपी 518 में बिल्ड अलगाव का उल्लेख किया गया था। यह एक अतिरिक्त विशेषता है जिसे पीआईपी कुछ समय के लिए शामिल करना चाहता है, लेकिन यह पीईपी 518 समर्थन से जुड़ा नहीं है, संयोग तथ्य को छोड़कर कि वही पीआर लागू किया गया है दोनों (AFAIR)। इसलिए अगर बिल्ड आइसोलेशन हमें यहां समस्या दे रहा है, तो मैं शुरुआत में सिर्फ पीईपी 518 रखने और चरण 2 के रूप में आइसोलेशन जोड़ने के साथ ठीक हूं। हालांकि, मैं चीजों को लागू करने वाले लोगों के लिए यह निर्णय छोड़ दूंगा।

क्या मैं कुछ भूल रहा हूँ?

नहीं।

मैं शुरुआत में सिर्फ पीईपी 518 के साथ ठीक हूं, और चरण 2 के रूप में अलगाव को जोड़ रहा हूं।

मुझे लगता है कि हमें पीईपी 518 करना चाहिए और एक साथ अलगाव का निर्माण करना चाहिए, क्योंकि यह एक अच्छा तरीका है कि लोग अलग-अलग बिल्ड पर स्विच करें।

जबकि न तो पीईपी 518 और न ही पीईपी 517 को पृथक बिल्ड की आवश्यकता है, पीईपी 517 उन्हें ध्वनि कारणों से अनुशंसा करता है: https://www.python.org/dev/peps/pep-0517/#recommendations -for-build-frontends-non-normative

स्थानीय बाइनरी आर्टिफैक्ट कैश के बिना, पृथक निर्माण वातावरण अव्यावहारिक हैं, लेकिन एक बार आपके पास उनमें से एक है (जैसा कि pip अब करता है), वे कहीं अधिक व्यवहार्य हैं, क्योंकि:

1. अधिकांश इंस्टॉलेशन पर, आपको पहली बार में सोर्स बिल्ड करने की भी आवश्यकता नहीं होगी
2. जब आपको स्रोत निर्माण करने की आवश्यकता होती है, तो आप आमतौर पर कैश से बिल्ड वातावरण सेट कर रहे होंगे

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

इसलिए pyproject.toml आधारित बिल्ड को शुरुआत से अलग किया जाना एक प्राकृतिक स्विचिंग पॉइंट प्रदान करता है, क्योंकि संपूर्ण पीईपी रनटाइम निर्भरता से अलग बिल्ड निर्भरता को स्पष्ट रूप से और लगातार घोषित करने का एक तरीका प्रदान करने के बारे में है। इसका मतलब है कि setup.py से स्विच करने वाले लोग संभवतः ऐसा इसलिए कर रहे हैं क्योंकि वे उस तरह का काम करने की परवाह करते हैं, जबकि नई परियोजनाओं के लिए नए सिरे से आने वाले लोग इसे एक और घेरा के रूप में मानेंगे कि पैकेजिंग टूलींग उन्हें कूदने के लिए बाध्य करता है के माध्यम से।

इसलिए, कोड लिखने के लिए नीचे आने से पहले मैं बस कुछ चीजों की पुष्टि करना चाहता हूं:

• पीईपी 517 समर्थन पाइप 10 के लिए अवरोधक नहीं है
• पीईपी 518 पिप 10 में
  
  
  
  • pyproject.toml . के माध्यम से ऑप्ट-इन करें
  
  
  • केवल बाइनरी-केवल बिल्ड-निर्भरता का समर्थन करता है
  
  
  • पृथक निर्माण
  
  

पीईपी 517 पाइप 10 के लिए अवरोधक नहीं हो सकता क्योंकि यह अभी तक तैयार नहीं है, और इस बिंदु पर आगे कोई स्पष्ट रास्ता नहीं है (आगे का रास्ता है लेकिन यह स्पष्ट नहीं है)।

मेरे पास @xoviat की टिप्पणी के जवाब में एक टिप्पणी और प्रश्न है, जिसमें कार्यान्वयन चुनौतियों का सारांश दिया गया है और साथ ही इस धागे को जल्दी से पढ़ने के बाद भी।

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

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

क्या कोई कारण है कि एक आंतरिक एपीआई फ़ंक्शन नहीं बनाया जा सका/रीफैक्टर किया जा सकता है जो जो भी शेलिंग आउट हासिल करने की कोशिश कर रहा है वह करेगा?

दूसरा, पाइथन के भीतर से पाइप फ़ंक्शन को कॉल करने के विरोध में शेलिंग आउट क्या खरीदता है?

यह समय खरीदता है जो वर्तमान में हमारे पास नहीं है। pip पहले से ही इसके रिलीज शेड्यूल से पीछे है।

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

मैं रिकर्सन विरोधी नहीं हूँ। मैं प्रक्रिया-पुनरावृत्ति विरोधी हूं। मुझे लगता है कि यह ठीक है यदि आप 100% सीपीयू का उपयोग करना चाहते हैं (ठीक है, यह पायथन में 20% होगा), लेकिन अंततः उपयोगकर्ता को कार्य प्रबंधक खोलने और अधिकतम 15 प्रक्रियाओं को मारने में सक्षम होना चाहिए। मेरे लिए, ऐसी स्थिति जो संभावित रूप से एक प्रक्रिया विस्फोट का कारण बन सकती है, अस्वीकार्य है।

हालांकि, यह इस सवाल का जवाब नहीं देता है कि यह समय क्यों खरीदता है। क्या एक आंतरिक एपीआई फ़ंक्शन बनाना मुश्किल बनाता है जो एक ही काम करता है?

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

हालांकि, यह इस सवाल का जवाब नहीं देता है कि यह समय क्यों खरीदता है। क्या एक आंतरिक एपीआई फ़ंक्शन बनाना मुश्किल बनाता है जो एक ही काम करता है?

अगर आपको लगता है कि यह आसान है, तो आगे बढ़ें। मैं यह व्यंग्यात्मक रूप से नहीं कह रहा हूं: कृपया, आगे बढ़ें, क्योंकि इससे सभी समस्याओं का समाधान हो जाएगा।

मुझे नहीं लगता कि यह आसान है। मैं प्रश्न पूछ रहा हूं कि यह अंतर्दृष्टि प्राप्त करने के लिए कि यह कठिन क्यों है। (मैं मान रहा हूं कि आपने इस बारे में सोचा है क्योंकि आपने कहा था कि इससे समय की बचत होगी।)

pkg_resources जैसे स्थानों में कैश की वजह से आम तौर पर उपप्रोसेस के अंदर चलाने के लिए आपको अलग पाइप इंस्टॉल की आवश्यकता होती है (हालांकि मैं वहां गलत हो सकता हूं)।

इसका मतलब यह नहीं है कि आपको pip पर कॉल करने की आवश्यकता है, आप एक एपीआई बना सकते हैं जो सीएलआई के माध्यम से डेटा को क्रमबद्ध करता है और python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" पर कॉल करता है और स्टडआउट से अधिक डेटा पढ़ता है। पाइप के कॉलिंग पिप्स कॉलिंग पिप्स कॉलिंग पिप्स के पुनरावर्ती समाधान को इस तरह के एपीआई का उपयोग करके स्टैक में बदलना संभव होगा (क्योंकि सभी रिकर्सन को स्टैक के रूप में भी वर्णित किया जा सकता है), आप अनिवार्य रूप से एक निजी एपीआई बना रहे होंगे जिसे एक प्रक्रिया कहा जाता है।

मैं अभी भी इस धागे को पढ़ने की योजना बना रहा हूं (हाल ही में कताई प्लेटों का एक गुच्छा था!), लेकिन एक बात पर: हमारे पास वास्तव में रिलीज शेड्यूल नहीं है, हम रिलीज करते हैं जब यह किसी लक्ष्य तिथि पर तैयार नहीं होता है। हम कभी-कभी कुछ सामान्य विचार रखते हैं कि हम कब रिलीज़ करना चाहते हैं, लेकिन यह कभी पत्थर में सेट नहीं होता है।

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

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

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

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

और सीधे @cjerdonek के प्रश्न का उत्तर देने के लिए: सिद्धांत रूप में यह कठिन नहीं है, जो चीजें मुश्किल बना रहा है वह कुछ एम्बेडेड वास्तुशिल्प धारणाएं हैं जो pip वर्तमान में काम करती हैं जो अब ऐसी दुनिया में सच नहीं हैं जहां प्रत्येक स्रोत का निर्माण होता है स्थापना वातावरण में सीधे चलने के बजाय, अपना अलग बिल्ड वातावरण प्राप्त करता है।

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

मुझे @dstufft का एक पुनरावृत्त/स्टैक-आधारित दृष्टिकोण में कनवर्ट करने और पैटर्न python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" का उपयोग करके आंतरिक पाइप फ़ंक्शन में खोलने का विचार पसंद है। यह चर्चा के आधार पर सरल लगता है, साथ ही मजबूत भी।

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

मैंने पुनरावर्ती दृष्टिकोण को पुनरावृत्त दृष्टिकोण में परिवर्तित करने के बारे में थोड़ा और देखा/सोचा। पीईपी 518 (पीआर #4799) पर @xoviat के आंशिक कार्य ने मुझे पुनरावर्तन के बिंदु को खोजने में मदद की (जो आप में से कुछ शायद पहले से ही परिचित हैं)। यह उनकी कोड टिप्पणी पर है:

# TODO: Use single process with recursion handling

जहां यह pip install ... आह्वान करता है।

मेरा विचार यह है कि ऐसा लगता है कि इसे pip install (निर्माण निर्भरताओं के लिए) के एक संस्करण द्वारा हल किया जा सकता है, जिसमें निम्न परिवर्तन की तरह कुछ है:

• अगर इंस्टाल को किसी सब-इंस्टॉलेशन की आवश्यकता नहीं है, तो इंस्टाल करें।
• अन्यथा, उप-स्थापनाओं की एक (संभवतः आंशिक) सूची के साथ वापस लौटें जो आवश्यक हैं (उदाहरण के लिए एक सहमत फ़ाइल में जानकारी लिखकर यदि stdout को लिखना पहले से काम नहीं करता है)।

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

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

@cjerdonek मुझे उस विचार में कोई समस्या नहीं दिख रही है। लेकिन आखिरकार किसी को इसे लागू करने की जरूरत है (मुझे लगता है कि @pradyunsg इस सप्ताह के अंत में कुछ काम करने जा रहा था?) और हमेशा की तरह अधिक कठिनाइयों का पता लगाया जा सकता है।

कुछ पास आ गया है। अगर कोई और इसे उठाना चाहता है, तो मेरे पास नहीं है
मुद्दे। :)

मुझे @dstufft का विचार भी पसंद है।

सूर्य पर, 29 अक्टूबर 2017, 08:47 xoviat , [email protected] ने लिखा:

@cjerdonek https://github.com/cjerdonek मुझे कोई समस्या नहीं दिख रही है
वह विचार। लेकिन आखिरकार किसी को इसे लागू करने की जरूरत है (मुझे लगता है)
@pradyunsg https://github.com/pradyunsg कुछ काम करने जा रहा था
इस सप्ताहांत?) और हमेशा की तरह अधिक कठिनाइयों का पता लगाया जा सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pypa/pip/issues/4802#issuecomment-340234567 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ADH7SYImpWgJGg-DzQRcO_9hHfE6ZxEAks5sw-5RgaJpZM4QBdSg
.

इस पर वापस आते हुए, क्या हम @dstufft द्वारा सुझाए गए स्टैक+आंतरिक आह्वान दृष्टिकोण के साथ आगे बढ़ना चाहते हैं?

/पिंग @ncoghlan @pfmoore @xavfernandez

हाँ कृपया। इसे आगे बढ़ाने के लिए कुछ भी।

क्या कोई है जो संक्षेप में बता सकता है कि हम पीईपी 517 और पीईपी 518 के साथ पीआईपी 10 रिलीज के संबंध में कहां खड़े हैं? विशेष रूप से:

1. क्या मास्टर वर्तमान में रिलीज करने योग्य स्थिति में है? पिछली बार मैंने सुना था, PEP 518 सपोर्ट टूट गया था (PEP 518 - #4647 से संबंधित कम से कम एक रिलीज़ ब्लॉकर इश्यू खुला है)।
2. क्या हमारे पास एक काम कर रहे पीईपी 517 और/या पीईपी 518 कार्यान्वयन एक समय-सीमा में होने की संभावना है जो पीआईपी 10 को उपलब्ध होने तक देरी करना उचित बनाता है?
3. मान लें कि हम सामान को (1) में ठीक करते हैं, क्या हम पीईपी 517/518 के बिना पीआईपी 10 रिलीज करना चाहते हैं? हमने रिलीज़ के बारे में एक हेड-अप ईमेल तैयार किया, ताकि लोग जान सकें कि यह आ रहा है। और वहां कुछ उचित महत्वपूर्ण सुधार हैं (उदाहरण के लिए, विंडोज़ के लिए एन्कोडिंग फिक्स) जो रिलीज करना अच्छा होगा।

मेरी भावना यह है कि हम रिलीज ब्लॉकर्स पर प्रतीक्षा कर रहे हैं, लेकिन हम पीईपी 517/518 समर्थन के लिए पर्याप्त नहीं हैं ताकि उन पर पीआईपी 10 को ब्लॉक किया जा सके। लेकिन मुझे नहीं लगता कि पीईपी 518 को लागू करने के अलावा कोई भी #4647 पर काम कर रहा है।

एक वैकल्पिक विकल्प मौजूदा पीईपी 518 समर्थन की सीमाओं का दस्तावेजीकरण करना और रिलीज अवरोधक होने से #4647 को डाउनग्रेड करना होगा। मुझे यह जानने के लिए उपयोग के मामलों के बारे में पर्याप्त जानकारी नहीं है कि क्या यह व्यवहार्य है।

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

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

यह मुझे यह भी याद दिलाता है कि मुझे शायद मामलों को ठीक करना चाहिए ताकि उड़ान खुद की निर्माण आवश्यकता न हो।

आधे-अधूरे प्रारंभिक कार्यान्वयन के लिए क्षमा याचना जो एक कांटा बम के रूप में कार्य करने के लिए उत्तरदायी है,

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

क्या मास्टर वर्तमान में रिलीज करने योग्य स्थिति में है?

IIUC, यह अभी तक एक प्रणाली को फोर्क-बम कर सकता है; क्या वो सही है? अगर ऐसा है तो मुझे लगता है कि ऐसा नहीं है।

क्या हमारे पास एक काम कर रहे पीईपी 517 और/या पीईपी 518 कार्यान्वयन एक समय-सीमा में होने की संभावना है जो पीआईपी 10 को उपलब्ध होने तक देरी करना उचित बनाता है?

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

मुझे नहीं लगता कि पीईपी 518 को लागू करने के अलावा कोई भी #4647 पर काम कर रहा है।

मुझे लगता है कि आपका मतलब है, पीईपी 518 के पूर्ण कार्यान्वयन के साथ स्रोत निर्माण निर्भरताओं की अनुमति है?

ओह, और लगभग #4647 -- @xoviat का विवरण ऊपर कहता है, फिक्सिंग जो कोड को बदलना/चलती है और वस्तुओं की स्वामित्व/दृश्यता (विशेष रूप से BuildEnvironment ) लेती है, जो गैर तुच्छ है।

मुझे लगता है कि इसे पहियों तक सीमित करना इस लाइन को बदलने जितना आसान होना चाहिए:

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

प्रति:

finder.format_control = FormatControl(set(), set([':all:']))

दूसरा क्षेत्र केवल बायनेरिज़ के रूप में खोजने के लिए पैकेजों का एक सेट है, जिसमें सभी पैकेजों का मतलब ':all:' के लिए एक विशेष मामला है।

हां। लेकिन वह अकेले #4647 को संबोधित नहीं करेगा। साथ ही, इनमें से कोई भी कोड नहीं जाता है
एक समाधानकर्ता के माध्यम से।

शनिवार, 2 दिसंबर 2017 को 01:23 पर थॉमस क्लूवर नोटिफिकेशन @github.com ने लिखा:

मुझे लगता है कि इसे पहियों तक सीमित करना इसे बदलने जितना आसान होना चाहिए
रेखा:

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

प्रति:

Finder.format_control = FormatControl (सेट (), सेट ([': सभी:']))

दूसरा क्षेत्र केवल बायनेरिज़ के रूप में खोजने के लिए संकुल का एक सेट है
सभी पैकेजों के लिए ':all:' के लिए एक विशेष मामला।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pypa/pip/issues/4802#issuecomment-348598368 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ADH7SUi0QMS3rr5Iba90XWZmFweGmqeBks5s8FlEgaJpZM4QBdSg
.

ठीक है, इसमें कई अन्य चीजें गलत हैं। लेकिन इसे फोर्क-बमबारी से रोकना चाहिए, जो मुझे लगता है कि सबसे ज्यादा चिंता का विषय है।

अगर कोई मेरा मूल पीआर लेना चाहता है ("पीईपी 518 समस्याओं को ठीक करें"),
इसे बदलना मुश्किल नहीं होना चाहिए ताकि अलगाव का निर्माण न हो
pyproject.toml के बिना सक्षम। मूल कारण इसका विलय नहीं किया गया था
यह था कि इसने स्रोत से निर्भरता स्थापित करने के लिए समर्थन छोड़ दिया था
पीईपी 518. हालांकि, अब जब लोगों को यह एहसास होने लगा है कि पीईपी 518 मई
पीआईपी 10 में बिल्कुल भी न हों, वे उस पीआर को स्वीकार करने के लिए अधिक उत्तरदायी हो सकते हैं। मैं
व्यक्तिगत रूप से इसे चैंपियन बनाने का समय नहीं है, लेकिन इससे दूसरों को रोकना नहीं चाहिए
इसे आगे ले जाने से, क्योंकि परिवर्तनों की केवल कुछ पंक्तियों की आवश्यकता होगी
(पीईपी 518 परीक्षण में असफल होने के अलावा)।

वास्तव में, मेरे बेहतर निर्णय के विपरीत, मैं शीघ्र ही पीईपी 517 और 518 दोनों को लागू करने के लिए तैयार हूं यदि पीआईपी डेवलपर्स मेरी शर्तों से सहमत होंगे:

1. निर्भरता शुरुआत में पहियों पर ही होगी
2. पाइप में शुरू में एक आंतरिक बिल्ड बैकएंड होगा, भले ही इसे अंततः हटा दिया जाएगा

मुझे 1 के साथ कोई समस्या नहीं है; मेरे पास 2 के लिए कोई वरीयता नहीं है।

रविवार, 3 दिसंबर 2017 को 02:36 बजे xoviat [email protected] ने लिखा:

वास्तव में, मेरे बेहतर निर्णय के विरुद्ध, मैं PEP दोनों को लागू करने के लिए तैयार हूँ
517 और 518 शीघ्र ही अगर पाइप डेवलपर्स मेरी शर्तों से सहमत होंगे:

1. निर्भरता शुरुआत में पहियों पर ही होगी
2. पाइप में शुरू में एक आंतरिक बिल्ड बैकएंड होगा, भले ही यह
   अंततः हटा दिया जाएगा

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pypa/pip/issues/4802#issuecomment-348720096 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ADH7ST6riptZkYMap5Z5SstRf-VmE7eAks5s8bu5gaJpZM4QBdSg
.

FYI करें शर्तें मनमानी नहीं हैं लेकिन प्रारंभिक कार्यान्वयन को संभव बनाने के लिए हैं। क्या @pfmoore इसके साथ ठीक है?

मैं विशेष रूप से "अपने बेहतर निर्णय के खिलाफ ... मेरी शर्तों से सहमत हूं" प्रस्ताव के लहजे से सहज नहीं हूं। यदि अन्य पीआईपी डेवलपर्स इस प्रस्ताव को लेने के लिए खुश हैं तो मुझे कोई आपत्ति नहीं होगी, लेकिन व्यक्तिगत रूप से मेरे पास इस समय कार्यान्वयन विवरण पर पूरी बहस को फिर से शुरू करने का समय नहीं है। मूल रूप से, मैं इस पर @dstufft और @xavfernandez को टाल दूंगा ( @pradyunsg पहले ही अपने विचार दे चुका है)।

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

मैं सिर्फ इतना कहूंगा कि मैं भी स्वर के साथ बहुत सहज नहीं हूं, यह है
बस, मेरे पास यह जानने का समय या ऊर्जा नहीं है कि उस स्वर का उपयोग क्यों किया गया था
आदि मेरी ओर से संक्षिप्त उत्तर के लिए एक ही कारण।

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

सूर्य पर, 3 दिसंबर 2017, 23:37 xoviat , [email protected] ने लिखा:

प्रस्ताव का लहजा ऐसा है कि यह इसलिए है क्योंकि के तरीके
किस बारे में मूलभूत असहमति के कारण कार्यान्वयन बंद कर दिया गया था
एक प्रारंभिक कार्यान्वयन की तरह दिखेगा। मैं इसके बजाय सहमत हूँ
सिद्धांत अब एक और कार्यान्वयन बहस में विकसित होने के बजाय।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pypa/pip/issues/4802#issuecomment-348802032 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ADH7ScUh-BveonoTxZ5FkkeSynFvoLb8ks5s8uNRgaJpZM4QBdSg
.

ईमानदारी से, पोस्ट के स्वर पर आगे चर्चा करने के लिए शायद यह किसी के समय का प्रभावी उपयोग नहीं है, क्योंकि यह इन विशेषताओं को पाइप 10 में शामिल करने के लिए प्रासंगिक नहीं है। हालांकि, मुझे एक आश्वासन की आवश्यकता है कि मेरी शर्तें किसी भी @pfmoore से विलय करने के लिए स्वीकार्य हैं ( जिसने संकेत दिया है कि वह ऐसा आश्वासन नहीं दे सकता है, जो स्वीकार्य है कि यहां किसी को उनके समय के लिए भुगतान नहीं किया जाता है), @dstufft , या @xavfernandez।

फिर से, शर्तें मेरी व्यक्तिगत राय नहीं हैं, बल्कि कार्यान्वयन से प्रेरित हैं। अगर मैं इन शर्तों में ढील देता हूं, तो मैं एक कार्यान्वयन का वादा नहीं कर सकता, इसलिए पीआर तैयार करने पर समय बिताने का कोई मतलब नहीं है, और फिर लोग अंतर पढ़ रहे हैं और पूछ रहे हैं "ओह, यह लाइन यहां क्यों है?" और फिर "ओह, तो यह विलय योग्य नहीं है?" क्योंकि पीआर का उद्देश्य वास्तव में क्या था, इस बारे में गलत संचार था।

स्वर फिर से सहमत। मेरा कहना बस इतना है कि मैं परिवर्तन का विलय नहीं करूंगा[1], इसलिए मेरा विचार यहां वास्तव में उतना महत्वपूर्ण नहीं है।

[1] स्पष्ट रूप से, मैं कह रहा हूं कि कार्यान्वयन को देखे बिना, इसलिए मुझे आशा है कि यह स्पष्ट है कि मेरे कारणों का कोड गुणवत्ता के बारे में चिंताओं से कोई लेना-देना नहीं है - यह सुनिश्चित करने के लिए समय नहीं होने के बारे में है कि मैं कोड को पर्याप्त रूप से समझता हूं मूल रूप से विलय करने के लिए तैयार रहें।

@xoviat हमने ऊपर चर्चा की पुनरावृत्ति बनाम पुनरावर्ती दृष्टिकोण के संबंध में आपकी कार्यान्वयन योजनाएं क्या हैं?

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

पहली शर्त संपूर्ण रिकर्सन समस्या को समाप्त करती है।

साथ ही, स्पष्ट करने के लिए, क्या आप कह रहे हैं कि आप पहले पीईपी 517 और 518 के आंशिक कार्यान्वयन को पूरा करेंगे जिसे विलय किया जा सकता है, उसके बाद एक पूर्ण कार्यान्वयन जिसे विलय किया जा सकता है?

मैं जो कह रहा हूं वह यह है कि मैं आंशिक कार्यान्वयन पूरा करूंगा, यह 95% उपयोग के मामलों के लिए काम करेगा; विशेष रूप से उस मामले में जहां निर्भरताओं में पहिए होते हैं (अब बहुत आम हैं) और आप कई लिनक्स/विंडोज़/ओएसएक्स प्लेटफॉर्म (उपयोगकर्ताओं के विशाल बहुमत) पर हैं।

यह पूर्ण कार्यान्वयन नहीं है। लेकिन जिस तरह से आप गैर-विलय योग्य पीआर प्राप्त करते हैं, वह "सभी या कुछ भी नहीं" दृष्टिकोण करने की कोशिश कर रहा है जहां आप या तो मानक का पालन करते हैं या आप नहीं करते हैं।

ध्यान रखें कि एक पूर्ण कार्यान्वयन के लिए कुछ काफी खराब मुद्दों को हल करने की आवश्यकता होगी, जिनमें से प्रत्येक को एक अलग पीआर की आवश्यकता होगी (जैसा कि 100+ टिप्पणियों के साथ पीआर होने का आमतौर पर मतलब है कि कोड की अच्छी तरह से समीक्षा नहीं की गई है)। [1]

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment -313843216

मैं अब इस मुद्दे को बंद कर दूंगा - हमारे पास पीईपी 518 के लिए पीआईपी 10 में प्रारंभिक समर्थन है जो केवल पहियों को बिल्ड निर्भरता के रूप में समर्थन करता है। मैं पूर्ण समर्थन के बारे में चर्चा करने के लिए एक नया मुद्दा खोलूंगा और दूसरा पीईपी 517 समर्थन के लिए (यहां से प्रासंगिक के रूप में उद्धृत)।

आपकी अंतर्दृष्टि और सहायता के लिए @ncoglan @rgommers @cjerdonek धन्यवाद। PEP 518 के शुरुआती क्रियान्वयन के लिए @takluyver का धन्यवाद। इन परिवर्तनों को लागू करने में सभी सहायता के लिए @xoviat (जो अब @ghost हैं) का धन्यवाद। धन्यवाद @ benoit-pierre वर्तमान समर्थन को बेहतर बनाने में आपकी सहायता के लिए।

पीएस: 100 वीं टिप्पणी! टाडा:

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।