क्या यह सच है कि GOPATH और GOROOT की अब आवश्यकता नहीं है?

ऐसा हुआ कि डेवलपर्स जो अभी गो के साथ परिचित होना शुरू कर रहे हैं, अक्सर गो परियोजनाओं के लिए एक कार्यशील निर्देशिका चुनने की समस्या का सामना करते हैं। इसलिए, गोलंगकॉन्फ़ सम्मेलन की बातचीत में , यह प्रश्न भी पूछा गया था। नए Gophers अक्सर GOPATH और GOROOT शब्दों से एक-दूसरे को डराते हैं । हालाँकि, गो (1.13) के वर्तमान संस्करण के साथ त्वरित आरंभ गाइडों में, इन दो "डरावने" शब्दों का उल्लेख नहीं किया गया है।

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

sudo add-apt-repository ppa:longsleep/golang-backports sudo apt-get update sudo apt-get install golang-go 

जाओ 1.13 स्थापित है और उपयोग करने के लिए तैयार है:

 $ go version go version go1.13 linux/amd64 $ which go /usr/bin/go $ whereis go go: /usr/bin/go /usr/lib/go /usr/share/go /usr/share/man/man1/go.1.gz 

GOROOT

GOROOT बारे में 2015 के एक लेख में पहले ही पूरी तरह से लिखा जा चुका है, और यह जानकारी अभी भी प्रासंगिक है।

यह मजेदार है कि अंतिम आदेश ( GOROOT whereis go ) द्वारा जारी की गई निर्देशिकाओं की सूची में, GOROOT वास्तव में नहीं है:

 $ go env GOROOT /usr/lib/go-1.13 

इसलिए, उदाहरण के लिए, अगर आईडीई के लिए मुझे मानक गो लाइब्रेरी की फ़ाइलों के लिए पथ निर्दिष्ट करने की आवश्यकता है, तो मैं /usr/lib/go-1.13 निर्दिष्ट करूंगा। शायद, इस परिदृश्य में, रोजमर्रा की जिंदगी में GOROOT का उपयोग समाप्त होता है।

GOPATH और मॉड्यूल

ऐसा लगता है कि इस जगह में GOPATH को स्थापित करने के लिए जल्दी करना आवश्यक है, लेकिन मैं ऐसा नहीं करूंगा। वास्तव में GOPATH पहले GOPATH ही सेट है:

 $ go env GOPATH /home/elena/go 

मैं ~/go में GOPATH साथ सहज हूं, जिसका अर्थ है कि मैंने इसे नहीं बदला है।

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

 $ mkdir ~/hello $ go mod init github.com/rumyantseva/hello go: creating new go.mod: module github.com/rumyantseva/hello 

go mod init कमांड के लिए, मैंने अपनी परियोजना के लिए एक अद्वितीय मॉड्यूल मॉड्यूल पथ निर्दिष्ट किया। इस तरह, एक प्रॉक्सी या अन्य उपकरण, यदि आवश्यक हो, तो मेरी परियोजना की फाइलें पा सकते हैं।

go mod init कमांड को कॉल करने के बाद, go mod init डायरेक्टरी मेरे होम डायरेक्टरी में दिखाई दी:

 $ tree ~/go /home/elena/go └── pkg └── mod └── cache └── lock 3 directories, 1 file 

इस स्थिति में, लॉक-फ़ाइल (ट्री के बहुत नीचे) अभी भी खाली है।

go.mod फ़ाइल निम्नलिखित सामग्री के साथ ~/hello go.mod में दिखाई दी:

 module github.com/rumyantseva/hello go 1.13 

यह go.mod कि मेरे मॉड्यूल की निर्भरता के बारे में सभी जानकारी बाद में संग्रहीत की जाएगी।

अब एक बाहरी निर्भरता का उपयोग करते हुए एक आवेदन लिखें। ~/hello निर्देशिका में, मैं main.go फ़ाइल main.go और main.go निम्न कोड लिखता main.go :

 package main import ( "github.com/sirupsen/logrus" ) func main() { logrus.Info("Hello, world!") } 

बेशक "हैलो, दुनिया!" लिखने के लिए वास्तविक जीवन में आप लॉगरस के बिना कर सकते हैं, लेकिन इस उदाहरण में, यह लाइब्रेरी हमें यह पता लगाने में मदद करेगी कि बाहरी निर्भरता की फाइलें कहाँ संग्रहीत हैं।

मैं सरल तरीके से एप्लिकेशन लॉन्च करता हूं:

 $ go run main.go go: finding github.com/sirupsen/logrus v1.4.2 go: downloading github.com/sirupsen/logrus v1.4.2 go: extracting github.com/sirupsen/logrus v1.4.2 go: downloading golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: extracting golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: finding golang.org/x/sys v0.0.0-20190422165155-953cdadca894 INFO[0000] Hello, world! 

एप्लिकेशन के निर्माण और लॉन्च होने से पहले, go mod टूल ने काम किया। उन्होंने मेरे बाहरी निर्भरता github.com/sirupsen/logrus परिभाषित किया, इसका नवीनतम संस्करण v1.4.2 लिया और पारगमन निर्भरता के लिए चला गया।

एक लाइन को go.mod फ़ाइल में go.mod पर निर्भरता के विवरण के साथ जोड़ा गया था:

 module github.com/rumyantseva/hello go 1.13 require github.com/sirupsen/logrus v1.4.2 // indirect 

go.sum फ़ाइल भी दिखाई दी, जिसमें, logrus निर्भरता के हैश के अलावा, logrus निर्भरता के हैश के बारे में जानकारी संग्रहीत है:

 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4= github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE= github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= golang.org/x/sys v0.0.0-20190422165155-953cdadca894 h1:Cz4ceDQGXuKRnVBDTS23GTn/pU5OE2C0WrNTOYK1Uuc= golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= 

निर्भरता कोड स्वयं कहां है? यह ~/go/pkg/mod में पाया जा सकता है। इसके अलावा, निर्भरता के साथ काम करने के लिए चेकसम और अन्य ओवरहेड जानकारी ~/go/pkg में संग्रहीत की जाएगी।

यदि आप पहले से ही go get टूल में आ गए go get , तो आप जानते हैं कि निर्भरता को खींचते समय, यह वास्तव में रिपॉजिटरी को क्लोन करता है (उदाहरण के लिए, git clone साथ)। लेकिन go mod उस तरह से काम नहीं करता है। go mod कोड go mod मुख्य इकाई मॉड्यूल है। मॉड्यूल अभिलेखागार हैं। go mod निर्भरताओं के साथ काम करते समय, यह स्पष्ट रूप से (यदि आपने go mod download कमांड GOPROXY ) या अंतर्निहित (यदि आपने एप्लिकेशन को संकलित करना शुरू किया है) GOPROXY माध्यम से डाउनलोड और GOPROXY अभिलेखागार। आइए देखें कि डिफ़ॉल्ट रूप से गो 1.13 में प्रॉक्सी कैसे सेट है:

 $ go env GOPROXY https://proxy.golang.org,direct 

तो, एक प्रॉक्सी के रूप में जब मेरे "हैलो, वर्ल्ड!" xy.golang.org द्वारा उपयोग किया जाता है। बेशक, इस चर को मॉड्यूल के एक अलग भंडार को चुनकर बदला जा सकता है। उदाहरण के लिए, आप अपनी खुद की आंतरिक प्रॉक्सी कंपनी को तैनात कर सकते हैं, जिसे संग्रहीत किया जाएगा, जिसमें आंतरिक पुस्तकालय भी शामिल हैं, जिसका कोड खुले स्रोत में प्रकाशित नहीं किया गया था।

सामान्य तौर पर, अगर मैं एक नया प्रोजेक्ट शुरू कर रहा हूं और गो मॉड्यूल्स का उपयोग करने में कोई आपत्ति नहीं है, तो मुझे GOPATH बारे में कुछ भी पता नहीं GOPATH । जरूरत पड़ने पर Go अपने आप ही ~/go Go डायरेक्टरी बना लेगा।

GOPATH की आवश्यकता कब है?

यदि आप मूल रूप से गो मॉड्यूल (उदाहरण के लिए, एक विरासत परियोजना में) का उपयोग नहीं करते हैं, तो GOPATH साथ अधिक स्पष्ट कार्य से दूर होना इतना सरल नहीं हो सकता है।

यह देखने के लिए कि मेरे प्रोजेक्ट का क्या होगा, अगर मैं go mod का उपयोग नहीं करने का निर्णय लेता हूं, तो फ़ाइलों को हटा दें ~/hello/go.mod और ~/hello/go.sum । मैं उस सिस्टम की स्थिति पर लौटने के लिए ~/go हटा दूंगा जो मेरे पास बहुत शुरुआत में था:

 rm -rf ~/go ~/hello/go.mod ~/hello/go.sum 

केवल main.go फ़ाइल ~/hello main.go में बनी हुई है। अब क्या होगा अगर मैं इसे go run साथ चलाने की कोशिश करूं?

 $ go run main.go main.go:4:2: cannot find package "github.com/sirupsen/logrus" in any of: /usr/lib/go-1.13/src/github.com/sirupsen/logrus (from $GOROOT) /home/elena/go/src/github.com/sirupsen/logrus (from $GOPATH) 

यहाँ वे हैं, ये डरावने GOROOT और GOPATH :)

आवेदन को संकलित करने के लिए, मुझे GOPATH में निर्भरता को खींचने की आवश्यकता है। मैं अच्छे पुराने go get साथ ऐसा करता हूं:

 $ go get -v github.com/sirupsen/logrus github.com/sirupsen/logrus (download) created GOPATH=/home/elena/go; see 'go help gopath' get "golang.org/x/sys/unix": found meta tag get.metaImport{Prefix:"golang.org/x/sys", VCS:"git", RepoRoot:"https://go.googlesource.com/sys"} at //golang.org/x/sys/unix?go-get=1 get "golang.org/x/sys/unix": verifying non-authoritative meta tag golang.org/x/sys (download) golang.org/x/sys/unix github.com/sirupsen/logrus 

क्या हुआ? सबसे पहले, go get ~/go निर्देशिका ( GOPATH रूप में निर्दिष्ट) बनाया। फिर निर्भरता वाले रिपॉजिटरी को क्लोन करने की प्रक्रिया शुरू हुई। यह अजीब बात है कि क्लोनिंग रिपॉजिटरी जब हम go mod को डाउनलोड करने और अनपैक करने के लिए go mod का उपयोग करते हैं, तो विकल्प की तुलना में काफी धीमा दिखता है। हालाँकि, निर्भरता कोड अब ~/go/src/ अंदर पाया जा सकता है।

वैसे, मेरे स्वच्छ उबंटू इंस्टॉलेशन पर अभी भी कोई गिट क्लाइंट नहीं था, और काम पर go get मुझे इसे स्थापित करना था।

मैंने एप्लिकेशन लॉन्च किया:

 $ go run main.go INFO[0000] Hello, world! 

यह काम करता है!

यह सिर्फ आवेदन के स्तर पर है, मैं अब बाहरी निर्भरता के संस्करण को ट्रैक नहीं करता हूं। क्या होगा यदि, किसी भेद्यता के कारण, कुछ बिंदु पर github.com/sirupsen/logrus रिपॉजिटरी में वह लकड़हारा नहीं है जिसकी मुझे उम्मीद थी, लेकिन कुछ दुर्भावनापूर्ण कोड? जल्दी या बाद में, मुझे अभी भी निर्भरता के साथ काम करने के लिए एक उपकरण की आवश्यकता है, और अगर किसी कारण से गो मॉड्यूल फिट नहीं होते हैं, तो आपको कुछ और देखना होगा ...

निष्कर्ष

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

यदि आप एक नई परियोजना शुरू कर रहे हैं, तो गो मॉड्यूल का प्रयास करें! निर्भरता के साथ काम करने के लिए पुराने दृष्टिकोण पर लौटने से ही कुछ गलत होता है। वैसे, यदि आप प्रोजेक्ट के अंदर सभी निर्भरता को संग्रहीत करना पसंद करते हैं, तो गो मॉड्यूल विक्रेता मोड का समर्थन करता है।

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

वैसे, 7 अक्टूबर को गोलंगकॉन्फ सम्मेलन में, विशेष गतिविधियों में से एक के रूप में, हम एक विशेषज्ञ क्षेत्र की योजना बना रहे हैं जहां कोई भी सम्मेलन कार्यक्रम समिति के सदस्यों और रूसी गो-समुदाय के उत्साही लोगों के बारे में कोई भी प्रश्न पूछ सकता है। जाओ स्थापित करें? व्यसनों से निपटें? माइक्रोसेवा लिखिए? यह हमारे लिए है!