गो मॉड्यूल का परिचय

गो प्रोग्रामिंग भाषा के संस्करण 1.11 की आगामी रिलीज मॉड्यूल के लिए प्रयोगात्मक समर्थन लाएगी - गो के लिए एक नई निर्भरता प्रबंधन प्रणाली। (नोट अनुवाद: रिलीज हुई )

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

इसलिए, यहां हम क्या करेंगे: एक नया पैकेज बनाएं और फिर देखें कि यह कैसे काम करता है।

मॉड्यूल निर्माण

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

 $ mkdir testmod $ cd testmod 

हमारा पैकेज काफी सरल है:

 package testmod import "fmt" // Hi returns a friendly greeting func Hi(name string) string { return fmt.Sprintf("Hi, %s", name) } 

पैकेज तैयार है, लेकिन यह अभी तक एक मॉड्यूल नहीं है । चलो इसे ठीक करते हैं।

 $ go mod init github.com/robteix/testmod go: creating new go.mod: module github.com/robteix/testmod 

हमारे पास पैकेज निर्देशिका में go.mod नामक एक नई फ़ाइल निम्नलिखित सामग्री के साथ है:

 module github.com/robteix/testmod 

थोड़ा, लेकिन वह वही है जो हमारे पैकेज को एक मॉड्यूल में बदल देता है।

अब हम इस कोड को रिपॉजिटरी में धकेल सकते हैं:

 $ git init $ git add * $ git commit -am "First commit" $ git push -u origin master 

अब तक, जो कोई भी हमारे पैकेज का उपयोग करना चाहता है वह लागू go get :

 $ go get github.com/robteix/testmod 

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

वर्जनिंग मॉड्यूल के बारे में एक छोटा सा विषयांतर

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

इसके अलावा, गो संस्करणों की तलाश करते समय रिपॉजिटरी टैग का उपयोग करता है, और कुछ संस्करण बाकी से अलग होते हैं: उदाहरण के लिए, संस्करण 2 और अधिक के लिए संस्करण 0 और 1 की तुलना में एक अलग आयात पथ होना चाहिए (हम इसे प्राप्त करेंगे)।

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

हमारे लिए अब यह महत्वपूर्ण है कि हमारे पैकेज की रिलीज़ बनाते समय, हमें रिपॉजिटरी में संस्करण के साथ एक लेबल लगाने की आवश्यकता है।

चलो करते हैं।

अपनी पहली रिलीज बना रही है

हमारा पैकेज तैयार है और हम इसे पूरी दुनिया में "रोल आउट" कर सकते हैं। हम यह वर्जन किए गए लेबल का उपयोग करते हैं। संस्करण संख्या 1.0.0 होने दें:

 $ git tag v1.0.0 $ git push --tags 

ये कमांड मेरे गितुब रिपॉजिटरी में एक टैग बनाते हैं जो जारी किए गए 1.0.0 के रूप में वर्तमान प्रतिबद्ध को चिह्नित करता है।

गो इस पर जोर नहीं देते हैं, लेकिन एक अतिरिक्त नई शाखा ("v1") बनाना एक अच्छा विचार है, जिसमें हम पैच भेज सकते हैं।

 $ git checkout -b v1 $ git push -u origin v1 

अब हम बिना किसी चिंता के master ब्रांच में काम कर सकते हैं कि हम अपनी रिहाई तोड़ सकते हैं।

हमारे मॉड्यूल का उपयोग करना

आइए बनाए गए मॉड्यूल का उपयोग करें। हम एक सरल प्रोग्राम लिखेंगे जो हमारे नए पैकेज को आयात करता है:

 package main import ( "fmt" "github.com/robteix/testmod" ) func main() { fmt.Println(testmod.Hi("roberto")) } 

अब तक, आप पैकेज डाउनलोड करने के go get github.com/robteix/testmod पर go get github.com/robteix/testmod , लेकिन मॉड्यूल के साथ यह अधिक दिलचस्प हो जाता है। सबसे पहले, हमें अपने नए कार्यक्रम में मॉड्यूल समर्थन को सक्षम करने की आवश्यकता है।

 $ go mod init mod 

जैसा कि आप शायद उम्मीद करते हैं, जो आपने पहले पढ़ा था, उसके आधार पर निर्देशिका में नाम के साथ एक नई go.mod फ़ाइल दिखाई दी:

 module mod 

स्थिति और भी दिलचस्प हो जाती है जब हम अपने कार्यक्रम को एक साथ रखने की कोशिश करते हैं:

 $ go build go: finding github.com/robteix/testmod v1.0.0 go: downloading github.com/robteix/testmod v1.0.0 

जैसा कि आप देख सकते हैं, go कमांड स्वचालित रूप से हमारे प्रोग्राम द्वारा आयातित पैकेज को ढूंढ और डाउनलोड कर लेता है।
यदि हम अपनी go.mod फ़ाइल की जाँच करते हैं, तो हम देखेंगे कि कुछ बदल गया है:

 module mod require github.com/robteix/testmod v1.0.0 

और हमें go.sum नामक एक और नई फ़ाइल go.sum , जिसमें सही संस्करण और फ़ाइलों की जांच करने के लिए संकुल की हैश शामिल है।

 github.com/robteix/testmod v1.0.0 h1:9EdH0EArQ/rkpss9Tj8gUnwx3w5p0jkzJrd5tRAhxnA= github.com/robteix/testmod v1.0.0/go.mod h1:UVhi5McON9ZLc5kl5iN2bTXlL6ylcxE9VInV71RrlO8= 

बग फिक्स रिलीज़ रिलीज़ करना

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

 // Hi returns a friendly greeting func Hi(name string) string { - return fmt.Sprintf("Hi, %s", name) + return fmt.Sprintf("Hi, %s!", name) } 

हमने v1 शाखा में यह परिवर्तन सही किया है, क्योंकि इसका v2 शाखा में आगे क्या होगा, इससे कोई लेना-देना नहीं है, लेकिन वास्तविक जीवन में, शायद आपको इन परिवर्तनों को master में करना चाहिए और फिर उन्हें v1 भेजना चाहिए। किसी भी मामले में, फिक्स v1 शाखा में होना चाहिए और हमें इसे एक नए रिलीज के रूप में चिह्नित करना होगा।

 $ git commit -m "Emphasize our friendliness" testmod.go $ git tag v1.0.1 $ git push --tags origin v1 

मॉड्यूल अद्यतन

डिफ़ॉल्ट रूप से, गो बिना मांग के मॉड्यूल को अपडेट नहीं करता है। "और यह अच्छा है," क्योंकि हम सभी अपने निर्माण में पूर्वानुमान लगाना चाहते हैं। यदि हर बार एक नया संस्करण जारी होने पर गो मॉड्यूल को स्वचालित रूप से अपडेट किया जाएगा, तो हम "अंधेरे युग से पहले Go1.11" पर लौट आएंगे। लेकिन नहीं, हमें हमारे लिए मॉड्यूल अपडेट करने के लिए गो को बताने की आवश्यकता है।

और हम इसे अपने पुराने दोस्त की मदद से करेंगे - go get :

• रन go get -u अंतिम नाबालिग या पैच रिलीज़ का उपयोग करने के लिए (यानी कमांड 1.0.0 से अद्यतन करेगा, कहते हैं, 1.0.1 या 1.1.0, अगर ऐसा संस्करण उपलब्ध है)

  
  

• रन go get -u=patch नवीनतम पैच संस्करण का उपयोग करने के लिए (यानी पैकेज को 1.0.1 पर अपडेट किया जाएगा, लेकिन 1.1.0 तक नहीं )

  
  

• रन go get package@version को एक विशिष्ट संस्करण में अपग्रेड करने के लिए (उदाहरण के लिए, github.com/robteix/testmod@v1.0.1 )

  
  

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

चूंकि हमारे प्रोग्राम ने हमारे पैकेज के संस्करण 1.0.0 का उपयोग किया था और हमने अभी संस्करण 1.0.1 बनाया था, निम्न में से कोई भी आदेश हमें 1.0.1 में अपडेट करेगा:

 $ go get -u $ go get -u=patch $ go get github.com/robteix/testmod@v1.0.1 

शुरू करने के बाद (चलो कहते go get -u go.mod ), हमारे go.mod बदल गया है:

 module mod require github.com/robteix/testmod v1.0.1 

प्रमुख संस्करण

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

यह पहली बार में जंगली लग सकता है, लेकिन यह समझ में आता है: पुस्तकालय के दो संस्करण जो एक दूसरे के साथ असंगत हैं, दो अलग-अलग पुस्तकालय हैं।

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

 package testmod import ( "errors" "fmt" ) // Hi returns a friendly greeting in language lang func Hi(name, lang string) (string, error) { switch lang { case "en": return fmt.Sprintf("Hi, %s!", name), nil case "pt": return fmt.Sprintf("Oi, %s!", name), nil case "es": return fmt.Sprintf("¡Hola, %s!", name), nil case "fr": return fmt.Sprintf("Bonjour, %s!", name), nil default: return "", errors.New("unknown language") } } 

हमारे एपीआई का उपयोग करने वाले मौजूदा कार्यक्रम टूट जाएंगे क्योंकि वे ए) पैरामीटर के रूप में भाषा को पारित नहीं करते हैं और बी) त्रुटि वापसी की उम्मीद नहीं करते हैं। हमारा नया API अब संस्करण 1.x के साथ संगत नहीं है, इसलिए संस्करण 2.0.0 से मिलें।

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

हम अपने मॉड्यूल के नाम में एक नया संस्करण पथ जोड़कर ऐसा करेंगे।

 module github.com/robteix/testmod/v2 

बाकी सब समान है: धक्का, एक लेबल लगाओ कि यह v2.0.0 है (और वैकल्पिक रूप से एक शाखा v2 sod)

 $ git commit testmod.go -m "Change Hi to allow multilang" $ git checkout -b v2 # optional but recommended $ echo "module github.com/robteix/testmod/v2" > go.mod $ git commit go.mod -m "Bump version to v2" $ git tag v2.0.0 $ git push --tags origin v2 # or master if we don't have a branch 

मेजर वर्जन अपडेट

भले ही हमने अपने पुस्तकालय का एक नया असंगत संस्करण जारी किया, लेकिन मौजूदा कार्यक्रम नहीं टूटे , क्योंकि वे संस्करण 1.0.1 का उपयोग करना जारी रखते हैं।
go get -u संस्करण 2.0.0 डाउनलोड नहीं करेगा ।

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

अद्यतन करने के लिए, मुझे अपने कार्यक्रम को तदनुसार बदलना होगा:

 package main import ( "fmt" "github.com/robteix/testmod/v2" ) func main() { g, err := testmod.Hi("Roberto", "pt") if err != nil { panic(err) } fmt.Println(g) } 

अब, जब मैं go build संचालन करता हूं, तो यह "क्विट" और मेरे लिए संस्करण 2.0.0 डाउनलोड करता है। ध्यान दें कि यद्यपि आयात पथ अब "v2" में समाप्त होता है, फिर भी इसके वास्तविक नाम ("टेस्टमॉड") द्वारा मॉड्यूल को संदर्भित करता है।

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

 package main import ( "fmt" "github.com/robteix/testmod" testmodML "github.com/robteix/testmod/v2" ) func main() { fmt.Println(testmod.Hi("Roberto")) g, err := testmodML.Hi("Roberto", "pt") if err != nil { panic(err) } fmt.Println(g) } 

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

हम चीजों को क्रम में रखते हैं

चलो पिछले संस्करण पर वापस जाते हैं, जो केवल टेस्टमॉड 2.0.0 का उपयोग करता है - अगर हम go.mod की सामग्री की जांच करते go.mod , तो हम इस पर ध्यान देंगे:

 module mod require github.com/robteix/testmod v1.0.1 require github.com/robteix/testmod/v2 v2.0.0 

डिफ़ॉल्ट रूप से, Go तब तक निर्भरता को go.mod से नहीं go.mod जब तक आप इसके लिए नहीं पूछते। यदि आपके पास निर्भरताएं हैं जिनकी अब आवश्यकता नहीं है और आप उन्हें साफ करना चाहते हैं, तो आप नई tidy कमांड का उपयोग कर सकते हैं:

 $ go mod tidy 

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

vendoring

डिफ़ॉल्ट रूप से जाने वाले मॉड्यूल vendor/ निर्देशिका को अनदेखा करते हैं। विचार धीरे-धीरे वेंडिंग ^{1 से} छुटकारा पाने का है। लेकिन अगर हम अभी भी अपने संस्करण नियंत्रण के लिए "अलग" निर्भरता जोड़ना चाहते हैं, तो हम यह कर सकते हैं:

 $ go mod vendor 

टीम हमारी परियोजना के मूल में vendor/ निर्देशिका बनाएगी, जिसमें सभी निर्भरता के स्रोत कोड होंगे।

हालाँकि, डिफ़ॉल्ट रूप से go build अभी भी इस निर्देशिका की सामग्री को अनदेखा करता है। यदि आप vendor/ निर्देशिका से निर्भरता एकत्र करना चाहते हैं, तो आपको इसके लिए स्पष्ट रूप से पूछना चाहिए।

 $ go build -mod vendor 

मुझे लगता है कि कई डेवलपर्स जो वेंडिंग का उपयोग करना चाहते go build , वे अपनी मशीनों पर, हमेशा की तरह, go build का उपयोग -mod vendor और अपने CI पर -mod vendor उपयोग -mod vendor ।

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

यह सुनिश्चित करने के तरीके go नेटवर्क अनुपलब्ध है (उदाहरण के लिए, GOPROXY=off का उपयोग करके), लेकिन यह अगले लेख का विषय है।

निष्कर्ष

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

मॉड्यूल $GOPATH की आवश्यकता को भी समाप्त कर $GOPATH , जो नए Go डेवलपर्स के लिए एक ठोकर था, जिन्हें यह समझने में समस्या थी कि उन्हें किसी विशिष्ट निर्देशिका में कुछ क्यों रखना चाहिए।

प्रॉक्सी का उपयोग करने के पक्ष में वेंडिंग (अनौपचारिक रूप से) को हटा दिया गया है। ¹
मैं गो मॉड्यूल के लिए परदे के पीछे एक अलग लेख बना सकता हूं।

टिप्पणी:

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