फरवरी 2018 में लिखा गया लेख।

जाओ पैकेज संस्करण जोड़ने की जरूरत है।

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

संस्करण क्रमांकन आपको प्रतिलिपि प्रस्तुत करने योग्य असेंबली बनाने की अनुमति देता है: यदि मैं अपने कार्यक्रम का नवीनतम संस्करण पोस्ट करता हूं, तो आपको न केवल मेरे कोड का नवीनतम संस्करण मिलेगा, बल्कि सभी पैकेजों के सटीक समान संस्करण भी होंगे जो मेरा कोड निर्भर करता है, ताकि हम पूरी तरह से समकक्ष बाइनरी फ़ाइलों का निर्माण करेंगे।

वर्जनिंग यह भी सुनिश्चित करता है कि कल प्रोग्राम बिलकुल वैसा ही बने जैसा कि आज है। यहां तक ​​कि अगर निर्भरता के नए संस्करण जारी किए जाते हैं, तो go विशेष कमांड के बिना उनका उपयोग नहीं करेंगे।

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

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

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

सामान्य स्थिति

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

Makefile , goinstall और go get

नवंबर 2009 में, गो के प्रारंभिक संस्करण के साथ संकलक, लिंकर और कई पुस्तकालय जारी किए गए थे। कार्यक्रमों को संकलित और लिंक करने के लिए, 6g और 6g 6l को चलाने के लिए आवश्यक था, और हमने किट में नमूना मेकफाइल्स को शामिल किया। न्यूनतम gobuild शेल एक पैकेज संकलित कर सकता है और संबंधित gobuild (ज्यादातर मामलों में) लिख सकता है। दूसरों के साथ कोड साझा करने का कोई स्थापित तरीका नहीं था। हम जानते थे कि यह पर्याप्त नहीं था - लेकिन हमने जारी किया कि हमारे पास क्या है, बाकी को समुदाय के साथ मिलकर विकसित करने की योजना है।

फरवरी 2010 में, हमने गोस्टाइम को प्रस्तावित किया , बिटकबेट और गीथहब जैसे संस्करण नियंत्रण प्रणालियों के रिपॉजिटरी से पैकेज डाउनलोड करने के लिए एक सरल कमांड। Goinstall आयात रास्तों पर सम्मेलनों Goinstall शुरुआत की है जो अब आम तौर पर स्वीकार किए जाते हैं। लेकिन उस समय, किसी भी संहिता ने इन सम्मेलनों का पालन नहीं किया, पहले goinstall केवल उन पैकेजों के साथ काम की जो मानक पुस्तकालय के अलावा कुछ भी आयात नहीं करते थे। लेकिन डेवलपर्स जल्दी से एक एकल समझौते पर चले गए, जिसे हम आज जानते हैं, और प्रकाशित गो पैकेज का सेट एक समग्र पारिस्थितिकी तंत्र में विकसित हुआ है।

गोइनस्टॉल ने मेकफाइल्स को भी तय किया, और उनके साथ कस्टम बिल्ड विकल्पों की जटिलता। हालांकि यह कभी-कभी असुविधाजनक होता है कि पैकेज लेखक प्रत्येक बिल्ड के दौरान कोड उत्पन्न नहीं कर सकते हैं, यह सरलीकरण पैकेज उपयोगकर्ताओं के लिए अविश्वसनीय रूप से महत्वपूर्ण है: उन्हें उसी उपकरण के सेट को स्थापित करने के बारे में चिंता नहीं करनी चाहिए जिसका उपयोग लेखक करता है। साधनों के संचालन के लिए यह सरलीकरण भी महत्वपूर्ण है। पैकेज तैयार करने के लिए मेकफाइल एक आवश्यक चरण-दर-चरण नुस्खा है; और एक ही पैकेज पर एक अन्य उपकरण जैसे go vet या स्वतः पूर्णता को लागू करना काफी मुश्किल हो सकता है। यहां तक ​​कि निर्भरता को सही ढंग से प्राप्त करना, यदि आवश्यक हो तो केवल पैकेजों का पुनर्निर्माण करना और मनमाना मेकफाइल्स के साथ बहुत अधिक जटिल है। हालांकि उस समय कुछ लोगों ने आपत्ति जताई थी कि उन्हें लचीलेपन से वंचित किया जा रहा है, लेकिन पीछे मुड़कर देखने से यह स्पष्ट हो जाता है कि मेकफिल को छोड़ना सही कदम था: इससे होने वाले लाभ असुविधा को दूर करते हैं।

दिसंबर 2011 में, गो 1 की तैयारी में, हमने गो कमांड को पेश किया , जिसने goinstall साथ goinstall को बदल दिया।

सामान्य तौर पर, go get महत्वपूर्ण परिवर्तन पेश किए जाते हैं: इसने गो डेवलपर्स को स्रोत कोड का आदान-प्रदान करने और एक दूसरे के काम का उपयोग करने की अनुमति दी। उन्होंने go कमांड के अंदर बिल्ड सिस्टम के कुछ हिस्सों को भी अलग कर दिया, ताकि उपकरणों की मदद से महत्वपूर्ण स्वचालन संभव हो सके। लेकिन go get संस्करण नियंत्रण की अवधारणा का अभाव है। गोइस्ट की पहली चर्चा में, यह स्पष्ट हो गया: आपको संस्करण नियंत्रण के साथ कुछ करने की आवश्यकता है। दुर्भाग्य से, यह स्पष्ट नहीं था कि वास्तव में क्या करना है। कम से कम गो टीम में हमें यह स्पष्ट रूप से समझ नहीं आया। जब go get एक पैकेज का अनुरोध go get , तो उसे हमेशा नवीनतम कॉपी, डाउनलोडिंग और अपडेट ऑपरेशंस को एक वर्जन कंट्रोल सिस्टम जैसे Git या मर्सिडीज में मिलता है। इस तरह के "ब्लाइंड वर्क" के कारण कम से कम दो महत्वपूर्ण दोष हो गए हैं।

संस्करण और एपीआई स्थिरता

जाने का पहला बड़ा दोष यह है कि संस्करण नियंत्रण की अवधारणा के बिना, यह उपयोगकर्ता को इस बारे में कुछ भी नहीं बता सकता है कि इस अपडेट में क्या बदलाव होने की उम्मीद है।

नवंबर 2013 में, गो 1.2 के एक संस्करण ने वर्जनिंग के बारे में ऐसी सलाह के साथ अक्सर पूछे जाने वाले प्रश्न में प्रवेश किया (पाठ को संस्करण 1.10 में परिवर्तित नहीं किया गया है):

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

मार्च 2014 में, गुस्तावो नीमेयर ने "गो भाषा के लिए स्थिर एपीआई" की आड़ में gopkg.in को लॉन्च किया। यह डोमेन एक संस्करण- gopkg.in/yaml.v1 GitHub रीडायरेक्ट है जो आपको एक gopkg.in/yaml.v2 के विभिन्न gopkg.in/yaml.v2 (संभवतः विभिन्न शाखाओं में) के लिए gopkg.in/yaml.v1 और gopkg.in/yaml.v2 जैसे रास्तों को आयात करने की अनुमति देता है। सिमेंटिक वर्जनिंग के अनुसार, लेखकों को, महत्वपूर्ण बदलाव करते समय, एक नया प्रमुख संस्करण जारी करना चाहिए। इस प्रकार, v1 आयात पथ के बाद के संस्करण पिछले वाले को बदल देते हैं, और v2 पूरी तरह से अलग एपीआई दे सकते हैं।

अगस्त 2015 में डेव चेनी ने सिमेंटिक वर्जन कंट्रोल के लिए एक प्रस्ताव पेश किया । अगले कुछ महीनों में, इसने एक दिलचस्प चर्चा का कारण बना: हर कोई इस बात से सहमत था कि संस्करणों के सिमेंटिक टैगिंग एक महान विचार है, लेकिन किसी को नहीं पता था कि इन संस्करणों के साथ टूल को कैसे काम करना चाहिए।

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

आपके API का अनुबंध पर्याप्त संख्या में उपयोगकर्ताओं के साथ महत्वहीन हो जाता है। कोई सिस्टम के किसी भी देखे गए व्यवहार पर निर्भर करता है।

यद्यपि हिरुम का नियम आनुभविक रूप से सही है, सिमेंटिक संस्करण नियंत्रण अभी भी रिलीज़ के बीच के संबंध के बारे में अपेक्षाएं उत्पन्न करने का एक उपयोगी तरीका है। 1.2.3 से 1.2.4 तक का अपग्रेड आपके कोड को नहीं तोड़ना चाहिए, और 1.2.3 से 2.0.0 तक का अपग्रेड बहुत अच्छी तरह से हो सकता है। यदि 1.2.4 पर अपडेट करने के बाद कोड काम करना बंद कर देता है, तो लेखक सबसे खराब रिपोर्ट को स्वीकार करेगा और संस्करण 1.2.5 में त्रुटि को ठीक करेगा। यदि 2.0.0 को अपडेट करने के बाद कोड ने काम करना बंद कर दिया (या यहां तक ​​कि संकलित किया गया), तो यह परिवर्तन जानबूझकर होने की संभावना अधिक थी और तदनुसार, यह संभावना नहीं है कि 2.0.1 में कुछ तय किया जाएगा।

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

वेंडिंग और प्रतिलिपि प्रस्तुत करने योग्य विधानसभाएं

दूसरा मुख्य दोष यह है कि संस्करण नियंत्रण की अवधारणा के बिना, एक टीम प्रदान नहीं कर सकती है और यहां तक ​​कि एक प्रतिलिपि निर्माण के विचार को भी व्यक्त नहीं कर सकती है। आप यह सुनिश्चित नहीं कर सकते हैं कि उपयोगकर्ता कोड निर्भरता के समान संस्करण को संकलित कर रहे हैं। नवंबर 2013 में, निम्नलिखित FAQ को Go 1.2 के लिए FAQ में जोड़ा गया था:

यदि आप एक बाहरी पैकेज का उपयोग करते हैं और डरते हैं कि यह अप्रत्याशित रूप से बदल सकता है, तो सबसे आसान समाधान यह है कि इसे स्थानीय रिपॉजिटरी में कॉपी किया जाए (यह दृष्टिकोण Google द्वारा उपयोग किया जाता है)। नए आयात पथ के साथ एक प्रतिलिपि सहेजें जो इसे स्थानीय प्रतिलिपि के रूप में पहचानती है। उदाहरण के लिए, आप original.com/pkg को you.com/external/original.com/pkg कॉपी कर सकते हैं। इस प्रक्रिया के लिए उपकरणों में से एक किट रेरिक का गोवेन है।

कीथ ररिक ने इस परियोजना को मार्च 2012 में शुरू किया था। goven उपयोगिता स्थानीय भंडार पर निर्भरता की प्रतिलिपि बनाता है और नए स्थान को प्रतिबिंबित करने के लिए सभी आयात पथों को अपडेट करता है। इस तरह के स्रोत कोड परिवर्तन आवश्यक हैं, लेकिन अप्रिय। वे नई प्रतियों की तुलना और शामिल करना मुश्किल बनाते हैं, और इस निर्भरता का उपयोग करके अन्य प्रतिलिपि किए गए कोड को अपडेट करने की भी आवश्यकता होती है।

सितंबर 2013 में, कीथ ने गॉडप पेश किया , "पैकेज निर्भरता को ठीक करने का एक नया उपकरण।" godep की मुख्य उपलब्धि थी जिसे अब हम godep कहते हैं, अर्थात, सोर्स फाइल्स को बिना टूल्स के सीधे सपोर्ट के बिना प्रोजेक्ट में निर्भरता की नकल करते हुए, एक निश्चित तरीके से GOPATH को सेट करके।

अक्टूबर 2014 में, कीथ ने गो टूल्स में "बाहरी पैकेज" के लिए समर्थन जोड़ने का प्रस्ताव रखा ताकि उपकरण इस सम्मेलन का उपयोग करके परियोजनाओं को बेहतर ढंग से समझ सकें। उस समय तक, कई godep उपयोगिताओं पहले से ही दिखाई दी थीं। मैट फ़रीना ने " godep ऑफ़ गो godep मैनेजर्स" पोस्ट को प्रकाशित किया, जिसमें godep तुलना godep , विशेष रूप से glide ।

अप्रैल 2015 में, डेव चेने ने gb , "प्रोजेक्ट-आधारित बिल्ड टूल ... रिपीट बिल्ड विथ सोर्स वेंडिंग के माध्यम से," फिर से आयात पथों को फिर से लिखने के बिना, GbATH में विशिष्ट निर्देशिकाओं में कोड स्टोर करने की आवश्यकता से बचने के लिए एक और प्रेरणा थी। जो हमेशा सुविधाजनक नहीं होता है)।

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

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

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

आधिकारिक पैकेज प्रबंधन प्रयोग

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

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

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

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

प्रस्ताव

go कमांड में संस्करण नियंत्रण जोड़ने के प्रस्ताव में चार चरण हैं। सबसे पहले, आयात संगतता नियम को स्वीकार करें, जो FAQ और gopkg.in द्वारा इंगित किया गया है: निर्दिष्ट आयात पथ के साथ पैकेज के नए संस्करण पुराने संस्करणों के साथ पीछे की ओर संगत होना चाहिए। दूसरे, एक साधारण नए एल्गोरिथ्म को अपनाएं, जिसे यह निर्धारित करने के लिए न्यूनतम संस्करण के रूप में जाना जाता है कि इस विधानसभा में पैकेज के किन संस्करणों का उपयोग किया जाता है। तीसरा, गो मॉड्यूल की अवधारणा को पेश करें: संकुल के समूह जो एक संपूर्ण संस्करण के रूप में हैं और न्यूनतम आवश्यकताओं की घोषणा करते हैं जिन्हें उनकी निर्भरता से संतुष्ट होना चाहिए। चौथा, यह निर्धारित करें कि इस सभी को अपने मौजूदा go कमांड में कैसे एकीकृत किया जाए ताकि बुनियादी वर्कफ़्लो आज से महत्वपूर्ण रूप से न बदले। इस लेख के बाकी हिस्सों में, हम इनमें से प्रत्येक चरण को देखते हैं। वे अन्य ब्लॉग लेखों में अधिक विस्तार से चर्चा कर रहे हैं।

आयात संगतता नियम

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

एक प्रणाली के बजाय जो अनिवार्य रूप से बड़े कार्यक्रमों की विधानसभा को अवरुद्ध करती है, हमारा प्रस्ताव पैकेज लेखकों के लिए एक आयात संगतता नियम पेश करता है:

यदि पुराने और नए पैकेजों में समान आयात पथ है, तो नए पैकेज को पुराने पैकेज के साथ संगत होना चाहिए।

नियम पहले उल्लिखित FAQ को दोहराता है। वह पाठ शब्दों के साथ समाप्त हुआ: "एक क्रांतिकारी परिवर्तन की स्थिति में, एक नया आयात पथ के साथ एक नया पैकेज बनाएं।"आज, इस तरह के एक बड़े बदलाव के लिए, डेवलपर्स अर्थ संस्करण नियंत्रण पर भरोसा कर रहे हैं, इसलिए हम इसे अपने प्रस्ताव में एकीकृत करते हैं। विशेष रूप से, दूसरे और बाद के प्रमुख संस्करणों की संख्या को सीधे पथ में शामिल किया जा सकता है:

 import "github.com/go-yaml/yaml/v2" 

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

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

न्यूनतम संस्करण चयन

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

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

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

न्यूनतम संस्करण का चयन ताला फ़ाइल के बिना डिफ़ॉल्ट रूप से प्रतिलिपि प्रस्तुत करने योग्य विधानसभाओं प्रदान करता है।

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

गो मॉड्यूल को परिभाषित करना

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

नई फ़ाइल में, go.modमॉड्यूल अन्य मॉड्यूल के लिए न्यूनतम संस्करण आवश्यकताओं को परिभाषित करता है, जिस पर यह निर्भर करता है। उदाहरण के लिए, यहाँ एक सरल फ़ाइल है go.mod:

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 ) 

यह फ़ाइल एक मॉड्यूल को परिभाषित करती है जिसे पथ द्वारा पहचाना जाता है rsc.io/hello, और यह दो अन्य मॉड्यूल पर निर्भर करता है: golang.org/x/textऔर rsc.io/quote। मॉड्यूल असेंबली हमेशा फ़ाइल में सूचीबद्ध आवश्यक निर्भरता के कुछ संस्करणों का उपयोग करेगी go.mod। एक बड़ी विधानसभा के हिस्से के रूप में, यह केवल एक नए संस्करण का उपयोग कर सकता है अगर विधानसभा के कुछ अन्य हिस्से को इसकी आवश्यकता होती है।

लेखक अपनी रिलीज़ को सिमेंटिक संस्करणों के साथ vgoचिह्नित करते हैं , और चिह्नित संस्करणों का उपयोग करने की सलाह देते हैं, न कि मनमाने तरीके से। मॉड्यूल rsc.io/quoteजो github.com/rsc/quote1.5.2 सहित चिह्नित संस्करणों के साथ आता है । हालाँकि, मॉड्यूल का कोई golang.org/x/textध्वजांकित संस्करण नहीं है। अनटैग्ड कमिट्स को नाम देने के लिए, छद्म संस्करण v0.0.0-yyyymmddhhmmss- कमिटदी गई तारीख पर एक विशिष्ट प्रतिबद्ध परिभाषित करता है। अर्थ वर्ज़निंग प्री-रिलीज़ v0.0.0 पहचानकर्ता को यह लाइन मेल खाती yyyymmddhhmmss-लिखें । संस्करण पूर्वता के शब्दार्थ नियम संस्करण v0.0.0 की तुलना में इस तरह के पूर्व-रिलीज़ को पहचानते हैं, और स्ट्रिंग तुलना करते हैं। छद्म संस्करण में दिनांक क्रम यह सुनिश्चित करता है कि स्ट्रिंग तुलना तिथि तुलना से मेल खाती है।

इन आवश्यकताओं के अलावा, फाइलें go.modपिछले अनुभाग में उल्लिखित अपवादों और प्रतिस्थापनों को इंगित कर सकती हैं, लेकिन फिर से वे केवल एक पृथक मॉड्यूल का निर्माण करते समय लागू होते हैं, और बड़े कार्यक्रम के भाग के रूप में निर्माण करते समय नहीं। यह सब उदाहरणों में प्रदर्शित होता है ।

Goinstallऔर पुरानाgo getसंस्करण नियंत्रण उपकरण, जैसे कि gitऔर hg, को कोड डाउनलोड करने के लिए कहा जाता है , जिससे विखंडन सहित कई समस्याएं होती हैं। उदाहरण के लिए, बिना यूज़र्स bzrबाज़ार के रिपॉजिटरी से कोड डाउनलोड नहीं कर सकते हैं। इस प्रणाली के विपरीत, गो मॉड्यूल हमेशा ज़िप अभिलेखागार के रूप में HTTP के माध्यम से जारी किए जाते हैं। पहले, go getलोकप्रिय कोड होस्टिंग साइटों के लिए विशेष टीमें थीं। अब उनके पास vgoइन साइटों से अभिलेखागार प्राप्त करने के लिए विशेष एपीआई प्रक्रियाएं हैं।

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

टीम go

मॉड्यूल के साथ काम करने के लिए, कमांड goको अपडेट करने की आवश्यकता है। बड़े बदलाव से एक है कि हमेशा की तरह का निर्माण जैसे आदेश है go build, go install, go runऔर go test, नई निर्भरता के लिए मांग की अनुमति देगा। golang.org/x/textएक पूरी तरह से नए मॉड्यूल में उपयोग करने के लिए , बस गो स्रोत कोड में आयात करें और निर्माण करें।

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

आगे क्या है?

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

कृपया प्रयास करें । सिमेंटिक टैग के साथ रिपॉजिटरी में संस्करणों को टैग करना शुरू करें। फाइलें बनाएं go.mod। ध्यान दें कि भंडार में एक खाली फ़ाइल अगर go.mod, लेकिन देखते हैं dep, glide, glock, godep, godeps, govend, govendorया विन्यास फाइल gvt, तो vgoउन्हें फ़ाइल को भरने के लिए उपयोग करता है go.mod।

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

लेकिन मैं शायद कुछ विवरणों में गलत हूँ। मुझे आशा है कि पाठक प्रोटोटाइप का परीक्षण करके vgoऔर उत्पादक चर्चाओं में भाग लेकर इसे बेहतर बनाने में मदद कर सकते हैं । मैं गो 1.11 को गो मॉड्यूल के लिए प्रारंभिक समर्थन के साथ आना चाहूंगा, एक प्रकार के डेमो के रूप में, और फिर गो 1.12 आधिकारिक समर्थन के साथ सामने आया। बाद के संस्करणों में, हम पुराने, गैर-प्रसार के लिए समर्थन हटा देंगेgo get। लेकिन यह एक आक्रामक योजना है, और यदि सही कार्यक्षमता के लिए आपको बाद में रिलीज़ होने की प्रतीक्षा करने की आवश्यकता है, तो ऐसा ही हो।

मैं पुराने go getऔर अनगिनत वेंडिंग टूल से नए मॉड्यूलर सिस्टम में संक्रमण के बारे में बहुत चिंतित हूं । यह प्रक्रिया मेरे लिए सही कार्यक्षमता के समान ही महत्वपूर्ण है। यदि एक सफल संक्रमण का मतलब बाद में रिलीज होने की प्रतीक्षा करना है, तो फिर से, ऐसा ही हो।