पायथन (2.4, 2.5, 2.6, 3.0) का संस्करण क्या आप उत्पादन विकास प्रयासों (और क्यों) के लिए मानकीकृत करते हैं?

Question

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

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

हमने हाल ही में वाणिज्यिक उत्पाद के पर्यावरण पर निर्भरता से हमारे निर्माण पर्यावरण decoupled है और अजगर (या जावा) हम चाहते हैं के किसी भी संस्करण का उपयोग कर सकते हैं। यह एक महीने या उससे भी अधिक रहा है क्योंकि हमने पाइथन 2.6 पर पाइथन के नवीनतम संस्करण के रूप में मानकीकृत किया है जो पिछले संस्करणों के साथ पिछड़ा संगत है।

अजगर 3.0 नहीं के बाद से हम अपने निर्माण और एकीकरण उपकरण सही ढंग से काम करने के लिए फिर से बनाने के लिए हमारे कोड बेस के बहुत ज्यादा विस्थापित करने के लिए होगा एक विकल्प (अब के लिए) है।

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

अब मैं अगर हम उत्पादन वातावरण उपकरणों के विकास में अजगर 2.6 का उपयोग करने के लिए अजगर 2.5 को मानकीकृत चाहिए बजाय अब सोच रहा हूँ। अधिकांश उपकरण जो हम चाहते हैं/चाहते हैं वे पाइथन 2.5 के साथ सही तरीके से काम करते हैं। पाइथन 2.6 फीचर्स या मॉड्यूल पर कई निर्भरताओं से पहले हम इसे हल करने की कोशिश कर रहे हैं।

बहुत धन्यवाद!

-माइकल

Answer 1

मैं 2.6 सिर्फ प्रतिवाद चेतावनी की वजह से त्याग नहीं होता; वे समय के साथ गायब हो जाएंगे। (आप कम से कम मुद्रित होने से रोकने के लिए पाइथन दुभाषिया के -W ignore विकल्प का उपयोग कर सकते हैं) लेकिन यदि मॉड्यूल को वास्तव में उपयोग करने की आवश्यकता है तो वास्तव में Python 2.6 के साथ काम नहीं करते हैं, यह 2.5 के साथ रहने का एक वैध कारण होगा। पाइथन 2.5 अब व्यापक उपयोग में है और शायद आने वाले लंबे समय तक होगा (मान लें कि 2.3 कितनी देर तक चल रहा है!), इसलिए यदि आप 2.5 के साथ जाते हैं, तो आपको थोड़ी देर के लिए अपग्रेड करने के लिए मजबूर नहीं किया जाएगा।

मैं अपने सभी विकास कार्य के लिए अजगर 2.5 का उपयोग करें, लेकिन केवल क्योंकि यह संस्करण है कि Gentoo में उपलब्ध होने की (लिनक्स) के पैकेज भंडार होता है। जब जेनेटू रखरखाव Python 2.6 "स्थिर" * घोषित करते हैं, तो मैं उस पर स्विच करूंगा। बेशक, यह तर्क जरूरी नहीं है कि आप पर लागू हों।

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

Answer 2

मुझे सबसे महत्वपूर्ण अजगर के साथ रहना करने के लिए 2.5+ है, क्योंकि यह आधिकारिक तौर पर ctypes का समर्थन करता है, जो कई प्लगइन प्रणाली बदल दिया है।

हालांकि आप 2.3/2.4 के साथ काम करने के लिए ctypes पा सकते हैं, लेकिन वे आधिकारिक तौर पर बंडल नहीं किए जाते हैं।

तो मेरा सुझाव 2.5 होगा।

Answer 3

मेरी कंपनी 2.5 में मानकीकृत है। आप की तरह हम एक लाख कारणों से 3.0 तक स्विच नहीं कर सकते हैं, लेकिन मुझे बहुत इच्छा है कि हम 2.6 तक बढ़ सकें।

कर कोडिंग दिन से दिन मैं प्रलेखन के माध्यम से देख रहे होंगे और मैं वास्तव में मॉड्यूल या समारोह है कि मैं चाहता हूँ मिल जाएगा, लेकिन तब यह थोड़ा एनोटेशन होगा: संस्करण 2.6 में नई

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

Answer 4

हम अभी 2.5.2 के साथ चिपके हुए हैं। Django पर हमारे तकनीकी ढेर केंद्र (लेकिन हमारे पास एक दर्जन अन्य बिट्स और बोब्स हैं।) तो हम उनके काम के करीब रहते हैं।

हम 0.4 करने के लिए docutils करने के लिए वापस जाना पड़ा तो यह epydoc 3.0.1 के साथ काम करेगा। अब तक, यह एक बड़ा मुद्दा नहीं रहा है, लेकिन यह किसी बिंदु पर - हमें epydoc के उपयोग पर पुनर्विचार करने का कारण बन सकता है।

2.6 अपग्रेड हमारी विकास योजना का हिस्सा है। हमारे पास बजट है, लेकिन अभी तय समय निर्धारित नहीं है।

3.0 उन्नयन, इसी तरह, कुछ मैं के लोगों को याद दिलाना है। हमें इसके लिए बजट करना है। हम इस साल ऐसा नहीं करेंगे जब तक कि डैंजो 3.0 तक नहीं पहुंच जाता। हम अगले साल ऐसा कर सकते हैं।

Answer 5

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

तो एक मुद्दा प्रति आधार पर यह के साथ काम करने के बजाय आप अपनी रिहाई प्रबंधन पर एक अच्छी नज़र लेने के द्वारा इस समस्या का समाधान कर सकता है।

इसके बजाय स्रोत जारी करने की

, मंच के आधार बाइनरी (स्रोत वितरण के अलावा) के लिए जाना। x86-32, x86-64, स्पार्क

तब जो ऑपरेटिंग सिस्टम: लिनक्स, विंडोज, सोलारिस, FreeBSD

तो आप क्या है कि आप उदाहरण के लिए समर्थित CPU के के एक नंबर को परिभाषित है,

प्रत्येक ओएस के लिए आप अपने कई प्रमुख संस्करणों का समर्थन करते हैं।

अगला चरण यह है कि आप उन सभी के लिए द्विआधारी प्रदान करते हैं।

हां वास्तव में इसके लिए कुछ बुनियादी ढांचे निवेश और आपके भंडारों से स्वचालित भवन की स्थापना की आवश्यकता होगी (आपके पास है?)।

लाभ है कि अपने उपयोगकर्ताओं को केवल स्थापित करने के लिए 'एक' बात है और आप आसानी से संस्करणों या यहाँ तक कि मिश्रण संस्करणों स्विच कर सकते हैं। असल में आप अपने रिलीज प्रबंधन को प्रभावित किए बिना इस दृष्टिकोण के साथ विभिन्न प्रोग्रामिंग भाषाओं का भी उपयोग कर सकते हैं।