2009-11-10 27 views
6

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

हम Pinax का एक नया संस्करण पर विकास शुरू हो गए हैं:

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

मुझे इस पर कुछ विचार सुनना अच्छा लगेगा।

+0

"मुझे नहीं लगातार बग फिक्स के लिए नाबालिग विज्ञप्ति बनाने का भी शौकीन हूँ ..." "बेशक पुराने संस्करण शाखाओं का हमें क्या करना है ..." बस स्पष्ट होना, आप के बारे में बात कर रहे हैं ऐप्स या पिनैक्स स्वयं (या दोनों)? –

+0

मैं ऐप्स का जिक्र कर रहा था। हम तब देव संस्करण के लिए हमारी आवश्यकताओं में नई मामूली रिलीज को लक्षित करेंगे और यदि हम इसे पिनैक्स की पिछली रिलीज की मामूली रिलीज पर चाहते हैं तो आवश्यकताओं को बैकपोर्ट करें। –

उत्तर

3

मेरा मतलब यह था कि मैंने पहले पूछे जाने वाले समाधान को पिनैक्स पीईपीआई डालने और विकास पर रिलीज करना था। हम chishop का एक उदाहरण डाल सकते हैं। हम पैकेजिंग के लिए pypi.pinaxproject.com पर इंगित करने के लिए पहले ही पाइप के - फाइंड-लिंक का उपयोग कर रहे हैं, जिन्हें हमें खुद को रिलीज़ करना पड़ा है।

+0

यह सुनिश्चित नहीं है कि -1 कहां से आया, कोई भी समझाएगा? मेरे लिए यह संभावित रूप से सबसे अच्छा विकल्प जैसा प्रतीत होता है, क्योंकि यह मेरे उत्तर में वर्णित == देव चीज़ से बहुत अधिक नियंत्रण देता है। –

3

क्या आप इसे "== dev" संस्करण विनिर्देशक का उपयोग करके संभाल सकते हैं? यदि पीईपीआई पर वितरण के पृष्ठ में वर्तमान dev संस्करण (जैसे कि दोनों जिथब और बिटबकेट स्वचालित रूप से प्रदान करते हैं) के .tgz का लिंक शामिल है और आप लिंक में "# egg = project_name-dev" जोड़ते हैं, तो easy_install और pip दोनों इसका उपयोग करेंगे .tgz अगर == dev अनुरोध किया गया है।

यह आपको "सबसे हालिया टिप/हेड" की तुलना में कुछ और विशिष्ट पिन करने की अनुमति नहीं देता है, लेकिन कई मामलों में जो पर्याप्त हो सकता है?

1

अधिकांश खुले स्रोत वितरक (डेबियन, उबंटू, मैकपॉर्ट्स, एट अल) कुछ प्रकार के पैच प्रबंधन तंत्र का उपयोग करते हैं। तो कुछ ऐसा है: रिलीज के रूप में प्रत्येक पैकेज के लिए आधार स्रोत कोड आयात करें, एक टैर बॉल के रूप में, या एससीएम स्नैपशॉट के रूप में। फिर पैच मैनेजर का उपयोग करके इसके ऊपर किसी भी आवश्यक संशोधन का प्रबंधन करें, जैसे quilt या Mercurial's Queues। फिर एक सतत प्रारूप में किसी भी लागू पैच के साथ प्रत्येक बाहरी पैकेज को बंडल करें। या व्यक्तिगत पैच के लिए मूल पैकेज और यूआरएल के लिए यूआरएल है और उन्हें स्थापना के दौरान लागू किया है। यह अनिवार्य रूप से MacPorts करता है।

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

0

संपादित करें: मुझे यकीन नहीं है कि मैं आपका प्रश्न सही तरीके से पढ़ रहा हूं, इसलिए निम्नलिखित आपके प्रश्न का सीधे उत्तर नहीं दे सकते हैं।

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

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

एक अन्य विकल्प आप उन ऐप्स के दर्पण को रख सकते हैं जिन्हें आप नियंत्रित नहीं करते हैं, एक सतत वीसीएस में, और फिर अपने प्रतिबिंबित संस्करणों को वितरित करते हैं। यह "हर किसी" के लिए कई अलग-अलग प्रोग्राम स्थापित करने की ज़रूरत को दूर करेगा।

इसके अलावा, ऐसा लगता है कि आप केवल एक ही वास्तविक समाधान है जो आप कर रहे हैं, कोई परेशानी रहित तरीका नहीं है जिसे मैं ढूंढने में सक्षम हूं।

+0

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

+0

हाँ आपके प्रश्न को दोबारा पढ़ने के बाद मैंने देखा कि मैं इसका जवाब सीधे नहीं दे रहा था। –