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

/cc @uranusjr @jtratner @ncoghlan

maya मुद्दों के कुछ संदर्भ:

• kennethreitz/maya#138 (RemovePipfile.lock रिपॉजिटरी से)
• kennethreitz/maya#139 (tox.ini में पिपेनव रन छोड़ें ...)
• kennethreitz/maya#145 (setup.py में pendulum>=1.0 ठीक करें: संस्करण पिपफाइल में था लेकिन setup.py में गायब था)
• Kennethreitz/maya#143 (पीआर दिखा रहा है कि कैसे pipenv मुद्दे ने पूरे ट्रैविस रन को तोड़ दिया)
• kennethreitz/maya#144 (अर्ध-आधिकारिक सर्वोत्तम प्रथाओं के अनुसार पीआर रिफैक्टर पिपेनव उपयोग)

मुझे यह भी पसंद है। हो सकता है कि हमें इसे पिपेनव के दस्तावेज़ीकरण, या यहां तक ​​कि पायथन पैकेजिंग उपयोगकर्ता मार्गदर्शिका में जोड़ना चाहिए।

उपरोक्त सलाह का परिणाम "निर्धारक/पुनरुत्पादित सीआई बनाता है" प्रतीत होता है, जो मुझे एक बहुत बड़े विरोधी पैटर्न के रूप में मारता है।

आप एक विकल्प के रूप में क्या प्रस्तावित कर रहे हैं जो अभी भी नियतत्ववाद की अनुमति देगा?

@ tsiq-oliverc नियतात्मक बिल्ड का इस समय अपना स्थान है, एक एप्लिकेशन बनाया जाना है।

अजगर पुस्तकालय के वास्तव में नियतात्मक निर्माण करने के लिए निम्नलिखित प्रयास की कल्पना करें:

• बिल्ड Pipfile.lock पर आधारित होना चाहिए
• प्रत्येक निष्पादन संदर्भ (प्रत्येक पायथन और ओएस संस्करण का संयोजन) में अलग-अलग Pipfile.lock जिसके परिणामस्वरूप Pipfile में परिभाषित पुस्तकालय सार निर्भरताएं होती हैं।
• भंडार में परिभाषित अलग Pipfile.lock उदाहरण प्रदान करना होगा भंडार। ध्यान दें, कि CI बिल्ड के दौरान स्वचालित रूप से Pipfile.lock निर्माण कोई नियतत्ववाद नहीं जोड़ता है

यह बहुत अधिक अतिरिक्त प्रयास है। और आपको जो मिलता है वह एक पुस्तकालय है, जिसे अलग-अलग संदर्भ में स्थापित किया जाएगा (उदाहरण के लिए एक सप्ताह बाद मानक स्थापना उन्नत निर्भरता या दो उठाएगी) और जिसे तथ्य से कुछ भी नहीं मिलेगा, आपने Pipfile.lock , जो फिलहाल अप्रचलित है।

संघर्ष इस तथ्य में है कि पुस्तकालय को कभी भी सख्त निर्भरताओं को परिभाषित नहीं करना चाहिए।

यदि आपको लगता है, अजगर पुस्तकालय के लिए नियतात्मक निर्माण प्राप्त करने के लिए एक और विकल्प है - इसका वर्णन करें।

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

लेकिन यहां लक्ष्य संभवत: बहुत छोटा दायरा है। विशेष रूप से, मैं निम्नलिखित के रूप में एक पुस्तकालय अनुरक्षक के लिए लक्ष्य देखूंगा (जो मोटे तौर पर समकक्ष हैं):

1. यदि आप अपना CI दो बार चलाते हैं, तो आपको वही परिणाम प्राप्त होने की गारंटी है (नेटवर्क समस्याओं के बावजूद!)
2. आप सीआई पर देखे जाने वाले व्यवहार को स्थानीय रूप से फिर से बना सकते हैं (और इस प्रकार डीबग) कर सकते हैं, भले ही इसका मतलब डॉकर/आदि चलाना हो। स्थानीय रूप से।
3. आप विश्वास के साथ कह सकते हैं "मेरी लाइब्रेरी आपके उपभोक्ताओं के लिए निर्भरता संस्करण X, Y, Z के साथ अपेक्षा के अनुरूप व्यवहार करती है"।

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

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

मैंने यह जानने के लिए पर्याप्त पिपेनव का उपयोग नहीं किया है कि यह अभ्यास में कितना आसान होगा, हालांकि।

मैं वर्तमान में सीआई सिस्टम के लिए कुछ पुस्तकालय परियोजनाओं में Pipfile s जोड़ने पर विचार कर रहा हूं।

मुझे पूरी तरह से कंपनी-व्यापी सुरक्षा दिशानिर्देशों का अनुपालन करने के लिए निर्भरता लॉकिंग (+ हैशिंग) की आवश्यकता है और मुझे वर्तमान में विभिन्न पायथन संस्करणों के साथ परीक्षण करने की आवश्यकता नहीं है, क्योंकि आधिकारिक तौर पर समर्थित केवल एक ही है। और तथ्य यह है कि पिपेनव वर्चुअलएन्व समेत स्थानीय विकास पर्यावरण की स्थापना को सरल बनाता है, यह एक अच्छा दुष्प्रभाव है।

और आपको जो मिलता है वह एक पुस्तकालय है, जिसे अलग-अलग संदर्भ में स्थापित किया जाएगा (उदाहरण के लिए एक सप्ताह बाद मानक स्थापना उन्नत निर्भरता या दो उठाएगी) और जिसे तथ्य से कुछ भी नहीं मिलेगा, आपने Pipfile.lock , जो फिलहाल अप्रचलित है।

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

(हाँ, मैं एक पुस्तकालय के बारे में बात कर रहा हूँ, यहाँ एक आवेदन नहीं...)

@ Moritz90 आपका परिदृश्य उद्यम वातावरण में अजगर पुस्तकालय के लिए है और वहां pipenv मदद कर सकता है क्योंकि यह बहुत अधिक नियतात्मक वातावरण है।

मेरा विवरण सामान्य अजगर पुस्तकालयों जैसे flask , request , maya आदि पर लक्षित है जहां संदर्भ बहुत अधिक परिवर्तनशील है। maya में कुछ चीजों को ठीक करने का प्रयास करते हुए मुझे यह सीखने में निराशा हुई, कि कई मामलों में pipenv ने वास्तविक समस्याएं (आमतौर पर उन समस्याओं को छिपाना जो सामान्य रूप से पता लगाया जाएगा) को अधिक या कोई अतिरिक्त प्रदान नहीं करते हुए पेश किया। मूल्य।

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

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

@uranusjr - ज़रूर। मैं मानता हूं कि अगर इच्छा "गैर-नियतात्मक निर्माण" है, तो ऊपर की सलाह अच्छी तरह से समझ में आ सकती है। वास्तव में, यह लगभग एक तार्किक समानता है, और इसे और अधिक संक्षेप में कहा जा सकता है: "यदि आप नियतात्मक निर्माण नहीं चाहते हैं, तो एक उपकरण का उपयोग न करें ( pipenv ) जिसका उद्देश्य नियतात्मक निर्माण सुनिश्चित करना है" .

लेकिन यह निश्चित रूप से सामान्य रूप से एक वांछनीय लक्ष्य नहीं है।

@ tsiq-oliverc अच्छी गुंजाइश परिभाषा - यह केंद्रित चर्चा का समर्थन करता है। मैं एक और आवश्यकता जोड़ूंगा :

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

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

मुझे गलत मत समझो: गैर-निर्धारक बिल्ड चलाने की कोई इच्छा नहीं है, मेरी इच्छा सीआई बिल्ड चलाने की है, जो जितना संभव हो उतना मुद्दों का पता लगाएगा।

@vlcinsky निश्चित रूप से, मैं यह सुनिश्चित करने के लिए अपना अनुभव साझा करना चाहता था कि अद्यतन दस्तावेज इसे भी प्रतिबिंबित करता है। ट्रेडऑफ़ की व्याख्या करने के लिए वर्तमान दस्तावेज़ीकरण बहुत अच्छा काम करता है:

पुस्तकालयों के लिए, setup.py में install_requires के माध्यम से अमूर्त निर्भरता को परिभाषित करें। [...]
अनुप्रयोगों के लिए, निर्भरताओं को परिभाषित करें और उन्हें पिपफाइल में कहां प्राप्त करें और इस फ़ाइल का उपयोग पिपफाइल.लॉक में ठोस निर्भरताओं के सेट को अद्यतन करने के लिए करें। [...]
बेशक, पिपफाइल और पिपेनव अभी भी पुस्तकालय डेवलपर्स के लिए उपयोगी हैं, क्योंकि उनका उपयोग विकास या परीक्षण वातावरण को परिभाषित करने के लिए किया जा सकता है।
और, ज़ाहिर है, ऐसी परियोजनाएं हैं जिनके लिए पुस्तकालय और आवेदन के बीच का अंतर स्पष्ट नहीं है।

(उस भाग पर प्रकाश डाला जो मेरे मामले में लागू होता है।)

मैं बस यह सुनिश्चित करना चाहता हूं कि यह उसी तरह बना रहे। मुझे लगता है कि आपकी मूल पोस्ट में बिना किसी अस्वीकरण के बहुत सारे ब्लैंकेट स्टेटमेंट हैं कि आप एक ओपन-सोर्स प्रोजेक्ट के बारे में बात कर रहे हैं जो कि PyPI पर प्रकाशित होने जा रहा है।

@ मोरित्ज़ 9 0 मैं पूरी तरह सहमत हूं। मैं उस फोकस को हाइलाइट करने की कोशिश कर रहा था लेकिन मैं इसे और भी ज्यादा दृश्यमान बना सकता हूं।

@ Moritz90 मैंने आपकी टिप्पणी को दर्शाते हुए परिचयात्मक नोट जोड़ा।

@vlcinsky - यह समझ में आता है। मैं समझता हूं कि आप स्पष्ट रूप से गैर-नियतात्मक निर्माण नहीं चाहते हैं, लेकिन मुझे लगता है कि यह अनिवार्य रूप से आप जो चाहते हैं उसके बराबर है (यानी जब आपकी अपस्ट्रीम निर्भरता अपडेट होती है तो मुद्दों को पकड़ने के लिए)।

ज़ोर से सोचना, इन दो परस्पर विरोधी लक्ष्यों को हल करने का सबसे अच्छा तरीका क्या है? दो चरणों वाली सीआई प्रक्रिया होने की एक संभावना है:

1. नियतात्मक चरण। आपके रेपो में Pipfile.lock का लाभ उठाता है, इसलिए यह पूरी तरह से प्रतिलिपि प्रस्तुत करने योग्य है।
2. गैर-नियतात्मक चरण। pipenv update चलाता है और फिर परीक्षण चलाता है, ताकि यह आपकी सभी निर्भरताओं के नवीनतम में खींच सके (जो मूल रूप से बिना लॉकफाइल वाले व्यवहार के समान है, मुझे लगता है?)

@ tsiq-oliverc नियतात्मक निर्माण प्राप्त करने के लिए, मैं निम्नलिखित सेटअप के बारे में सोचूंगा:

• पीपीआई कैश जॉब बनाएं: एक बार एक बार चलाएं, कुछ प्रकार के पीपीआई इंडेक्स कैश का उत्पादन करें (फाइलों की निर्देशिका या कुछ भी समान)
• पुस्तकालय परीक्षण कार्य: पीपीआई कैश का उपयोग करना, लेकिन pipenv से बचना

संस्थापन करने के लिए pipenv का उपयोग करना पुस्तकालय को स्थापित करने के समान है लेकिन यह निश्चित रूप से अलग है क्योंकि यह काम करने वाला अलग कोड है।

पीपीआई कैश जॉब बनाएं

$ git clone <repo_url> <project_dir>
$ cd <project_dir>
$ pip install pipenv
$ $ # clean pypi cache and make it ready to cache somehow - not described here
$ pipenv install -e .[test]
$ # if we need extra testing packages in pipenv
$ pipenv install <extra_test_packages>
$ # record current requirements expressed in `Pipfile.lock`
$ pipenv lock
$ # if needed, record the `Pipfile.lock` somewhere

ऐसी नौकरी के आउटपुट हैं:

• Pipfile.lock रिकॉर्ड की गई निर्भरता के रूप में (डेवलपर्स को आसानी से पर्यावरण को पुन: पेश करने में मदद कर सकता है)
• पूर्व-आबादी स्थानीय pypi कैश

पुस्तकालय परीक्षण कार्य

चरण हैं:

• केवल हमारे स्थानीय pypi कैश का उपयोग करके tox , pip आदि को बाध्य करने के लिए पर्यावरण को कॉन्फ़िगर करें
• सीआई परीक्षण चलाएं ( pipenv का उपयोग करने से बचें)

हमें क्या मिलता है

• पुस्तकालय का परीक्षण नियतात्मक वातावरण में किया जाता है
• पुस्तकालय सहित परीक्षण किया जाता है। यह स्वयं को स्वयं स्थापित करने की क्षमता रखता है
• Pipfile.lock pypi संकुल को रिकॉर्ड करता है जिसका उपयोग पुस्तकालय को स्थापित करने के लिए किया गया था। इसका उपयोग डेवलपर साइट पर पर्यावरण को पुन: पेश करने के लिए किया जा सकता है।
• (संभवतः बाहरी) pypi पर अपग्रेड किए गए पैकेज के लिए अनुकूलन सरल है ("बिल्ड pypi कैश जॉब को फिर से चलाएँ) और नियंत्रित तरीके से किया जाता है (pypi की सामग्री को हैश सहित रिकॉर्ड किया जाता है)

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

क्या अभी भी गायब है (और किया जा सकता है)

पीपीआई कैश वह हिस्सा है जिसे कुछ शोध की आवश्यकता है। मुझे लगता है, साधारण निर्देशिका पर्याप्त होगी और शायद pipenv इसके लिए मदद के लिए पहले से ही तैयार है। शायद अंक #1731 गायब हिस्सा है।

एक पैकेज के रूप में जो निर्भरता समाधान करता है, हमारे अपने कई परीक्षण नियतात्मक निर्माण पर निर्भर करते हैं - अर्थात, ज्ञात सामग्री लेना और एक हल किए गए ग्राफ़ की अपेक्षा करना। हम इसके लिए pytest-pypi का उपयोग करते हैं।

इस विषय पर जीवंत चर्चा पसंद आई. मुझे लगता है कि बारीकियां महत्वपूर्ण हैं और आपको हमेशा ज्ञात निर्भरताओं के साथ-साथ अनपिन किए गए लोगों के खिलाफ परीक्षण करना चाहिए

आपको हमेशा ज्ञात निर्भरताओं के साथ-साथ अनपिन किए गए लोगों के खिलाफ परीक्षण करना चाहिए

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

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

@Moritz90 @techalchemy @uranusjr @tsiq-oliverc

पिछली चर्चा से मेरा सारांश यहां दिया गया है।

विशेष समस्याएं और प्रस्तावित समाधान

कई निष्पादन संदर्भ - Pipfile.lock फ़ाइल (फ़ाइलों) को कौन बनाए रखेगा?

प्रत्येक समर्थित ओएस और पायथन दुभाषिया संभावित निष्पादन संदर्भों के मैट्रिक्स में योगदान देता है।

जैसे फ्लास्क समर्थन करता है (रिपॉजिटरी में कम से कम सीआई सामान दिखाई देता है):

• ओएस विंडोज (पायथन 2.7 और पायथन 3.6)
• लिनक्स (अजगर 2.7, 3.4, 3.5, 3.6, रात्रिकालीन, पीपीआई)
• ओएसएक्स (पीई - सुनिश्चित नहीं है कि और संस्करण हैं या नहीं)

यह 9 अलग-अलग निष्पादन संदर्भ बनाता है जो भिन्न हो सकते हैं।

प्रत्येक निष्पादन संदर्भ में भिन्न Pipfile.lock ।

उनका रखरखाव कौन करेगा?

विकल्प हैं:

• डेवलपर्स को मैन्युअल रूप से ऐसा करने दें (कोई रास्ता नहीं)
• मुख्य विकास मंच के लिए केवल एक Pipfile.lock बनाए रखें (किस मंच को अनदेखा किया जाना पसंद है?)
• सीआई (हाँ) के माध्यम से स्वचालित निर्माण

प्रस्ताव: सीआई को pipenv install -e . द्वारा फाइल जेनरेट करने दें। इसे रेपो में शामिल न करें, स्वचालित बिल्ड के परिणामस्वरूप डेवलपर्स को उचित Pipfile.lock चुनने में मदद करें।

डेवलपर्स को पूर्वानुमेय वातावरण की आवश्यकता है

किसी समस्या को ठीक करते समय, जो pypi पर निर्भरता के परिवर्तन के कारण हो सकता है, डेवलपर को विफल परीक्षण से पर्यावरण को पुन: उत्पन्न करने के लिए सरल माध्यम की आवश्यकता हो सकती है।

प्रस्ताव:

• कई पैकेजों के लिए, पीपीआई निर्भरता परिवर्तन इतने दुर्लभ हैं कि वे वास्तविक समस्या नहीं हैं
• पर्यावरण को स्वयं ठीक करने के लिए, डेवलपर Pipfile.lock द्वारा pipenv install -e . उसके बाद pipenv lock उत्पन्न कर सकता है।
• विफल परीक्षण से पर्यावरण को दोहराने के लिए, डेवलपर विफल परीक्षण से Pipfile.lock ।
• टूडू: उदाहरण दिखाएं, Pipfile.lock में tox.ini कैसे लागू करें।

सीआई को टूटा हुआ setup.py प्रकट करना होगा

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

प्रस्ताव:

• सादे स्थापना के समान परिणाम प्रदान करने के लिए pipenv install -e . पर भरोसा करें (वर्तमान में इसके साथ कुछ समस्याएं हैं)।
• सादा स्थापना परीक्षण चलाएं (बिना pipenv ) और संभवतः तुलना करें कि परिणामी pip freeze आउटपुट pipenv द्वारा स्थापित किए गए सबसेट का सबसेट है।

अद्यतन pypi निर्भरता चीजों को तोड़ सकती है, CI ऐसे पीछा का पता लगाएगा

कुछ निर्भरता अद्यतन इसका उपयोग कर पुस्तकालय तोड़ सकते हैं। सीआई ऐसी समस्या पर विफलता का पता लगाएगा।

प्रस्ताव:

• अनपिन किए गए संस्करण के विरुद्ध कम से कम एक परीक्षण चलना चाहिए
• यदि CI हमेशा नया Pipfile.lock उत्पन्न करता है, तो यह गैर-मुद्दा है (जैसा कि हम वैसे भी अनपिन मोड में चलते हैं)

विभिन्न पुस्तकालय प्रकारों के लिए सीआई मोड

सभी प्रस्तावित मोड में मैंने pipenv फाइलों को रिपॉजिटरी सेविंग डेवलपर्स में रखने से बचने की कोशिश की, जो वास्तव में जटिल सामान (स्वचालन !!!) को बनाए रखने से बचते हैं।

मेरे मूल पाठ के विपरीत दूसरा और तीसरा मोड सीआई स्क्रिप्ट में pipenv का उपयोग करता है।

मोड: भागो, फॉरेस्ट, भागो!

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

बस pipenv युग से पहले की तरह दौड़ें और चीजों को हमारे लिए सरल रखें।

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

मोड: जेनरेट और सील

हर बार जब सीआई परीक्षण चलाया जाता है, तो नया Pipfile.lock उत्पन्न करें जो इस समय उपयोग किए गए पर्यावरण का पूरी तरह से वर्णन करता है।

Pipfile.lock CI आर्टिफैक्ट बन जाएगा।

अगर चीजें गलत हो जाती हैं, तो डेवलपर टूटे हुए निर्माण से Pipfile.lock चुन सकता है, इसे स्थानीय रूप से लागू कर सकता है और परीक्षण और फिक्सिंग कर सकता है।

अगर कोई तैनात करना चाहता है, तो पिछले सफल निर्माण से Pipfile.lock उपयोग किया जा सकता है।

मोड: हिमयुग

जब निर्भरता बदलना वास्तविक समस्या हो, तो सीआई एक बार में Pipfile.lock बनाएगा और इसे निश्चित अवधि (एक महीने?) के लिए उपयोग करता रहेगा।

यह सीआई सेटअप को और अधिक कठिन बनाता है, क्योंकि कम से कम दो अलग-अलग कार्य होने चाहिए (एक Pipfile.lock उत्पन्न करता है, दूसरा इसे लागू करने और परीक्षणों में उपयोग करने वाला)।

चेतावनी: Pipfile.lock इस समय भी अपडेट होना चाहिए, setup.py निर्भरता को बदलता है।

ध्यान दें, कि हिमयुग के लिए स्क्रैट को गिलहरी प्रकार के परीक्षण की आवश्यकता होती है जो जमे हुए स्थिति को अनदेखा करता है और अनपिन किए गए संस्करणों के विरुद्ध जांच करता है।

अंतिम शब्द

जैसा कि देखा गया है, नियतिवाद और जटिलता मोड द्वारा मोड में बढ़ती है।

मेरा प्रस्ताव होगा:

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

सभी लाभ कुछ न कुछ खर्च करते हैं।

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

@vlcinsky शीर्षक "मोड: जेनरेट और सील" के तहत, यह उल्लेख करना समझ में आता है कि अंतिम सफल Pipfile.lock हमेशा आसपास रखा जाना चाहिए, उदाहरण के लिए इसे जेनकिन्स आर्टिफैक्ट के रूप में घोषित करके। उस परिवर्तन के साथ, अधिकांश परियोजनाओं के लिए उस सेटअप की अनुशंसा करना ठीक रहेगा। @ Tsiq-oliverc की तरह, मैं पहले मोड की सिफारिश नहीं करूंगा।

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

@ tsiq-oliverc सामान्य पायथन पैकेज के विशाल बहुमत "रन, फॉरेस्ट, रन" मोड में हैं। मैंने इनमें से कुछ पैकेजों को tox और pytest , क्योंकि मुझे लगा कि यह पैकेज की गुणवत्ता में योगदान देगा और क्योंकि मेरे पास बिल्कुल स्पष्ट विचार था कि यह कैसे अच्छी तरह से किया जा सकता है।

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

मैं फ्लास्क परियोजना को क्या कहूंगा?

1. जब तक आपके पास कोई विकल्प न हो, डिफ़ॉल्ट रूप से सर्वोत्तम अभ्यास (पुनरुत्पादित बिल्ड) का पालन करें?
2. 9 Pipfile.lock फ़ाइलें जोड़ें और उन्हें अद्यतन करने के लिए नीति सेट करें?
3. ट्रैविस और एपवेयर के लिए रिफैक्टर सीआई स्क्रिप्ट हिमयुग मोड के बाद दो चरण तरीके से काम करने के लिए?
4. मामलों के लिए Pipfile.lock आर्टिफैक्ट उत्पन्न करने के लिए ट्रैविस और एपवेयर के लिए सीआई स्क्रिप्ट को संशोधित करें, जब किसी को अपने कंप्यूटर पर असफल परीक्षण को पुन: उत्पन्न करने की आवश्यकता होती है?
5. "फ्लास्क के लिए बहुत-बहुत धन्यवाद" के अलावा कोई टिप्पणी नहीं।

लक्ष्य कार्यात्मक कार्य शैली खोजना है। यदि यह डॉक्टर में समाप्त होता है, तो अच्छा है, यदि नहीं, तो कोई बात नहीं।

@vlcinsky मैं कहूंगा (1) और (4) ऐसी परियोजनाओं के लिए सिफारिश होनी चाहिए। जबकि पहले से मौजूद Pipfile.lock आप बिल्ड में उपयोग किए गए संस्करणों को पहले से नहीं जान पाएंगे (जो कॉर्पोरेट वातावरण के बाहर ठीक है), यदि आप लॉक फ़ाइल को जनरेट और संग्रहीत करते हैं तो भी आपको एक प्रतिलिपि प्रस्तुत करने योग्य परिणाम मिलेगा निर्माण के दौरान।

संपादित करें : मेरी सिफारिश का टीएल; डॉ संस्करण होगा:

• हमेशा सुनिश्चित करें कि आपके बिल्ड प्रतिलिपि प्रस्तुत करने योग्य हैं, भले ही आप लाइब्रेरी या एप्लिकेशन विकसित कर रहे हों। pipenv इस लक्ष्य को हासिल करने में आपकी मदद कर सकता है।
• यदि आप कोई एप्लिकेशन विकसित कर रहे हैं, तो अपने भंडार में Pipfile.lock प्रतिबद्ध करें और इसे परिनियोजन के लिए उपयोग करें। (यह पहले से ही मौजूदा दस्तावेज़ीकरण द्वारा कवर किया गया है।)
• यदि आप एक ओपन-सोर्स लाइब्रेरी विकसित कर रहे हैं, तो अपने CI बिल्ड में ऑन-द-फ्लाई Pipfile.lock जेनरेट करें और इसे बाद के लिए आर्काइव करें।
• यदि आप एक पुस्तकालय विकसित कर रहे हैं और एक प्रतिबंधित कॉर्पोरेट वातावरण में काम कर रहे हैं, तो उचित संख्या में लॉक फ़ाइलों को बनाए रखें और अपने सीआई बिल्ड में उनका उपयोग करें।

(बेशक, वास्तविक दस्तावेज में थोड़ा और विवरण और उदाहरण होना चाहिए।)

@ Moritz90 जैसा कि आपने प्रस्तावित किया था, मैंने "जेनरेट एंड सील" को संशोधित किया।

पुन (1): कहना आसान है, अधिक विशिष्ट होने के बिना निष्पादित करना असंभव है।

पुन (4): हाँ, मुझे यह भी लगता है कि "जेनरेट और सील" सबसे व्यवहार्य तरीका है। लेकिन फ्लास्क के मामले में मेरी हिम्मत नहीं होगी (कम से कम फिलहाल तो नहीं)।

एंटरप्राइज़ वातावरण में पहले से मौजूद Pipfile.lock : इसे किसी भी तरह (अर्ध) मैन्युअल रूप से या स्वचालित रूप से बनाया जाना है। मुझे लगता है, कॉर्पोरेट वातावरण में आप सीधे सार्वजनिक pypi से स्थापित नहीं करते हैं, लेकिन कुछ निजी का उपयोग करते हैं और जो केवल स्वीकृत पैकेज प्रदान करता है ( devpi-server उसमें बहुत अच्छी सेवा प्रदान करता है - कई अनुक्रमणिका, प्रकाशित पैकेजों की नियंत्रित अस्थिरता, बाहरी के लिए अनुमोदन पैकेज आदि) यदि Pipfile.lock के निर्माण की प्रक्रिया ऐसे वातावरण में चलती है, तो यह केवल वही उपयोग कर सकता है जो स्वीकृत है इसलिए यदि नया संस्करण वहाँ प्रदर्शित होना है, तो किसी को खड़ा होना होगा और इसे अनुमोदित करना होगा। सीआई बिल्ड के बाद यह परीक्षण करेगा कि यह चीजों को तोड़ता नहीं है। और pipenv check के साथ सुरक्षा मुद्दों का परीक्षण भी स्वचालित हो सकता है।

मुझे लगता है कि ऐसा वर्कफ़्लो किसी व्यक्ति द्वारा इसे (अर्ध) मैन्युअल रूप से बनाने की तुलना में अधिक सुरक्षित होगा। लेकिन उद्यम पर्यावरण के बारे में मेरा ज्ञान बहुत सीमित है।

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

मेरे पास निम्नलिखित संशोधन है जिस पर मैं चर्चा करना चाहता हूं:

हमारे आंतरिक पायथन पैकेज के लिए, पूरी तरह से पुन: प्रयोज्य, हमारे आंतरिक पीपीआई, आदि पर प्रकाशित, और यहां तक ​​​​कि मेरे अपने पायथन पैकेज (उदा: cfgtree , txrwlock , pipenv-to-requirements ) के लिए, मैं एक पैकेज का उपयोग करता हूं जिसे कुछ पहले से ही जानते हैं या यहां तक ​​​​कि उपयोग भी कर सकते हैं , जो इन विवरणों को सारगर्भित करता है और अजगर डेवलपर के जीवन को आसान बनाता है: PBR।
PBR मूल रूप से पढ़ता है requirements.txt में एक वितरण पैकेज के रूट फ़ोल्डर में और इसकी सुई पाया install_requires के setup.py । डेवलपर को केवल requirements.txt को ढीली निर्भरता घोषणाओं के साथ बनाए रखने की आवश्यकता है। जब तक Pipfile का समर्थन आधिकारिक तौर पर PBR के अंदर एकीकृत नहीं हो जाता, तब तक मुझे pipenv-to-requirements का उपयोग requirements.txt से Pipfile requirements.txt उत्पन्न करता है ताकि वे दोनों सिंक्रनाइज़ हों और दोनों प्रतिबद्ध हों स्रोत में, और वितरण पैकेज के निर्माण के बाद पीबीआर इंजेक्शन सही ढंग से करता है। मुझे लगता है कि एक इस्तेमाल कर सकते हैं pipenv उत्पन्न करने के लिए इस requirements.txt

मैं एक पर काम Pipfile के समर्थन PBR के लिए, इतना है कि यह पढ़ने के लिए सक्षम हो जाएगा Pipfile इसकी सुई में (और नहीं ताला फ़ाइल) और install_requires जैसे कि यह साथ करता है requirements.txt ।

मुझे नहीं पता कि अन्य समान पैकेज मौजूद हैं, क्योंकि यह अन्य चीजें भी करता है जो लोग नहीं चाहते हैं (गिट इतिहास से संस्करण, लेखकों की ऑटो पीढ़ी और चांगलॉग)।

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

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

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

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

टीम, आप दस्तावेज़ीकरण पर एक प्रकार के "समुदाय" अनुभाग के बारे में क्या सोचते हैं? ताकि मेरे जैसे उपयोगकर्ता अपना अनुभव साझा कर सकें कि वह पिपेनव का उपयोग कैसे करता है, बिना पिपेनव टीम के पूर्ण समर्थन के?

पुनश्च: यदि आप इस सूत्र को दूषित नहीं करना चाहते हैं तो मैं इसे एक समर्पित मुद्दे पर ले जा सकता हूं

@vlcinsky (1) निष्पादित करना बहुत आसान है - अपनी लॉकफाइल को अपने रेपो में रखें।

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

या इसे दूसरे तरीके से रखने के लिए, समाधान इस बात पर निर्भर करता है कि आप अपने सीआई वर्कफ़्लो को कौन सी अतिरिक्त गारंटी प्रदान करना चाहते हैं।

@gsemet आप जानते हैं क्या? पिछले दो वर्षों में बनाए गए मेरे सभी पायथन पैकेज pbr पर आधारित हैं - यह वास्तव में बहुत अच्छा है। और जब भी मैं कर सकता हूं, मैं पीबीआर में पिपफाइल का समर्थन करने के आपके प्रयासों का पालन करता हूं (कुछ अंगूठे ऊपर, वोट इत्यादि)।

इस मुद्दे के मामले में ( pipenv पैटर्न और सामान्य पायथन पुस्तकालयों के लिए एंटीपैटर्न की खोज) मैंने जानबूझकर दो कारणों से pbr छोड़ा:

• यह वैचारिक चर्चा को और अधिक जटिल बना देगा
• कुछ लोगों को अन्य कारणों से pbr पसंद नहीं है (आपने उनका उल्लेख किया है) और यह शायद चर्चा को दूर कर देगा

दूसरी ओर, मैं वास्तव में पीबीआर-प्रेमियों के लिए आपकी एक रेसिपी की प्रतीक्षा कर रहा हूँ। मुझे इसे पढ़ना है।

@ tsiq-oliverc आपने नाखून मारा: अपना लॉकफाइल

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

यदि आप मुझे एक रेपो दिखाते हैं, जहां यह ठीक से किया जाता है (सामान्य पायथन पुस्तकालय), मुझे खुशी होगी। या मैं दिखाऊंगा कि क्या जोखिम हैं या क्या चीजें अधूरी हैं।

ठंडा ! मैं इस कुकीकटर को भी बनाए रखता

@vlcinsky ठीक है, तो चलिए विशिष्ट समस्याओं की गणना करते हैं और उनके लिए समाधान

जैसा कि मैं बता सकता हूं, आपकी मूल पोस्ट में ये विशिष्ट लक्षण हैं:

• टूटी हुई setup.py निर्भरता को छिपाना। यह एक गैर-मुद्दे की तरह लगता है - pipenv install -e . , है ना?
• विभिन्न पायथन संस्करणों या किसी अन्य ओएस में निर्भरता अमान्य होने की संभावना है। मैं देख सकता हूं कि यह एक मुद्दा हो सकता है, लेकिन क्या आप एक ठोस उदाहरण प्रदान कर सकते हैं कि यह व्यवहार में कहां मायने रखता है? (लॉकफाइल के संदर्भ में)
• डेवलपर्स को अद्यतन करने के लिए मजबूर किया जाता है ... जब अन्य पुस्तकालय अद्यतन होते हैं और पुस्तकालय के भीतर प्रयोग योग्य हो सकते हैं। वे ऐसा करने के लिए n के बजाय संस्करण n+1 के विरुद्ध काम करती है। लेकिन ध्यान दें कि मैंने पहले ही एक विकल्प प्रस्तावित किया है जो दोनों दुनिया के सर्वश्रेष्ठ प्रदान करता है।
• Tox के साथ प्रतिस्पर्धा। मैं वास्तव में Tox के बारे में कुछ नहीं जानता। लेकिन हाँ, अपनी निर्भरता को प्रबंधित करने के लिए एक साथ दो उपकरणों का उपयोग करना आपदा के लिए एक नुस्खा की तरह लगता है। मैं कहूंगा कि उस विशेष कार्य के लिए जो भी श्रेष्ठ है उसका उपयोग करें।
• पिपेनव विफल रहता है। यह एक और गैर-मुद्दे की तरह लगता है - आप केवल पिपेनव के संस्करण को पिन कर सकते हैं (यह मेरा वर्तमान समाधान है, जैसे मैं अपनी डॉकर छवि, पिप का मेरा संस्करण इत्यादि) पिन करता हूं।

@ tsiq-oliverc मुझे कहना है, आपकी टिप्पणियों ने मुझे प्रेरित किया और मुझे पता है कि उन्होंने प्रस्तावित समाधान के उच्च स्तर के पुनरुत्पादन में योगदान दिया।

दोहराव सुनिश्चित करने के लिए लॉकफाइल ( Pipfile.lock ) को रेपो में डालने के आपके प्रस्ताव से निम्नलिखित संबंधित है:

टूटी हुई setup.py निर्भरता को फिर से pipenv install -e . जो मैं प्रस्तावित करता हूं उसका पालन करें, लेकिन ध्यान दें, यह Pipfile.lock का उपयोग नहीं है, यह इसे बनाने (पुनः) करने का तरीका है। अगर कोई Pipenv.lock रखता है और पैकेज को स्थापित करने से पहले वर्चुअलएन्व बनाने के लिए इसका इस्तेमाल करता है, तो समस्या मौजूद है।

विभिन्न पायथन संस्करणों या किसी अन्य ओएस में पुनः doit पुराना संस्करण होना चाहिए क्योंकि नया पायथन 2.x के लिए समर्थन छोड़ देता है। watchdog निर्भरता के लिए प्लेटफॉर्म पर निर्भर पुस्तकालयों की आवश्यकता होती है: लिनक्स पर इनोटिफाई, विंडोज पर कुछ और, ओएसएक्स पर कुछ और। मेरे पूर्व ग्राहक कहते थे "यह कभी नहीं होगा" और 50% स्थिति में यह 2 सप्ताह के भीतर हुआ। सीआई स्क्रिप्ट के लिए यह सबसे अच्छा अभ्यास नहीं है।

डेवलपर्स को अद्यतन करने के लिए मजबूर किया जाता है .. 15 योगदानकर्ताओं के साथ ओपन सोर्स लाइब्रेरी की कल्पना करें। एक नवागंतुक या थके हुए कोर डेवलपर द्वारा Pipfile.lock को पुनर्जीवित करना भूलना इतना आसान है। में उदाहरण के लिए maya पैकेज मैं पुनर्जीवित करने के लिए कहा गया था Pipfile.lock के रूप में नए निर्भरता को जोड़ा गया है setup.py । क्या यह जरूरी था? क्या मैंने इसे ठीक से अपडेट किया? क्या मैंने इसे समर्थित सभी निष्पादन संदर्भों के लिए अद्यतन किया था? उत्तर हैं नहीं, निश्चित नहीं, नहीं। वैसे भी, आपके प्रस्ताव के लिए धन्यवाद (इसने मुझे आपकी टिप्पणी के आगे वर्णित समाधान के लिए प्रेरित किया)।

टॉक्स के साथ फिर से टॉक्स कई वर्चुअलएन्व्स के निर्माण और उनके भीतर चल रहे परीक्षणों के स्वचालन की अनुमति देता है। विशिष्ट tox.ini अजगर 2.7, 3.4, 3.5, 3.6 और आपके लिए आवश्यक किसी भी अन्य वर्चुअलएन्व को परिभाषित करता है, और वहां पैकेज स्थापित करने और परीक्षण सूट चलाने की अनुमति देता है। यह गंभीर परीक्षकों का पावरटूल स्थापित है। pipenv इस उद्देश्य के लिए उपकरण नहीं है, लेकिन आवश्यक चीजों को स्थापित करने में हस्तक्षेप कर सकता है। एक तरह से मैंने आपकी सलाह का पालन किया और जहाँ संभव हो pipenv से अधिक बेहतर टूल (टॉक्स) का उपयोग करने का प्रस्ताव रखा।

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

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

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

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

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

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

@ मोरित्ज़90

स्ट्रॉमैन से मिलना

Pipfile.lock स्ट्रॉ मैन के रूप में काम करने वाले बहुत सारे वेरिएंट के बारे में (दूसरों को अपने क्षेत्र से दूर रखने के लिए):

फ्लास्क

मैंने flask प्रोजेक्ट लिया (इसे बहुत परिपक्व मानते हुए) और टॉक्स टेस्ट चलाए:

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

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

  coverage-report: commands succeeded
  docs-html: commands succeeded
  py27-devel: commands succeeded
  py27-lowest: commands succeeded
  py27-simplejson: commands succeeded
  py27: commands succeeded
  py35: commands succeeded
  py36-devel: commands succeeded
  py36-lowest: commands succeeded
  py36-simplejson: commands succeeded
  py36: commands succeeded
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy-devel: InterpreterNotFound: pypy
ERROR:   pypy-lowest: InterpreterNotFound: pypy
ERROR:   pypy-simplejson: InterpreterNotFound: pypy
ERROR:   pypy: InterpreterNotFound: pypy

बनाए गए प्रत्येक वर्चुअलएन्व के लिए मैंने requirements.txt फ़ाइल pip freeze > {venv_name}.txt द्वारा बनाई है

फिर फाइलों के लिए हैश की गणना की जाती है, हैश मानों के अनुसार क्रमबद्ध किया जाता है, इसलिए सभी को समूहीकृत किया जाएगा। यहाँ स्ट्रॉमैन आता है:

b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py35.txt
b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py36.txt
cdf69aa2a87ffd0291ea65265a7714cc8c417805d613701af7b22c8ff2b5c0e4  py27-devel.txt
dfe27df6451f10a825f4a82dfe5bd58bd91c7e515240e1b102ffe46b4c358cdf  py36-simplejson.txt
e48cd24ea944fc9d8472d989ef0094bf42eb55cc28d7b59ee00ddcbee66ea69f  py36-lowest.txt
f8c745d16a20390873d146ccb50cf5689deb01aad6d157b77be203b407e6195d  py36-devel.txt
053e107ac856bc8845a1c8095aff6737dfb5d7718b081432f7a67f2125dc87ef  docs-html.txt
45b90aa0885182b883b16cb61091f754b2d889036c94eae0f49953aa6435ece5  py27-simplejson.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
564580dad87c793c207a7cc6692554133e21a65fd4dd6fc964e5f819f9ab249c  py27.txt
8b8ff4633af0897652630903ba7155feee543a823e09ced63a14959b653a7340  py27-lowest.txt

एक डरावना, है ना? सभी परीक्षणों से, केवल दो समान जमे हुए निर्भरता साझा करते हैं।

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

जिंजा2

jinja2 जाँच करना, जो कि बहुत सरल जानवर लगता है:

  coverage-report: commands succeeded
  py26: commands succeeded
  py27: commands succeeded
  py33: commands succeeded
  py35: commands succeeded
  py36: commands succeeded
ERROR:   docs-html: commands failed
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy: InterpreterNotFound: pypy

चेकसम देखकर मुझे आश्चर्य हुआ कि py27.txt और py26.txt भिन्न हैं:

047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py26.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py33.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py35.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py36.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
743ad9e4b59d19e97284e9a5be7839e39e5c46f0b9653c39ef8ca89c7b0bc417  py27.txt

@vlcinsky यह वास्तव में डरावना है। मैं सोच रहा हूं कि क्या फ्लास्क एक विशेष मामला है या क्या यह वास्तव में आदर्श है, लेकिन आपने निश्चित रूप से मुझे गलत साबित कर दिया है।

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

@ Moritz90 आपकी आंतरिक लाइब्रेरी पूरी तरह से अलग दर्शकों की सेवा कर रही है ताकि आप निष्पादन संदर्भ को और अधिक संकीर्ण रख सकें।

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

फ्लास्क के tox.ini से परीक्षण और टॉक्स के बारे में बहुत कुछ सीखा जा सकता है

सबसे पुराने निर्भरता संस्करण के खिलाफ परीक्षण करने के लिए सबसे कम परीक्षण संस्करण ध्यान रखते हैं।

डेवेल कोर निर्भरता के विकास संस्करण के खिलाफ परीक्षण कर रहा है।

मैं कहूंगा, फ्लास्क जटिलता के उच्च स्तर पर है और सावधानीपूर्वक परीक्षण सूट प्रदर्शित करता है।

पिरामिड का tox.ini समान संख्या में वातावरण दिखाता है (उनका लक्ष्य 100% कोड कवरेज भी है)।

माया का tox.ini बहुत ताज़ा (2 दिन) और सरल है, यहां तक ​​कि यहां 4 अलग-अलग वातावरण हैं और py27 py35 और py36 से जमी हुई आवश्यकताओं में भिन्न है।

@ मोरित्ज़90
पिपेनव और टॉक्स के बीच गोंद के संबंध में

• pipenv --man कुछ निर्देश दिखाता है, pipenv भीतर tox.ini कमांड का उपयोग कैसे करें
• tox-pipenv कुछ अतिरिक्त एकीकरण प्रदान करने का प्रयास कर रहा है लेकिन यह इस समय मुझे भ्रमित कर रहा है।

tox.ini फ़ाइल मनमानी कमांड चलाने की अनुमति देती है, इसलिए इसमें pipenv ।

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

चूंकि हमें संभवतः Pipfile.lock जेनरेट करने की आवश्यकता है, इसे प्राप्त करने और उचित स्थान पर जाने के लिए कुछ अतिरिक्त प्रयास किए जाने चाहिए (उदाहरण के लिए निम्नलिखित परीक्षण द्वारा ओवरराइटिंग को रोकने के लिए .tox/py36/Pipfile.lock । यह संभव होगा, लेकिन कुछ सरलीकरण स्वागत होगा। शायद Pipfile स्थान के लिए पर्यावरण चर के साथ कुछ चाल इसे और भी आसान बना देगी।

@vlcinsky

• setup.py - अभी भी सुनिश्चित नहीं है कि मैं समस्या को समझता हूं। आप एक बार pipenv install -e . चलाते हैं ताकि setup.py को अब आपकी लॉकफाइल के माध्यम से ट्रैक किया जा सके। और फिर जब भी आप setup.py में नए पैकेज जोड़ते हैं तो pipenv install चलाएं।
• डेवलपर्स लॉकफाइल को अपडेट करना भूल रहे हैं - pipenv --deploy इसे पकड़ने के लिए डिज़ाइन किया गया है। इसे अपने सीआई में चलाएं!
• पिपेनव विफल रहता है - सहमत है, अगर उपकरण में बग हैं, तो वह बेकार है। लेकिन बग आमतौर पर ठीक हो जाते हैं। यह एक पूरे दर्शन को फेंकने का कारण नहीं है
• टॉक्स
  
  
  
  • यदि परीक्षण के प्रबंधन के लिए Tox अच्छा है, तो यह बहुत अच्छा है। यदि यह पैकेज और नियतात्मक निर्माण के प्रबंधन के लिए भी बहुत अच्छा है, तो यह और भी बेहतर है।
  
  
  • लेकिन अगर यह सच होता, तो पिपेनव के अस्तित्व में आने का कोई कारण नहीं होता। तो मैं केवल यह मान सकता हूं कि Tox के साथ किसी प्रकार की सीमा है।
  
  
  • ऊपर की तरह, आज दुनिया की स्थिति (अच्छे इंटरऑप की कमी) दर्शन को अस्वीकार करने के कारण की तरह नहीं लगती है।
  
  
• एकाधिक envs
  
  
  
  • यह स्पष्ट है कि यहां कम से कम कुछ विशेष मामले हैं, जैसे फ्लास्क।
  
  
  • मेरे पास एक बेहतर सुझाव नहीं है कि एकाधिक लॉकफाइल (हालांकि शायद इस संबंध में पिपेनव के लिए भविष्य की सुविधा है?)
  
  
  • लेकिन इस मामले में भी, मैं अभी भी आश्वस्त नहीं हूं कि कई लॉकफाइलों को प्रबंधित करना व्यवहार में एक मुद्दा है। सबसे खराब स्थिति, ऐसा लगता है कि आप स्थानीय रूप से एक साधारण स्क्रिप्ट update-all-lockfiles.sh बना सकते हैं, और त्रुटियों को पकड़ने के लिए अपने CI पर pipenv --deploy सकते हैं।
  
  

@ Moritz90 - सहमत, ज्यादातर मामलों में "दो चरण" दृष्टिकोण अधिक हो सकता है। विशेष रूप से, यदि आप अपने लॉकफाइल में जानबूझकर/जानबूझकर "मैनुअल" अपडेट कर रहे हैं, तो यह पूरी तरह से अनावश्यक है।

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

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

यदि Pipenv/Pipfile lib-dependencies , app-dependencies और dev-dependencies संभालने की अनुमति देता है तो प्रदान किया गया दस्तावेज उदाहरण @vlcinsky सरल और कम भ्रमित हो जाएगा। डॉक्स कुछ इस तरह दिख सकते हैं:

यदि आप पैकेज एक साझा पुस्तकालय है तो lib-dependencies विकल्प का उपयोग करें। उदाहरण Pipfile :

[lib-dependencies]
some-lib=="*"
another-lib=="*"
yet-another-one==">=1.0"

[dev-dependencies]
some-dev-tool=="1.1"

साझा पुस्तकालयों के लिए यह महत्वपूर्ण है कि संस्करण श्रेणियों को [lib-dependencies] तहत जितना संभव हो उतना चौड़ा रखा जाए, ताकि उपभोक्ता प्रणाली पर संस्करण विरोधों को रोका जा सके।

यदि आपका पैकेज एक एप्लिकेशन है (लक्षित सिस्टम पर pipenv द्वारा स्थापित किया जाना है) जिसके लिए सटीक निर्भरता संस्करणों की आवश्यकता है तो आपको [app-dependencies] विकल्प का उपयोग करना चाहिए। उदाहरण Pipfile :

[app-dependencies]
some-lib=="1.0.12"
another-lib=="1.*"
yet-another-one=="2.0"

[dev-dependencies]
some-dev-tool=="1.1"

/ अंत दस्तावेज़ उदाहरण

एक अन्य दृष्टिकोण Pipfile.lib और एक Pipfile.app ।

मुझे लगता है कि ऐसा कुछ अंतर को भरने के लिए एंटी-पैटर्न अनुभागों और तीसरे पक्ष के टूल के एक हिस्से की आवश्यकता को छोड़ देगा।

पिपेनव पैकेजिंग टूल को कॉल करना भ्रामक है यदि कोई यह उम्मीद करता है कि वह अजगर पुस्तकालय बना सकता है या उनके निर्माण में गहराई से शामिल हो सकता है।

मुझे लगता है कि यह एक वास्तविक समस्या है, जिससे बहुत भ्रम होता है। विशेष रूप से उन लोगों के बीच जो अन्य प्रोग्रामिंग भाषाओं (जैसे JS, Rust, Elm) में प्रबंधकों को पैकेज करने के लिए उपयोग किए जाते हैं। जब तक मुझे एहसास नहीं हुआ कि मैं Pipenv और setup.py का गलत तरीके से उपयोग कर रहा था, तब तक मुझे कई महीने और कभी-कभी GITHub मुद्दों को पढ़ने में लग गए।

@ फेलक्स

आपका [lib-dependencies] या Pipfile.lib वह है जो आज हमारे पास Pipfile (अमूर्त निर्भरता के रूप में - जितना संभव हो उतना चौड़ा)।

आपका [app-dependencies] या Pipfile.app वह है जो हमारे पास Pipfile.lock (विशिष्ट निर्भरता के रूप में) में है।

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

मुझे लगता है कि यह एक वास्तविक समस्या है, जिससे बहुत भ्रम होता है। विशेष रूप से उन लोगों के बीच जो अन्य प्रोग्रामिंग भाषाओं (जैसे JS, Rust, Elm) में प्रबंधकों को पैकेज करने के लिए उपयोग किए जाते हैं। जब तक मुझे एहसास नहीं हुआ कि मैं Pipenv और setup.py का गलत तरीके से उपयोग कर रहा था, तब तक मुझे कई महीने और कभी-कभी GITHub मुद्दों को पढ़ने में लग गए।

माना। तीन-खंड समाधान भी एक बहुत ही रोचक समाधान है जिसे मैंने कभी नहीं माना है, और यह सही और (आश्चर्यजनक रूप से!) सरल लगता है।

खुद एक पायथन पृष्ठभूमि से आते हुए, मैंने हमेशा महसूस किया है कि Node's package.json इसे गलत कर रहा है (जंग बेहतर है क्योंकि इसमें एक कंपाइलर और लिंकर है, और इसे बाद के चरण में हल कर सकता है)। ऐप और lib निर्भरताओं का इलाज उसी तरह से पाइथन जैसी स्क्रिप्टिंग भाषा के लिए काम नहीं करेगा, कम से कम एक अमूर्त अर्थ में-यानी यह आपके लिए काम कर सकता है, लेकिन पिपेनव जैसा सामान्य टूल ऐसा नहीं कर सकता क्योंकि इसे होना चाहिए सामान्य।

जबकि मुझे अवधारणा में तीन-खंड समाधान पसंद है, यह अभी भी मौजूदा पारिस्थितिकी तंत्र में एक असंगत परिवर्तन है। इस स्थान को भरने के लिए पहले से ही setup.py, setup.cfg, और (संभावित रूप से) pyproject.toml मौजूद हैं। यदि पिपेनव (पिपफाइल, सटीक होने के लिए) अंतरिक्ष में जाना चाहता है, तो उसे संबंधित परियोजनाओं के साथ समेकित करने की आवश्यकता है, जैसे कि पाइप (लाइब्रेरी समर्थन को आदर्श रूप से सीधे इसके द्वारा समर्थित होना चाहिए) और फ़्लिट ।

जैसा कि मैंने lib/app निर्भरता प्रबंधन के संबंध में अन्य मुद्दों में उल्लेख किया है, इस चर्चा को pypa-dev (मेलिंग सूची) और/या पीईपी प्रक्रिया में आगे बढ़ाने की आवश्यकता है, ताकि पिपेनव से पहले अन्य पार्टियों और संबंधित व्यक्तियों द्वारा इसे बेहतर ढंग से सुना जा सके। (पिपफाइल) किसी भी दिशा में जा सकता है।

@vlcinsky

आपकी [lib-निर्भरता] या Pipfile.lib वह है जो आज हमारे पास पिपफाइल में है (अमूर्त निर्भरता के रूप में - जितना संभव हो उतना चौड़ा)।

क्षमा करें यदि यह स्पष्ट नहीं था। मेरा lib-dependencies वही है जो लोग वर्तमान में setup.py / install_requires में डालते हैं। शायद pypi-dependencies मेरे मतलब के लिए एक बेहतर नाम होगा।

@uranusjr

इस स्थान को भरने के लिए पहले से ही setup.py, setup.cfg, और (संभावित रूप से) pyproject.toml मौजूद हैं।

पिपेनव (कमांड लाइन टूल) इंटरफेस कर सकता है setup.py । बस setup.py के डिपेंडेंसी सेक्शन को पिपफाइल में जाना होगा। कम से कम मेरी कल्पना में :)

जैसा कि मैंने lib/app निर्भरता प्रबंधन के संबंध में अन्य मुद्दों में उल्लेख किया है, इस चर्चा को pypa-dev (मेलिंग सूची) और/या पीईपी प्रक्रिया में आगे बढ़ाने की आवश्यकता है, ताकि पिपेनव से पहले अन्य पार्टियों और संबंधित व्यक्तियों द्वारा इसे बेहतर ढंग से सुना जा सके। (पिपफाइल) किसी भी दिशा में जा सकता है।

ठीक है, परेशान करने के लिए खेद है;) अगर मुझे कुछ समय मिलता है तो मैं मेलिंग सूची के लिए कुछ लिखूंगा।

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

@uranusjr - मैं "संकलित" पृष्ठभूमि से आया हूं, इसलिए मैं उत्सुक हूं कि ऐसा क्यों है?

ऐप और lib निर्भरताओं का इलाज उसी तरह पाइथन जैसी स्क्रिप्टिंग भाषा के लिए काम नहीं करेगा

@ tsiq-oliverc चूंकि ऐप के सर्वोत्तम अभ्यास के लिए आपको अपनी निर्भरताओं को पिन करने की आवश्यकता होती है, पुस्तकालय भी उन्हें पिन करना शुरू कर देंगे, यदि वे आवश्यकता फ़ाइलों के समान स्रोत का उपयोग करते हैं। इससे निर्भरता समाधान में समस्याएं पैदा होंगी।

मान लें कि मेरे ऐप में दो निर्भरताएँ A और B हैं, दोनों ही C पर निर्भर हैं, लेकिन A पिन v1, जबकि B पिन v2। संकलित भाषाएँ टूलचेन को संकलन समय पर इसका पता लगाने और इसे कई तरीकों से हल करने की अनुमति देती हैं। उदाहरण के लिए, रस्ट लिंकिंग समय के दौरान ऐसा करता है—अंतिम निष्पादन योग्य में C (v1 और v2) की दो प्रतियां होंगी, जिनमें से प्रत्येक के साथ A और B लिंक होंगे। सी ++ भूमि में इसे गतिशील पुस्तकालयों के साथ हल किया जाएगा; प्रतीक लुकअप बाद में भी किया जाता है (रनटाइम पर), लेकिन विचार वही है-संकलक जानता है कि आपको क्या चाहिए (आपके द्वारा उपयोग किए जाने वाले इंटरफ़ेस से), और तदनुसार कार्य कर सकता है।

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

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

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

@ tsiq-oliverc पीटर हिंटजेंस ने कहीं न कहीं "टिप्पणियों का पुल अनुरोध के रूप में स्वागत है" की अवधारणा लिखी है।

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

मैंने आपसे अजगर पुस्तकालय का एक उदाहरण मांगा, जहां pipenv ठीक से उपयोग किया जाता है (या कम से कम उपयोग किया जाता है) और आपने कोई प्रदान नहीं किया।

आप tox गुणों पर टिप्पणी करते हैं लेकिन स्वीकार करते हैं कि आप इससे परिचित नहीं हैं, फिर भी पाइथन पैकेज विकास की दुनिया में सर्वोत्तम प्रथाओं के बारे में कुछ दोहरा रहे हैं।

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

• पांडा : tox.ini: 6 envs
• बवंडर : tox.ini: 30 !! एनवीएस
• थेनो : .trafis.yml: 12 envs
• scipy : tox.ini: 4 envs
• zipline : .travis.yml: 2 envs
• tflearn : .travis.yml: 2 envs
• yowsup : tox.ini: 7 envs
• चुकंदर : tox.ini: 4 envs
• WERKZEUG : tox.ini: 8 envs
• paramiko : tox.ini: 6 envs
• docker -py : tox.ini: 6 envs
• तकिया : tox.ini : 4 परिवेश

परीक्षण चलाने के लिए वातावरण की वास्तविक संख्या अधिकतर 2 (+Windows) या 3 (+OSX) गुना अधिक होगी।

tox का उपयोग

परीक्षण करने के लिए वातावरण की संख्या अधिक है, फ्लास्क निश्चित रूप से सबसे जंगली नहीं है।

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

बस Pipfile.lock को एक भंडार में छोड़ना आसान है, लेकिन यह कोई जादू सुधार नहीं करता है (यदि हां, मुझे वास्तविक परिदृश्य दिखाएं, जब यह स्थिति में सुधार करेगा)।

हो सकता है कि आप "संकलित" दुनिया से सुनहरा नियम जानते हों और महसूस करते हों कि नियतत्ववाद (या दोहराव) भी पायथन के लिए बहुत जरूरी है। जैसा कि आप देखते हैं, वास्तव में कई पायथन परियोजनाएं इसके बिना रहती हैं, इसलिए हो सकता है कि सुनहरा नियम यहां इतनी सख्ती से लागू न हो।

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

उस लक्ष्य तक पहुँचने के लिए, मेरा दृष्टिकोण प्रश्नों पर पुनरावृति करना है:

• क्या मैं उपकरण का उपयोग करूंगा?
• कैसे?
• क्यों, मुझे क्या मूल्य मिला?
• क्या इसने कुछ समस्याएं पेश कीं? (अतिरिक्त कार्य, त्रुटियां छिपाई जा रही हैं...)

@ फेलक्स

क्षमा करें यदि यह स्पष्ट नहीं था। मेरी lib-निर्भरताएं वही हैं जो लोग वर्तमान में setup.py/install_requires में डालते हैं। हो सकता है कि मेरे मतलब के लिए pypi-निर्भरता एक बेहतर नाम होगा।

इस अंक में pbr चर्चा देखें। यह पिपफाइल द्वारा पुस्तकालय निर्भरता का समर्थन करने का प्रयास है।

मुझे लगता है, कि एक Pipfile उपयोग दो उद्देश्यों (lib और ऐप) के लिए नहीं किया जाएगा, ये चीजें अलग से की जाएंगी। यदि आपको लगता है कि इसकी वास्तव में आवश्यकता है, तो क्या आप इसका उपयोग करके किसी परियोजना के उद्देश्य का वर्णन कर सकते हैं? मैं आमतौर पर पुस्तकालय विकास और परिनियोजन परियोजनाओं को अलग रखने की कोशिश करता हूं क्योंकि उनका समय में काफी अलग उपयोग होता है।

@vlcinsky मुझे वास्तव में यकीन नहीं है कि आप इसे कहाँ ले जाना चाहते हैं (मुझे यकीन नहीं है कि आप किस प्रकार का पीआर मांग रहे हैं!), इसलिए मैं अभी के लिए इस बातचीत से बाहर निकलने जा रहा हूं।

मेरी स्थिति के टीएल; डीआर को पुन: स्थापित करने के लिए:

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

@uranusjr समझ गया। हालांकि मुझे नहीं लगता कि यहां कुछ भी भाषा-विशिष्ट है, यह केवल इतना है कि विभिन्न समुदायों ने बिना किसी सामान्य समाधान के किसी समस्या से निपटने के लिए अलग-अलग अनुमानों पर समझौता किया है - यदि आपके पास संस्करण संघर्ष हैं, तो आपको एक समस्या है।

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

@vlcinsky

इस अंक में pbr चर्चा देखें। यह पिपफाइल द्वारा पुस्तकालय निर्भरता का समर्थन करने का प्रयास है।

pbr अच्छा लगता है और सभी, लेकिन यह उस श्रेणी के अंतर्गत आता है जिसे मैं इसके साथ संबोधित करने का प्रयास कर रहा था:

मुझे लगता है कि ऐसा कुछ अंतर को भरने के लिए एंटी-पैटर्न अनुभागों और तीसरे पक्ष के टूल के एक हिस्से की आवश्यकता को छोड़ देगा।

मुझे लगता है कि ऐसे उपकरण पहली जगह में जरूरी नहीं होना चाहिए।

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

जब पीपीआई पैकेज की बात आती है, तो मैंने देव-निर्भरता को संभालने के लिए पिपेनव का उपयोग करना समाप्त कर दिया, Pipfile देव-निर्भरता का वर्णन करने के लिए, setup.py install_requires और setuptools साथ lib निर्भरताओं का वर्णन करने के लिए। setup.py चल रहे मेरे पैकेज को प्रकाशित करने के लिए pipenv run python setup.py bdist_wheel upload । यही मैं जटिल मानता हूं।

अन्य आधुनिक भाषाओं में मुझे एक कमांड लाइन टूल (पैकेज मैनेजर) और एक डिपेंडेंसी फाइल फॉर्मेट सीखना है। दस्तावेज़ीकरण एक ही स्थान पर है और पालन करना आसान है और एक नवागंतुक को यह सब कुछ घंटों में सुलझा लिया जाएगा। यह npm init , npm install foo --dev , npm publish । पिपेनव/पिपफाइल इसमें से अधिकांश पहले से ही कर सकता है, अगर यह सब कुछ कर सकता है, तो इस तरह के मुद्दे मौजूद नहीं होंगे।

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

पुनश्च: नए pypi में माइग्रेशन तैयार करने के लिए, आपको सुतली का उपयोग करना चाहिए न कि python setup.py अपलोड का। "अपलोड" का उपयोग एक एंटीपैटर्न के रूप में माना जाना चाहिए।

हो सकता है कि पिपेनव "प्रकाशित" कमांड विकसित कर सके?

@feluxe आप कविता पर एक नज़र डालना चाहेंगे। मैं बस इसके पार ठोकर खाता हूं और ऐसा लगता है कि आप यही खोज रहे हैं।

यह वही करता है जो pipenv करता है और ऐसा लगता है कि वे इसे विशेष रूप से निर्भरता प्रबंधन के संबंध में बेहतर करते हैं (कम से कम वे यही दिखाते हैं)। यह निर्भरता प्रबंधन, पैकेजिंग और सभी एकल टूल poetry प्रकाशन करता है।

मुझे आश्चर्य है कि क्या pipenv और poetry अंततः पायथन को एक सच्चा पैकेज मैनेजर देने के लिए प्रयास कर सकते हैं।

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

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

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

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

संपादित करें : क्षमा करें, मैंने उस पोस्ट को याद किया होगा जिसमें आपने पहली बार नई टिप्पणियों को पढ़ते समय ठीक वैसा ही किया था।

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

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

विषय पर वापस जाएं: पुस्तकालयों के लिए एक अलग फ़ाइल में निर्भरता को परिभाषित क्यों किया जाना चाहिए, इस बारे में @uranusjr की पोस्ट का हवाला देते हुए:

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

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

मैं अभी भी नहीं देखता कि पुस्तकालयों के लिए आधिकारिक सिफारिश क्यों नहीं हो सकती है कि उनके सीआई बिल्ड के लिए pipenv का उपयोग करें, लेकिन Pipfile.lock को स्रोत नियंत्रण से बाहर रखें। चूंकि, जैसा कि कुछ लोगों ने बताया, pipenv वर्तमान में पैकेजिंग प्रक्रिया से कोई लेना-देना नहीं है, इसलिए हमें आपके द्वारा ऊपर उल्लिखित समस्या का सामना नहीं करना चाहिए।

और मैं यह भी नहीं देखता कि यह आपकी अमूर्त निर्भरताओं को उसी फ़ाइल में परिभाषित करने के खिलाफ एक तर्क क्यों है जिसका उपयोग अनुप्रयोग उनकी अमूर्त निर्भरताओं को परिभाषित करने के लिए करते हैं। यह ठीक है अगर pipenv Pipfile को setup.py साथ एकीकृत करने के लिए एक विस्तृत समाधान लागू नहीं करना चाहता है, लेकिन मुझे नहीं लगता कि यह सामान्य रूप से एक बुरा विचार क्यों है।

@vlcinsky

मुझे लगता है, कि एक पिपफाइल का उपयोग दो उद्देश्यों (lib और ऐप) के लिए नहीं किया जाएगा, ये चीजें अलग से की जाएंगी।

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

ध्यान दें कि मैं पहले ही सहमत हूं कि Pipfile.lock पुस्तकालयों के लिए स्रोत नियंत्रण में नहीं होना चाहिए जब तक कि आप उसी स्थिति में न हों जिसमें मैं हूं।

संपादित करें : साथ ही, अगर यह पता चलता है कि pipenv को वास्तव में अंतर के बारे में जानने की जरूरत है, तो आप app-dependencies और lib-dependencies शुरू करने से पहले कार्गो के crate-type फ़ील्ड की तरह कुछ पेश कर सकते हैं lib-dependencies - यह अत्यधिक जटिल लगता है।

@ Moritz90 इस चर्चा को आयोजित करने के लिए पायथन की कई मेलिंग सूचियाँ अच्छी जगह होंगी।

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

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

@tsiq-oliverc

पीआर से मेरा मतलब है: अपनी अवधारणा को व्यवहार्य साबित करने वाला एक उदाहरण दिखाएं।

तो कुछ मौजूदा पुस्तकालय उठाओ, इसे फोर्क करें, अपना (1) लागू करें - आप कहते हैं कि यह pipenv साथ आसान होगा और मुझे दिखाओ। मैंने बहुत कोशिश की और मुश्किलें आईं।

यदि आपके (2) का अर्थ है "किसी और को काम करना है", तो आपका पीआर मौजूद नहीं होगा।

(3) में आप कोई वास्तविक संख्या दिए बिना "मामलों के छोटे उपसमुच्चय" के बारे में बात करते हैं। क्या वर्चुअलएन्व की संख्या के संबंध में वर्णित सभी शीर्ष पुस्तकालय "छोटा सबसेट" माना जाता है?

इस चर्चा को समाप्त करने के लिए, मैंने चर्चा के दौरान जो पाया उसका संक्षिप्त सारांश बनाया।

फोकस: अजगर पुस्तकालयों और अनुप्रयोगों के लिए pipenv (विरोधी) पैटर्न

मैंने फोकस को थोड़ा बदल दिया: यह न केवल (सामान्य) पायथन पुस्तकालयों के बारे में बात करता है, बल्कि अनुप्रयोगों के बारे में भी बात करता है क्योंकि इसे शामिल करना सस्ता था और यह मतभेदों को अच्छी तरह से प्रदर्शित करता है।

मैंने जानबूझकर मौजूदा टूलिंग में परिवर्तन का प्रस्ताव देने वाली किसी भी चीज़ को बाहर रखा है जैसे pipenv , tox आदि।

pipenv क्या है और यह क्या नहीं है

• यह परिनियोजन उपकरण है, जो Pipfile.lock माध्यम से ठोस निर्भरता को परिभाषित करने और लागू करने की अनुमति देता है।
• यह वर्चुअलएन्व प्रबंधन उपकरण है।
• यह अजगर पैकेज उत्पन्न करने के अर्थ में पैकेजिंग उपकरण नहीं है।

पुस्तकालय और अनुप्रयोग

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

व्यक्तिगत रूप से मुझे लगता है, यहां तक ​​​​कि "उद्यम पुस्तकालय" भी पुस्तकालय श्रेणी में आते हैं (समान नियम लागू होते हैं, केवल निष्पादन संदर्भों की संख्या छोटी होती है)।

सॉफ्टवेयर उत्पादों के प्रकार

• पुस्तकालय: किसी अन्य उत्पाद (लाइब्रेरी या एप्लिकेशन) में उपयोग करने के लिए
• आवेदन: तैनात और चलाने के लिए

स्थापना के तरीके:

• पुस्तकालय: pipenv install <package> इस प्रकार "पैकेज को खेलने में प्राप्त करें (आसपास के अन्य पुस्तकालयों के लिए संस्करणों को हल करना)"
• आवेदन: pipenv sync इस प्रकार "ठोस निर्भरता लागू करें"

सार और ठोस निर्भरता

सॉफ्टवेयर उत्पाद निर्भरता

• अमूर्त निर्भरताएँ: प्रयुक्त पुस्तकालयों का नाम होना चाहिए, संस्करणों या उपयोग को प्रतिबंधित कर सकता है, लेकिन पर्याप्त लचीला रहना चाहिए (संस्करणों को पिन नहीं करना चाहिए)

• ठोस निर्भरता: संस्करणों को पिन करना चाहिए, आदर्श रूप से प्रयुक्त पुस्तकालयों के हैश के साथ

  pipenv कलाकृतियाँ:

• Pipfile : अमूर्त निर्भरता

• Pipfile.lock : ठोस (बंद) निर्भरता"

निष्पादन संदर्भ

विभिन्न निष्पादन संदर्भों की विशिष्ट संख्या

• पुस्तकालय:
  
  
  
  • एक ओएस पर पायथन वर्चुअलएन्व: 3 से 9 (30 का उपयोग कर बवंडर)
  
  
  • ओएस की संख्या: 1 से 3 (लिनक्स, ओएसएक्स, विंडोज़)
  
  
  • कुल संख्या: 3 से 18
  
  
• आवेदन:
  
  
  
  • एक ओएस पर पायथन वर्चुअलएन्व: 1
  
  
  • ओएस की संख्या: 1
  
  
  • कुल संख्या: 1 (या बहुत कम)
  
  

सीआई लक्ष्य, प्राथमिकताएं और नियतिवाद

सीआई लक्ष्य

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

कार्यक्षमता के संबंध में विशेष सीआई लक्ष्य:

• पुस्तकालय:
  
  
  
  • पुस्तकालय द्वारा घोषित अमूर्त निर्भरताएँ पूर्ण हैं और इसमें सभी आवश्यक प्रतिबंध शामिल हैं (केवल जहाँ आवश्यक हो): पुस्तकालय स्वयं को ठीक से स्थापित करता है
  
  
  • सभी अपेक्षित उपयोग के मामले ठीक से काम करते हैं
  
  
• आवेदन:
  
  
  
  • ठोस निर्भरताएं पूर्ण हैं और सभी को पिन किया गया है, सर्वोत्तम सहित। हैश: एप्लिकेशन ठीक से इंस्टॉल हो जाता है
  
  
  • सभी अपेक्षित उपयोग के मामले ठीक से काम करते हैं
  
  

विभिन्न सीआई परीक्षण मोड

• मोड: "भागो, फॉरेस्ट, भागो"
  
  
  
  • आजकल अधिकांश पायथन पुस्तकालयों का परीक्षण इस तरह से किया जाता है।
  
  
  • tox या समान परीक्षण SW . का उपयोग करें
  
  
  • pipenv और ठोस निर्भरता का कोई उपयोग नहीं (पुस्तकालयों के लिए ठीक हो सकता है)
  
  
• मोड: "उत्पन्न और सील"
  
  
  
  • भंडार में कोई Pipfile
  
  
  • Pipfile.lock pipenv install -e . द्वारा बनाया गया
  
  
  • Pipfile.lock पर्यावरण के दस्तावेज़ (सील) और मुद्दों के विश्लेषण के लिए वर्चुअलएन्व के बाद के पुनरुत्पादन की अनुमति देता है।
  
  

• मोड: "हिम युग"

  • दो चरण परीक्षण
    
    
    
    • जब अमूर्त निर्भरता ( setup.py install_requires भीतर परिभाषित) pypi पर परिवर्तन या आश्रित पैकेज को अद्यतन किया जाता है, तो Pipfile.lock को pipenv install -e . द्वारा पुन: उत्पन्न करें
    
    
  • फंक्शन टेस्ट रन: लाइब्रेरी कोड बदलने पर रन करें। pipenv sync Pipfile.lock द्वारा बनाए गए वर्चुअलएन्व के भीतर चलाया जाता है
    

    Pipfile.lock कैसे और किसके द्वारा बनाया जा सकता है

• डेवलपर द्वारा मैन्युअल रूप से (अनुप्रयोगों के लिए काम कर सकता है)

• सीआई बिल्ड द्वारा स्वचालित रूप से (और सभी परीक्षणों को पास करके, इसे सत्यापित आर्टिफैक्ट घोषित करें)

नियतत्ववाद बनाम लचीलेपन की प्राथमिकता

• पुस्तकालय: लचीलापन (जब भी संभव हो चलाएं)

• आवेदन: नियतत्ववाद (चयनित निष्पादन संदर्भ में ठीक उसी तरह से चलाएँ)

  स्थापित उत्पाद के नियतत्ववाद को क्या प्रभावित कर सकता है:

• सार्वजनिक पीपीआई (कम नियतत्ववाद, पैकेज किसी भी समय अपडेट किए जाते हैं)

• निजी पीपीआई (उच्च नियतत्ववाद, पैकेज अपडेट नियंत्रित किया जा सकता है)
• पुस्तकालयों के भीतर अमूर्त आवश्यकताएं (नियतत्ववाद के लिए उपयोग नहीं की जाएंगी)
• ठोस आवश्यकताएं ( Pipfile.lock ): कुल नियतत्ववाद

विविध

कुछ मामलों का उपयोग Pipfile.lock :

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

• उत्पादन में आवेदन तैनात करें

  अन्य संकेत

• pbr पुस्तकालय requirements.txt माध्यम से अमूर्त पुस्तकालय निर्भरताओं की परिभाषा की अनुमति देता है। Pipfile पढ़ने का अपडेट जारी है।

• poetry पैकेज pyenv समान कुछ कोशिश करता है

  सामान्य मुद्दे

• "लॉकफाइल को रेपो में ड्रॉप करें" और आपको नियतात्मक बिल्ड मिलते हैं:

  • अनुप्रयोगों के लिए काम करेगा।
  • पुस्तकालयों के लिए काम नहीं करेगा, क्योंकि वास्तव में कई निष्पादन संदर्भ हैं और प्रत्येक के पास अलग-अलग Pipfile.lock परिणाम देने की अच्छी क्षमता है। गंभीरता से: flask इसके 11 अलग-अलग वर्चुअल एनवीएस (एक ओएस पर) 10 अलग-अलग लॉक निर्भरताओं पर दिखाता है। उन्हें बनाने और प्रतिबद्ध करने वाला कौन है?
  • ध्यान दें, कि "जेनरेट और सील" सीआई मोड के साथ, आप अभी भी Pipfile.lock (लेकिन सीआई स्क्रिप्ट द्वारा उत्पन्न) प्राप्त कर सकते हैं जिससे वर्चुअलएन्व को कहीं और पुन: उत्पन्न करने की इजाजत मिलती है।
• Pipfile.lock पुस्तकालय भंडार में
  
  
  
  • यदि वर्चुअलएन्व बनाने के लिए उपयोग किया जाता है, तो यह setup.py भीतर पुस्तकालय निर्भरताओं की टूटी हुई परिभाषा छुपा सकता है।
  
  
• Pipfile पुस्तकालय भंडार में
  
  
  
  • यदि यह अमूर्त निर्भरताओं को दोहराता है (जिसे setup.py भीतर परिभाषित किया जाना है), यह टूटी हुई setup.py निर्भरता घोषणा को छुपा सकता है।
  
  
  • अनुशंसित: Pipfile द्वारा pipenv install -e . या pipenv install -e .[tests] उत्पन्न करें यदि आपको परीक्षण निर्भरता की भी आवश्यकता है और उन्हें setup.py में "परीक्षण" अतिरिक्त के रूप में घोषित किया गया है
  
  
• सीआई स्क्रिप्ट में pipenv install <something> जोड़ना
  
  
  
  • यह अपने आप में नियतत्ववाद में बहुत सुधार नहीं करता है
  
  
  • "जेनरेट और सील" सीआई मोड देखें (फिर वर्चुअलएन्व में सभी इंस्टॉलेशन pipenv माध्यम से जाना चाहिए)।
  
  

निष्कर्ष

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

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

आगे क्या करना है?

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

बहुत प्रेरक चर्चा के लिए सभी का धन्यवाद - मुझे एक संदेश के रूप में लगता है "मैं इस विषय में पूरी तरह से खो गया हूं" तीन बार रिफैक्ट किया गया - इसका मतलब है कि स्वाभाविक रूप से हम बेहतर हो गए।

@vlcinsky poetry के साथ कोई संबंध नहीं है pyenv । यह बहुत कुछ pipenv जैसा है (लेकिन पुस्तकालयों और अनुप्रयोगों के प्रबंधन के संबंध में बहुत बेहतर कार्यान्वयन के साथ, IMO) लेकिन पैकेजिंग और प्रकाशन भाग के साथ।

आपके पास एक pyproject.toml फ़ाइल है जो आपकी परियोजना और उसकी निर्भरता (अमूर्त निर्भरता) और एक pyproject.lock को परिभाषित करती है जो पिन की गई निर्भरताओं का वर्णन करती है और किसी भी पायथन संस्करण और pyproject.toml प्लेटफॉर्म के लिए पिन की जाती है। pipenv का सामना करने वाली समस्याओं से बचने के लिए फ़ाइल ने केवल एक नियतात्मक लॉक फ़ाइल रखने के लिए निर्दिष्ट किया है। केवल इंस्टॉल करते समय, poetry यह जांच करेगा कि कौन से पैकेज को पर्यावरण के खिलाफ जांच कर स्थापित करना है।

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

इसका लाभ यह है कि यह पुस्तकालयों के लिए अमूर्त निर्भरता और अनुप्रयोगों के लिए लॉक फ़ाइल का उपयोग करेगा। यह दोनों दुनियाओं में सबसे अच्छा है।

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

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

@techalchemy मैं कुछ भी नहीं बेच रहा हूं, वास्तव में, मैं केवल उन विचारों की ओर निर्देशित कर रहा हूं जिनका उपयोग pipenv में किया जा सकता है।

और poetry निर्भरता को pyproject.lock में पिन करता है, ठीक उसी तरह जैसे pipenv Pipfile.lock । तो आपके पास pipenv तरह ही पुनरुत्पादन है। यदि आपके पास लॉक फ़ाइल है तो इसका उपयोग किया जाएगा और पिन की गई निर्भरता स्थापित की जाएगी और यदि मैं गलत नहीं हूं तो यह भी pipenv करता है।

अमूर्त निर्भरता का उपयोग करने का एकमात्र समय यह है कि जब यह वितरण के लिए परियोजना को पैकेज करता है (इसलिए मूल रूप से पुस्तकालयों के लिए) क्योंकि इस मामले में आप पिन की गई निर्भरता नहीं चाहते हैं।

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

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

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

@uranusjr हां, मुझे लगता है कि कुछ चीजों को स्पष्ट किया गया था और व्यापक दर्शकों के साथ साझा करने लायक है। आपकी सहायता का वास्तव में स्वागत है।

"जोड़ी प्रलेखन प्रारूपण" के बारे में क्या? मुझे लगता है कि इस समय केवल दो व्यक्तियों के छोटे पैमाने पर इस पर काम करना सबसे प्रभावी होगा।

करने के लिए सोचता है (संभवतः एक या दो पुनरावृत्तियों के साथ):

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

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

अगले कार्यों पर सहमत होने के लिए मैं आपसे ई-मेल द्वारा संपर्क करूंगा।

@vlcinsky इसके अलावा यदि आप रीयलटाइम इंटरैक्शन पसंद करते हैं तो मैं PySlackers (एक स्लैक वर्कस्पेस) पर @uranusjr रूप में उपलब्ध हूं। पिपेनव का वहां एक चैनल है ( #pipenv )।

@uranusjr प्रयास इकट्ठा करने से मेरा यही मतलब था। पायथन को कार्गो जैसे अच्छे पैकेज मैनेजर की सख्त जरूरत है। चीजों को करने के लिए एक मानक तरीके की कमी के कारण अन्य भाषाओं की तुलना में पायथन पारिस्थितिकी तंत्र फीका पड़ जाता है। और pipenv इससे कोई मदद नहीं मिलेगी, मुझे लगता है।

मुझे जो परेशान करता है वह यह है कि pipenv खुद को the officially recommended Python packaging tool रूप में विज्ञापित करता है, जबकि यह पैकेजिंग टूल नहीं है, इससे बहुत दूर है, जो उपयोगकर्ताओं के लिए भ्रामक है। यह वर्चुअलएन्व मैनेजर के साथ केवल एक निर्भरता प्रबंधक है।

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

और यहाँ pipenv का दोष है, यह सिर्फ पानी को गंदा करता है क्योंकि लोग अब भी requirements.txt बनाम setup.py साथ पहले की तरह ही गलतियाँ करेंगे। परियोजनाओं को अभी भी बुरी तरह से परिभाषित निर्भरताओं के साथ उनके setup.py में बुरी तरह से पैक किया जाएगा। कार्गो जैसी परियोजनाओं ने सही किया: वे एक निरंतरता सुनिश्चित करने के लिए विकासशील परियोजनाओं/अनुप्रयोगों के सभी पहलुओं को संभालते हैं जबकि pipenv जैसी परियोजना नहीं करती है।

और जब आप कहते हैं:

जो पिपेनव और कविता दोनों करते हैं (और न ही पूरी तरह से)

आपका क्या मतलब है? मैंने जो देखा है, उसका निर्भरता प्रबंधक pipenv द्वारा प्रदान किए गए की तुलना में बहुत अधिक लचीला है। केवल नकारात्मक पक्ष यह है कि वे PyPI JSON API का उपयोग करते हैं जिसमें कभी-कभी बुरी तरह से प्रकाशित पैकेजों के कारण निर्भरता की जानकारी नहीं होती है।

वैसे भी, मुझे लगता है, जैसा आपने कहा, कि दोनों परियोजनाएं एक दूसरे से सीख सकती हैं।

और, एक और बात, पिपेनव का भविष्य क्या है, अगर, अंततः, पाइप Pipfile संभालता है? क्या यह सिर्फ वर्चुअलएन्व मैनेजर होगा?

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

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

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

दिन के अंत में pip _will_ हैंडल pipfiles, यही योजना है, प्रारूप बनने के बाद से यह योजना रही है। लेकिन यह पूछने जैसा ही है 'लेकिन क्या होगा जब पाइप आवश्यकताओं की फाइलों को संभाल सकता है?' प्रश्न मूल रूप से समान है। पिप उस प्रारूप को स्थापित कर सकता है। यह वास्तव में मेरे द्वारा वर्णित किसी भी कार्यक्षमता के लिए प्रासंगिक नहीं है, इसके अलावा हम फाइलें भी स्थापित करते हैं (पीआईपी का उपयोग करके, वैसे)।

@techalchemy

वेयरहाउस जेसन एपीआई सबसे हालिया निर्भरता पोस्ट करता है भले ही आप पुराने संस्करण से निपट रहे हों, और ऐसा है कि इसमें वह जानकारी है

यह सिर्फ सादा गलत है, आप https://pypi.org/pypi/{project}/{release}/json कॉल करके एक विशिष्ट संस्करण निर्भरता प्राप्त कर सकते हैं। यदि आप केवल https://pypi.org/pypi/{project}/json कॉल करते हैं, तो सुनिश्चित करें कि आपको केवल अंतिम निर्भरताएँ ही मिलेंगी, लेकिन आप वास्तव में निर्भरता का सही सेट प्राप्त कर सकते हैं।

और अजगर परियोजनाओं के पैकेजिंग/प्रकाशन भाग में वास्तव में सुधार करने की आवश्यकता है क्योंकि अंत में यह सभी को लाभान्वित करेगा, क्योंकि यह JSON API का मज़बूती से उपयोग करना संभव बना देगा।

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

और ऐसा ही करता है poetry । और आप इसे pipenv (पाइप-टूल्स का उपयोग करके) के समान रिज़ॉल्यूशन विधि का उपयोग प्रदान करने के लिए JSON API का उपयोग नहीं कर सकते हैं। देखें https://github.com/sdispater/poetry/issues/37#issuecomment -379071989 और यह अभी भी pipenv से अधिक लचीला होगा (https://github.com/sdispater/poetry#dependency-resolution )

@zface मैं इसे अंतिम बार कहूंगा, कृपया इसे पदानुक्रम में कहीं अधिक ले जाएं। पिपेनव आधिकारिक तौर पर अनुशंसित पायथन पैकेजिंग टूल होने का स्व-घोषणा नहीं करता है; यह कहता है क्योंकि यह है । यदि आपको लगता है कि यह अनुचित है, तो पिपेनव की सिफारिश करने वाले अधिकारियों को बताएं । कृपया इन बातों को पिपेनव देव पर न डालें। शिकायत करने के लिए यह गलत जगह है, और आप यहां अपनी शिकायतों का समाधान प्राप्त नहीं कर सकते। आप अपने पास मौजूद तकनीकी प्रश्नों के बेहतर उत्तर भी प्राप्त कर सकते हैं। यह पिपेनव के लिए एक मुद्दा ट्रैकर है, न कि पायथन पैकेजिंग टूल्स के लिए एक चर्चा बोर्ड और पायथन पैकेजिंग कैसे की जाती है।

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

यह सिर्फ सादा गलत है,

इस तरह के रवैये का यहां स्वागत नहीं है। यह मत समझो कि हम समझ नहीं पा रहे हैं कि हम किस बारे में बात कर रहे हैं। कृपया शिष्टाचार का अभ्यास करें।

यह अभी भी पिपेनव से अधिक लचीला होगा (https://github.com/sdispater/poetry#dependency-resolution)

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

मैं मानता हूं कि चर्चा विषय से परे है, जो पिपेनव के आसपास "अच्छे प्रथाओं" को भुनाने की कोशिश कर रही थी।

तथापि,

[...] अभी भी वही गलतियाँ करेगा जो पहले आवश्यकताएँ.txt बनाम setup.py के साथ की गई थीं। इस वजह से उनके setup.py में बुरी तरह से परिभाषित निर्भरता के साथ परियोजनाओं को अभी भी बुरी तरह से पैक किया जाएगा।

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

और पिपेनव (और शायद कविता) एक बहुत अच्छा कदम है।

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

उनका सिर्फ बात यह है कि करता है निकालने का एक तरीका होना चाहिए requirements.txt/Pipfile ऐसे PBR रूप libs से 'आसान setup.py', एक Pipfile अवगत आवरण arround का एक प्रकार का प्रस्ताव करने के install_requires के बिना, सभी अवांछित व्यवहार pbr लाता है, और पैकेज करता है कि एक समर्पित setuptools आवरण में जो केवल वही करता है।

इसलिए हम प्रत्येक दुनिया को बेहतर बनाने में सक्षम होंगे:

• pipenv Pipfile बनाए रखने के लिए (पुस्तकालयों और अनुप्रयोगों दोनों में संस्करणित)
• pipenv Pipfile.lock बनाए रखने के लिए (केवल अनुप्रयोगों के लिए संस्करण)
• एक पैकेज आवरण इस जादू (प्रयोग करेंगे pipfile_setuptools , install_requires_pipfile ?) है कि एक प्रथम स्तर निर्भरता जो काम केवल इंजेक्षन करने के लिए है हो सकता है Pipfile में install_requires ।

यह एक और प्रोजेक्ट है जो pipenv से संबंधित नहीं होगा, लेकिन फिर भी एक सामान्य Pipfile पार्सर लाइब्रेरी की आवश्यकता है। तुम क्या सोचते हो?

मेरी समझ Pypa से @gsemet को भरने के लिए है कि pyproject.toml साथ बजाय, के नेतृत्व में कोशिश कर रहा है उड़ जाना । पिपफाइल को स्रोत प्रारूप के रूप में उपयोग करने के लिए आगे बढ़ने से पहले आपको इस बारे में पहले उनसे (पाइपा-देव या डिस्टुटिल्स-सिग पर) बात करनी होगी। Pipfile (और लॉक फ़ाइल) को पार्स करने के लिए, जिसे pypa/pipfile (जो Pipenv विक्रेताओं को कोर पार्सिंग लॉजिक प्रदान करने के लिए) में नियंत्रित किया जाता है।

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

मुझे स्वीकार करना होगा कि मैं pyproject.toml में घोषित निर्भरता को देखकर थोड़ा दुखी हूं (जो पीबीआर द्वारा की गई setup.cfg रूप में भूमिकाएं लेता है), जबकि पीपीए Pipfile का भी समर्थन करता है ....

पॉइंटर को फ़्लिट करने और पाइपफाइल करने के लिए धन्यवाद। वहाँ भी Kennethreitz की है pipenvlib कि हल्का लगता है।

PBR का setup.cfg आधिकारिक दस्तावेज़ीकरण की तुलना में अधिक पूर्ण लगता है (उदा: data_files ) और पहले से साझा की गई फ़ाइल को कई टूल (flake8, pytest, ...) एक अजगर परियोजना की जड़ में फ़ाइल)