क्या मुझे अपने पायथन निर्भरता संस्करणों को पिन करना चाहिए?

Question

मैं एक पाइथन लाइब्रेरी जारी करने वाला हूं जो पिछले कुछ हफ्तों में काम कर रहा हूं। मैं अजगर निर्भरता के बारे में बहुत पढ़ा है लेकिन कुछ अभी तक काफी स्पष्ट नहीं है:

कुछ लोगों का नाटक आप कभी नहीं अपने निर्भरता संस्करणों पिन के रूप में यह उन निर्भरता उन्नयन से अपनी लाइब्रेरी के उपयोगकर्ताओं रोका जा सके चाहिए।

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

मैं किसी भी तरह (अर्थ संस्करण तय है कि इस तरह के संस्करणों हो रहे हैं जब प्रमुख संस्करण संख्या 0 है सिवाय एक संकर समाधान, जहां मैं अपने निर्भरता semantic versioning इस्तेमाल किया ग्रहण साथ खूंटी में केवल प्रमुख संस्करण संख्या (कहते हैं somelib >= 2.3.0, < 3) के लिए चला गया हूँ अस्थिर माना जाता है और एपीआई तोड़ सकता है भले ही केवल पैच संख्या बंप हो)।

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

Answer 1

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

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

(अजगर सॉफ्टवेयर संकुल के लिए मेटाडाटा) PEP 426 about Semantic dependencies की धारा कहती है:

"निर्भरता प्रबंधन भारी संस्करण की पहचान और विनिर्देश योजना PEP 440 (पीईपी 440 - संस्करण पहचान और निर्भरता विशिष्टता) में परिभाषित पर निर्भर है।"

इससे, मैं अनुमान लगाता हूं कि आधिकारिक "सर्वोत्तम अभ्यास" आपकी निर्भरताओं का संस्करण है, क्योंकि पैकेजिंग पर पीईपी के संबंध संबंधित पीईपी द्वारा उल्लिखित संस्करणों के विवरण पर "भारी निर्भर" कहा जाता है।

Answer 2

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

क्यों? Python Dependency Resolution का विस्तृत अध्ययन, हजारों पीईपीआई पैकेजों और निर्भरता संघर्ष की उनकी वर्तमान दरों का विश्लेषण करने के बाद, इस मुद्दे पर चर्चा करता है। यह बताते हैं कि:

यदि वितरण का अपना, खाली, एकल उद्देश्य वातावरण में स्थापित नहीं है, तो निर्भरता संघर्ष की संभावना काफी हद तक बढ़ जाती है अगर निर्भरता संस्करणों सभी बजाय पर्वतमाला लचीला छोड़ने की पिन किए गए होते।

और लिखते हैं कि पिन सुरक्षा समस्याओं उन्नयन के साथ हस्तक्षेप से ख़राब कर सकता है।

यह सलाह देता है: एक परियोजना निर्भरता पिन

है, तो यह, हर बार कुछ भी करने का एक महत्वपूर्ण रिहाई परियोजना प्रत्यक्ष या परोक्ष रूप पर निर्भर करता है वहाँ एक नया विज्ञप्ति जारी करना तैयार रहना चाहिए नीचे सभी तरह निर्भरता श्रृंखला।

Answer 3

दो अन्य उत्तरों एक-दूसरे के विरोधाभास का कारण यह है कि वे दोनों सही (और पढ़ने योग्य हैं) हैं, लेकिन वे विभिन्न स्थितियों पर लागू होते हैं।

यदि आप पीईपीआई पर लाइब्रेरी जारी कर रहे हैं, तो आपको जो भी निर्भरताओं के बारे में पता है, उन्हें घोषित करना चाहिए, लेकिन पिन एक विशिष्ट संस्करण में नहीं है। उदाहरण के लिए, यदि आपको पता है कि आपको >= 1.2 की आवश्यकता है, लेकिन 1.4 टूटा हुआ है, तो आप somepkg >= 1.2, != 1.4 जैसे कुछ लिख सकते हैं। यदि आप जानते हैं कि somepkg सेमवीर का पालन करता है, तो आप < 2 जोड़ सकते हैं।

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

ध्यान दें कि सलाह के ये दो टुकड़े एक-दूसरे के पूरक हैं: यह केवल एक तथ्य है कि यदि ऐप ए लाइब्रेरी बी का उपयोग करता है, तो या तो ए के लेखक या बी के लेखक पिन बी की निर्भरताओं को पिन कर सकते हैं, लेकिन दोनों नहीं। तो हमें एक चुनना है। यहां अंतर्निहित सिद्धांत यह है कि यह संभवतः देर से किया जाता है, यानी, ए के लेखक द्वारा, जो अपनी पूरी प्रणाली देख सकते हैं; लाइब्रेरी बी का काम इन निर्णयों को बनाने में मदद करने के लिए कुछ उपयोगी संकेतों को पारित करना है। विशेष रूप से, यदि सभी पुस्तकालयों में ए रिकॉर्ड पर निर्भर करता है कि वे अपनी अंतर्निहित निर्भरताओं के बारे में क्या जानते हैं, तो ए के लिए समझदारी से निर्णय लेना संभव है कि वे ओवरलैप करते समय क्या करें। जैसे निर्भरता बी requests >= 1.0, != 1.2 पर निर्भर करता है, और निर्भरता सी requests >= 1.1 पर निर्भर करती है, तो हम अनुमान लगा सकते हैं कि 1.1 या 1.3 पिन के लिए अच्छे संस्करण हो सकते हैं। यदि निर्भरता बी requests == 1.1 पर निर्भर करती है और निर्भरता सी requests == 1.2 पर निर्भर करती है, तो हम बस अटक गए हैं।