अजगर निर्भरता अराजकता

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



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

- मॉस्को पायथन कॉन्फ ++ में आप निर्भरता और उनके आगे होने वाली हर चीज के बारे में बात करेंगे। आपने रिपोर्ट के लिए सिर्फ ऐसा विषय क्यों चुना?

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

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

- दर्द हमेशा दिलचस्प होता है। आपको क्या लगता है कि पायथन के इस हिस्से में अभी क्या समस्याएं हैं?

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

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

न केवल पायथन में कुछ रिसोल्वर हैं, वे डिजाइन से भी धीमी हैं।

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

- मैं अक्सर प्रोग्रामरों से सुनता हूं कि वे पाइप का उपयोग करते हैं, और उनके लिए सब कुछ ठीक काम करता है। वे क्या गलत कर रहे हैं?

वे भाग्यशाली हैं, वे निर्भरता के संघर्ष में नहीं आते हैं। हालाँकि समस्या तब पैदा हो सकती है जब आप एक स्वच्छ वातावरण में सिर्फ दो पैकेज डालते हैं। हाल ही में कवरेज 5.0 पैकेज का विमोचन हुआ था, और यदि आप pip install pytest-cov coveralls निर्दिष्ट करें, पाइप क्रम में जाएगा और पहले पैकेज के लिए कवरेज के नवीनतम संस्करण का चयन करेगा, जो 5.0 है। पहले मैच जीत का सिद्धांत पाइप में काम करता है, इसलिए भले ही संस्करण दूसरे पैकेज के साथ संगत न हो, यह पहले से ही पहले पैकेज के लिए तय हो जाएगा। अक्सर यह दृष्टिकोण काम करता है, लेकिन हमेशा नहीं।

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

- यह विषय अब ऐसी प्रासंगिकता क्यों प्राप्त कर रहा है, जैसा आप सोचते हैं? पहले कुछ भी क्यों नहीं हुआ, लेकिन अब यह अलग-अलग दिशाओं में हो गया है?

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

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

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

इस प्रकार, आवश्यकताओं को पार्स करने के लिए। आपको पाइप या किसी तीसरे पक्ष के समाधान का उपयोग करने की आवश्यकता है। सभी तृतीय-पक्ष समाधान अनिवार्य रूप से कांटे हैं और फ़ाइल के बारे में कुछ प्रकार की धारणाओं का उपयोग करते हैं। हर मुश्किल आवश्यकताएं नहीं। टेक्स्ट फ़ाइल पाइप पढ़ सकता है इन कांटों को पढ़ने में सक्षम होगा।

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

- अन्य भाषाओं में कैसे? क्या यह उतना ही बुरा है, या ये सभी समस्याएं कहीं हल हैं?

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

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

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

उन्होंने एक Pipfile बनाया, लेकिन चूंकि पाइप बहुत भ्रामक है, इसलिए वे इसमें Pipfile समर्थन नहीं जोड़ सके।

डेवलपर्स ऐसा करना चाहते हैं, बिल्कुल। सबसे अधिक संभावना है, किसी दिन वे सक्षम होंगे, लेकिन अभी तक पाइप Pipfile का समर्थन नहीं कर सकता है। इसलिए, हमने Pipfile को Pipfile और आभासी वातावरण, पर्यावरण के साथ कुछ अन्य आवरणों के साथ काम करने के लिए बनाया। लेकिन पिपेनव में भी, सब कुछ मिश्रित और भ्रमित है।

अन्य भाषाओं के लिए, मुझे पसंद है कि गो में निर्भरता प्रबंधन कैसे लागू किया जाता है। इससे पहले, इसमें कोई संस्करण नहीं था, वहाँ go get था, जिसमें आप इंगित करते हैं कि किस भंडार से कौन सा पैकेज डाउनलोड करना है। एक शुरुआत के दृष्टिकोण से, यह सुविधाजनक है: आप बस लिखते go get और पैकेज पहले से ही सिस्टम में है। और जब आप पायथन के साथ काम करना शुरू करते हैं, तो हर चीज का एक पूरा ढेर तुरंत ढह जाता है: कुछ संस्करण, PyPI, पाइप, आवश्यकताएँ। Txt, setup.py, अब Pipfile, Poetry, __pymodules__ , आदि।

जैसा कि पायथन आकस्मिक रूप से विकसित होता है और समुदाय की मदद से पारिस्थितिक तंत्र में विरासत बनाता है। गो बस go get था, लेकिन फिर से यह समस्या उत्पन्न हो गई कि निर्भरता को ठीक करने की आवश्यकता है ताकि, विशेष रूप से, पर्यावरण प्रतिलिपि प्रस्तुत करने योग्य था।

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

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

लगभग एक साल पहले go.mod (Go Modules) Go में दिखाई दिया। यह एक नया बिल्ट-इन टूल है, लेकिन go get भी सपोर्ट go get । परियोजना में दो फाइलें हैं:

• एक निर्भरता का वर्णन करता है जिसके साथ परियोजना सीधे काम करती है;
• अन्य एक लॉक फ़ाइल है, जो बिल्कुल सभी निर्भरता और उनके विशिष्ट संस्करणों का वर्णन करता है।

यह एक शांत केंद्रीकृत समाधान है।

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

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

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

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

गो के पास सब कुछ है जो आपको अभी निर्भरता के साथ काम करने की आवश्यकता है। पायथन में, आपको बाहर से सब कुछ पुनः स्थापित करने की आवश्यकता है, और आपको अभी भी समझने की आवश्यकता है कि वास्तव में क्या है। सबसे अधिक बार, पाइप पर्याप्त है, लेकिन अब अन्य विकल्प दिखाई दे रहे हैं।

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

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

- आपको क्या लगता है कि निर्भरता के साथ काम करने के मामले में पारिस्थितिकी तंत्र का भविष्य क्या है? आपकी भविष्यवाणी

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

उदाहरण के लिए, हमारे पास ऐसी कहानी थी: PyYAML का एक निश्चित संस्करण लॉक फाइल में बंद था। एक दिन सीआई पास पर परीक्षण, हम उत्पादन के लिए तैनात करते हैं, और सब कुछ वहां गिर जाता है, क्योंकि PyYAML संस्करण नहीं मिला। बात यह थी कि लॉक किए गए संस्करण को pypi.org से हटा दिया गया था। हर कोई आक्रोश में था, लॉक फ़ाइल को अपडेट किया, किसी तरह बच गया, लेकिन तलछट बनी रही।

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

दूसरी दिलचस्प बात __pymodules__ लिए PEP है। ये हल्के आभासी वातावरण हैं: आप प्रोजेक्ट डायरेक्टरी खोलते हैं, PyYAML pip install करते हैं, और PyYAML को विश्व स्तर पर नहीं, बल्कि __pymodules__ डायरेक्टरी में स्थापित किया जाता है। जब पायथन इस निर्देशिका में शुरू होता है, तो यह विश्व स्तर पर नहीं, बल्कि इस निर्देशिका से PyYAML का आयात करता है।

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

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

- ठीक है, आपके पूर्वानुमान में भविष्य अब की तुलना में उज्जवल है।

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

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

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

परीक्षणों के साथ जाओ काम अच्छी तरह से लागू किया जाता है, यहां तक ​​कि गो मॉड्यूल ट्यूटोरियल में यह लिखा गया है कि निर्भरता कैसे अपडेट करें: आप कुछ निर्भरता को अपडेट करते हैं और परीक्षण चलाते हैं। इसके अलावा, परीक्षण न केवल तुम्हारा, बल्कि इस निर्भरता को भी चलाते हैं।

एक दिलचस्प पहलू अभी भी ध्यान देने योग्य है: क्या परीक्षण पायथन में संकुल में होना चाहिए? जब आप pypi.org से पैकेज डाउनलोड करते हैं, तो क्या परीक्षण होना चाहिए? सिद्धांत रूप में, उन्हें चलना चाहिए और यहां तक ​​कि उन्हें चलाने के लिए एक तंत्र भी होना चाहिए: setup.py में आप निर्दिष्ट कर सकते हैं कि परीक्षण कैसे चलाएं, उनके पास क्या निर्भरता है।

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

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

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

- क्यों, आपकी राय में, पायथन में, स्वचालित अर्थ वर्जनिंग के लिए उपकरण लोकप्रिय नहीं हैं?

मुझे लगता है कि समस्याओं में से एक यह है कि संस्करण को कई स्थानों पर वर्णित किया जा सकता है। ज्यादातर अक्सर उनमें से तीन होते हैं: प्रोजेक्ट मेटाडेटा विवरण प्रारूप (pypi.org, poety, setup.py, आदि), परियोजना के अंदर और प्रलेखन में। तीन स्थानों में एक संस्करण को अपग्रेड करना बहुत मुश्किल नहीं है, लेकिन भूलना आसान है।

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

दिलचस्प है, इस मुद्दे को फ्लिट में हल किया गया है। पैकेज मेटाडेटा का वर्णन करने के लिए, पैकेज को डिसाइड करने और उसे डाउनलोड करने के लिए फ़्लिट एक न्यूनतम उपकरण है। केवल चार टीमों के होते हैं: init, build, publishऔरinstall . , , PyPI — . Flit , . docstring . , .

DepHell Flit . description, , , .

, .

DepHell import , , , , . , , .

, Moscow Python Conf++ 27 . DepHell backend, web, , AI/ML, , DevOps, , IoT, infosec . , , Moscow Python Conf++.