पायथन 3 विकास और वितरण चुनौतियां

Question

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

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

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

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

वितरण पैकेजिंग के लिए, अधिक विकल्पों में से चुनने के लिए कर रहे हैं:, अजगर 2 के लिए एक उपयुक्त और अजगर 3 के लिए एक उपयुक्त

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

फिर से मैं वर्तमान में यहां विकल्प 3 की तरफ झुका रहा हूं, हालांकि मैंने अभी तक इस तरह के स्टब लोडर को विकसित करने की कोशिश नहीं की है।

कोई अन्य विचार?

Answer 1

संपादित करें: मेरा मूल उत्तर 200 9 की स्थिति पर आधारित था, जिसमें पाइथन 2.6 और 3.0 वर्तमान संस्करणों के रूप में थे। अब, पायथन 2.7 और 3.3 के साथ, अन्य विकल्प भी हैं। विशेष रूप से, यह अब देखें अजगर 2 और अजगर 3.

के लिए एक एकल कोड बेस का उपयोग करने के लिए काफी संभव है Porting Python 2 Code to Python 3

मूल जवाब:

official recommendation का कहना है:

मौजूदा अजगर 2.5 या 2.6 स्रोत कोड अजगर 3.0 करने के लिए पोर्टिंग के लिए, सबसे अच्छा रणनीति निम्नलिखित है:

+०१२३५१६४१०

1. (पूर्वापेक्षाएँ :) उत्कृष्ट परीक्षण कवरेज के साथ शुरू करें।

2. पोर्ट से पायथन 2.6। यह पाइथन 2.x से पायथन 2 (x + 1) से औसत पोर्ट से अधिक काम नहीं होना चाहिए। सुनिश्चित करें कि आपके सभी परीक्षण पास हो जाएं।

3. (अभी भी 2.6 का उपयोग कर :) -3 कमांड लाइन स्विच ऑन करें। यह सुविधाओं के बारे में चेतावनियां सक्षम करता है जो 3.0 में हटाए गए (या परिवर्तन) होंगे। अपने टेस्ट स्वीट फिर से चलाएँ, और कोड है कि आप के बारे में चेतावनी मिल तक वहां कोई चेतावनी छोड़ दिया जाता ठीक, और अपने सभी परीक्षण अभी भी गुजरती हैं।

4. अपने स्रोत कोड पेड़ पर 2to3 स्रोत-से-स्रोत अनुवादक चलाएं। (देखें 0to3 - स्वचालित पाइथन 2 से 3 इस उपकरण पर और अधिक के लिए कोड अनुवाद।) पायथन 3.0 के तहत अनुवाद का परिणाम चलाएं। मैन्युअल समस्याओं को ठीक करने तक सभी शेष परीक्षणों को ठीक करने तक किसी भी शेष समस्या को ठीक करें।

यह स्रोत कोड है कि दोनों अजगर 2.6 और 3.0 के तहत अपरिवर्तित चलाता है लिखने की कोशिश करने के लिए सिफारिश नहीं है; आपको एक बहुत ही अलग कोडिंग शैली का उपयोग करना होगा, उदा। प्रिंट स्टेटमेंट से परहेज, मेटाक्लास, और भी बहुत कुछ। आप एक पुस्तकालय है कि समर्थन दोनों अजगर 2.6 और अजगर 3.0 की जरूरत को बनाए रखने रहे हैं, सबसे अच्छा तरीका संपादन स्रोत कोड का 2.6 संस्करण और से फिर से 2to3 अनुवादक चल रहा है, बल्कि द्वारा उपरोक्त चरण 3 संशोधित करने के लिए है स्रोत कोड के 3.0 संस्करण को संपादित करना।

आदर्श रूप से, आप एक संस्करण के साथ समाप्त हो जाएंगे, जो कि 2.6 संगत है और 2to3 का उपयोग करके 3.0 में अनुवाद किया जा सकता है। अभ्यास में, हो सकता है कि आप इस लक्ष्य को पूरी तरह से प्राप्त नहीं कर पाएंगे। इसलिए आपको 3.0 के तहत काम करने के लिए कुछ मैन्युअल संशोधनों की आवश्यकता हो सकती है।

मैं इन संशोधनों को एक शाखा में, अपने विकल्प 2. की तरह है, बल्कि इस शाखा में अंतिम 3.0 संगत संस्करण को बनाए रखने की तुलना में बनाए रखना होगा लेकिन, मैं 2to3 अनुवाद से पहले मैनुअल संशोधनों लागू करने के लिए विचार किया जाएगा, और डाल यह आपकी शाखा में 2.6 कोड संशोधित है। इस विधि का लाभ यह होगा कि इस शाखा और 2.6 ट्रंक के बीच का अंतर अपेक्षाकृत छोटा होगा, और इसमें केवल मैन्युअल परिवर्तन होंगे, न कि 2to3 द्वारा किए गए परिवर्तन। इस तरह, अलग शाखाओं को बनाए रखने और मर्ज करने के लिए आसान होना चाहिए, और आप 2to3 में भविष्य में सुधार से लाभ प्राप्त करने में सक्षम होना चाहिए।

वैकल्पिक रूप से, "प्रतीक्षा करें और देखें" दृष्टिकोण का थोड़ा सा लें। अपने पोर्टिंग के साथ आगे बढ़ें, जहां तक ​​आप एक 2.6 संस्करण प्लस 2to3 अनुवाद के साथ जा सकते हैं, और शेष मैन्युअल संशोधन को तब तक स्थगित कर दें जब तक आपको वास्तव में 3.0 संस्करण की आवश्यकता न हो। हो सकता है कि इस समय तक आपको किसी भी मैनुअल ट्वीक्स की आवश्यकता नहीं है ...

Answer 2

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

वितरण के लिए, यदि संभव हो तो मैं विकल्प 3 का भी उपयोग करूंगा। सभी 3 विकल्प वैसे भी मान्य हैं और मैंने इन मॉडलों पर कई बार बदलाव देखा है।

Answer 3

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

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

Answer 4

मैं 2.6 पर माइग्रेट करके शुरू करूंगा, जो कि Python 3.0 के बहुत करीब है। आप 2.7 के लिए भी इंतजार करना चाहेंगे, जो कि अजगर 3.0 के करीब भी होगा।

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

जो भी आप चुनते हैं, सुनिश्चित करें कि आपके पास 100% कोड कवरेज के साथ पूर्ण परीक्षण हैं।

शुभकामनाएं!

Answer 5

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

मुझे लगता है कि कम से कम कुछ महीनों तक, एक साल तक, केवल 2.x के लिए विकास करना अधिक समझदारी है। कुछ समय पर यह 2.x के लिए अंतिम, स्थिर संस्करण पर घोषित करने का समय होगा और अगले 3x +

उदाहरण के लिए, मैं कुछ तक 3.x पर स्विच नहीं करूंगा प्रमुख ढांचे इस तरह से जाते हैं: पीईक्यूटी, matplotlib, numpy, और कुछ अन्य। और मुझे वास्तव में कोई फर्क नहीं पड़ता कि अगर किसी बिंदु पर वे 2.x समर्थन रोकते हैं और केवल 3.x के लिए विकास करना शुरू करते हैं, क्योंकि मुझे पता चलेगा कि थोड़े समय में मैं 3.x पर भी स्विच कर पाऊंगा।