Go: cmd/go: मान लें GOPATH=$HOME/go अगर सेट नहीं है तो

/सीसी @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

मुझे यह पसंद है, लेकिन क्या हमारे पास "गोकोड" के लिए कोई विशिष्ट प्राथमिकता है और "गोपथ" जैसी कोई चीज़ नहीं है?

कितने लोग पहले से ही GOPATH=$HOME/gocode का उपयोग कर रहे हैं? मुझे ऐसा लगता है कि बहुत से नहीं। इससे पता चलता है कि यह गलत डिफ़ॉल्ट है।

"gocode" में लोकप्रिय टूल github.com/nsf/gocode के साथ खोज इंजन और अन्य भ्रम होंगे।

क्या हमारे पास इस बारे में कोई जानकारी है कि अधिकांश लोग क्या करते हैं?

मैं स्वयं GOPATH=$HOME/gopath का उपयोग करता हूं।

यदि आप वर्तमान में GOPATH=$HOME . का उपयोग करते हैं, तो यहां अच्छा प्रदर्शन करें

यदि आप वर्तमान में GOPATH=$HOME/gopath . का उपयोग करते हैं तो यहां अच्छा प्रदर्शन करें

यदि आप वर्तमान में GOPATH=$HOME/gocode . का उपयोग करते हैं तो यहां अच्छा प्रदर्शन करें

क्या मुझे @golang पर ट्विटर पोल करना चाहिए?

@campoy , अच्छा लगता है। शायद इस बग में सभी को आमंत्रित करने से बेहतर है।

कैसे के बारे में $HOME/go (जो मैं उपयोग करता हूं)।

यह भी देखें: http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$होम: 8.9%
$होम/गो: ५०.६%
अन्य : 40.5%

मैं वास्तव में चाहता हूं कि मैंने इसके लिए और विकल्पों को विभाजित किया हो।

मतदान शुरू: https://twitter.com/golang/status/781189567437164544

बुधवार 28 सितंबर, 2016, 10:51 पूर्वाह्न एडवर्ड मुलर सूचनाएं @github.com . पर
लिखा था:

कैसे के बारे में $HOME/go (जो मैं उपयोग करता हूं)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -250244110, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

यहां कॉलम I भी देखें: https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid =1525640201

@freeformz ,

$HOME/go पाथ गो सोर्स कोड के साथ विरोधाभासी है (go.googlesource.com/go) अक्सर चेक आउट किया जाता है। यह बुरा है कि समुदाय ने इस स्थान को GOPATH के लिए डिफ़ॉल्ट के रूप में आशीर्वाद दिया :( मुझे चिंता है कि अगर कोई अपना GOPATH सेट करना भूल जाता है और गो टूल चलाता है, तो यह उनकी वर्तमान विकास निर्देशिका को गड़बड़ कर देगा।

@rakyll प्रत्येक के लिए, बस यह इंगित करना चाहता था कि मैं और कई अन्य लोग क्या उपयोग करते हैं। go.googlesource.com/go मेरे सिस्टम पर /usr/local/go.git में चेक आउट किया गया है।

कितने लोग पहले से ही GOPATH=$HOME/gocode का उपयोग कर रहे हैं? मुझे ऐसा लगता है कि बहुत से नहीं। इससे पता चलता है कि यह गलत डिफ़ॉल्ट है।

रिकॉर्ड के लिए मैं GOPATH=$HOME उपयोग करता हूं, लेकिन मुझे लगा कि यह बहुत विवादास्पद होगा और इस प्रस्ताव के लक्ष्य से अलग होगा जो कि नए उपयोगकर्ता के अनुभव को बेहतर बनाना है।

@freeformz , मुझे लगता है कि हमें मौजूदा विहित पथों की परवाह करने की ज़रूरत नहीं है जो $HOME के ​​बाहर हैं। GOPATH के लिए डिफ़ॉल्ट कहीं $HOME में होगा और न्यूनतम आवश्यकता यह होनी चाहिए कि यह किसी भी महत्वपूर्ण मौजूदा पथ के साथ संघर्ष न करे।

$HOME/gocode मेरे लिए विदेशी लगता है लेकिन यह एक बहुत अच्छा विकल्प हो सकता है।

बात यह है कि यह कम मायने रखता है कि डिफ़ॉल्ट क्या है, बस एक है।

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

जब GOPATH=$GOROOT स्पष्ट रूप से भ्रमित न हो तो go कमांड अपने रास्ते से हट जाता है; मुझे यकीन है कि निहित सेटिंग पर भी लागू करने के लिए एक ही तर्क बनाया जा सकता है। इसलिए मैं $ HOME/गलती से जाने के बारे में बहुत चिंतित नहीं हूं।

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

@rsc मैं उस डिफ़ॉल्ट को GOPATH=$HOME होना पसंद करूंगा क्योंकि इसका मतलब है कि $GOPATH/bin उनके रास्ते में होगा (कम से कम अधिकांश लिनक्स वितरण पर, डार्विन के बारे में निश्चित नहीं है)।

$GOPATH=$HOME/go भी एक अच्छा विकल्प है और जिनके पास कंपाइलर का स्रोत चेक आउट है, वे पहले ही GOPATH=something else सेट कर चुके होंगे, इसलिए संघर्ष की कोई संभावना नहीं है।

स्पष्ट होने के लिए, जब मैंने कहा तो मैं फ़्लिप करने की कोशिश नहीं कर रहा था

बात यह है कि यह कम मायने रखता है कि डिफ़ॉल्ट क्या है, बस एक है।

इसके बजाय इस प्रस्ताव के लक्ष्य पर जोर देने की कोशिश करना है कि गो टूल $GOPATH लिए एक डिफ़ॉल्ट मान का उपयोग करें, जब कोई प्रदान नहीं किया जाता है क्योंकि यह भाषा के लिए कई नए लोगों के लिए भ्रम और निराशा का निरंतर स्रोत है।

मैं ऑटो सूँघने पर हूँ क्योंकि यह एक प्रमुख उपयोग के मामले में विफल रहता है, जो है:

1. मैंने गो स्थापित किया है, मैंने वास्तव में गो इंस्टॉलेशन डॉक्स नहीं पढ़ा है, बस रेपो के रीडमे पर जो कहा है उसका पालन किया है जिसने कहा brew install go
2. मैंने go get github.com/thething/theproject चलाया है
3. अब मुझे $GOPATH सेट नहीं करने के बारे में एक त्रुटि मिलती है। वो क्या है? मैं बस इस कार्यक्रम को चलाना चाहता था जिसके बारे में किसी ने ट्वीट किया था!

GOPATH=$HOME/go SGTM का एक डिफ़ॉल्ट मान, यह मानते हुए कि हम डिफ़ॉल्ट पर निर्णय लेते हैं न कि ऑटो-सूँघने के दृष्टिकोण पर।

जब GOPATH=$GOROOT स्पष्ट रूप से भ्रमित न हो तो go कमांड अपने रास्ते से हट जाता है; मुझे यकीन है कि निहित सेटिंग पर भी लागू करने के लिए एक ही तर्क बनाया जा सकता है।

बहुत अच्छा लगता है।

डार्विन के बारे में निश्चित नहीं

डार्विन पर नहीं।

यदि यह नवागंतुकों के लिए है, तो मैं GOPATH=$HOME विरुद्ध सलाह दूंगा क्योंकि इससे उनकी होम निर्देशिका में केवल एक बनाम तीन निर्देशिकाएं बन जाएंगी। मैं ऐसे सॉफ़्टवेयर के लिए उत्सुक नहीं हूं जो मेरे घर को आवश्यकता से अधिक प्रदूषित करता है।

@mvdan मैं समझता हूं और आपकी प्रतिक्रिया थी कि मैंने GOPATH=$HOME का प्रस्ताव क्यों नहीं दिया।

यदि _I_ व्यक्तिगत रूप से मेरे GOPATH को $HOME पर सेट करना चाहता है, तो वह विकल्प मेरे लिए उपलब्ध रहेगा, और यदि यह प्रस्ताव गो 1.8 के लिए स्वीकार किया जाता है तो मुझे कोई परिवर्तन नहीं करना होगा।

@davecheney

GOPATH=$HOME/gocode . के मान के लिए डिफ़ॉल्ट

विंडोज़ पर कोई डिफ़ॉल्ट होम वैरिएबल नहीं है। आप विंडोज़ पर क्या करने का प्रस्ताव करते हैं?

मुझे वह डिफ़ॉल्ट GOPATH=$HOME होना अच्छा लगेगा क्योंकि इसका मतलब है कि $GOPATH/bin उनके रास्ते में होगा

मैं अपने पथ में $GOPATH/bin होने के बारे में हमेशा चिंतित रहता हूं। go get वहां अन्य लोगों के प्रोग्राम इंस्टॉल करता है। क्या हम वास्तव में चाहते हैं कि नया गो उपयोगकर्ता अपने पथ में कहीं इंटरनेट से यादृच्छिक प्रोग्राम स्थापित करे?

एलेक्स

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

यदि ऐसा कोई पथ मौजूद नहीं है, तो C:/gocode मान लें।

GOPATH = $ HOME पर मेरी टिप्पणी के लिए, जबकि यह मेरी व्यक्तिगत प्राथमिकता है और जारी रहेगी, मैं मानता हूं कि यह एक डिफ़ॉल्ट मान के लिए एक विवादास्पद विकल्प है और इस तरह इसे प्रस्तावित मूल्य के रूप में नहीं सुझाया गया है।

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

मैं पैकेज प्रबंधन कार्य समूह के साथ जो हो रहा है, उसके पाश में नहीं हूं, लेकिन मैं एक बहुत दूर के भविष्य की कल्पना कर सकता हूं जहां GOPATH पूरी तरह से समाप्त हो गया है।

उस ने कहा, भले ही GOPATH निकट भविष्य में कुछ समय के लिए गायब हो जाए, फिर भी डिफ़ॉल्ट सेट करने में मूल्य हो सकता है। अगर हमें लगता है कि GOPATH के गायब होने की संभावना है, तो इससे कोई फर्क नहीं पड़ता कि हम इसे किस पर सेट करते हैं।

मैंने ऊपर जो पढ़ा है, उससे कुछ आम सहमति है कि:

1. डिफ़ॉल्ट रूप से, GOPATH=$HOME बहुत आक्रामक है।
2. डिफ़ॉल्ट में कहीं न कहीं स्ट्रिंग go शामिल होनी चाहिए (संभवतः एक उपसर्ग के रूप में)।

मुझे इस बात की चिंता नहीं है कि GOPATH मुख्य गो रेपो (यानी, GOPATH == GOROOT) का क्लोन है। गो रेपो की जाँच करने वाले लोगों के पास एक GOPATH सेट होने की संभावना है। गो टूल वैसे भी संघर्ष का पता लगाएगा, जैसा कि वह आज करता है।

इसे ध्यान में रखते हुए, सबसे संक्षिप्त डिफ़ॉल्ट $HOME/go , जो मुझे लगता है कि काफी उचित है।

मुझे लगता है कि आधार पथ की कुछ धारणा है जहां दस्तावेज़ और सेटिंग्स संग्रहीत हैं।

मुझे ऐसी बात की जानकारी नहीं है। शायद अन्य विंडोज उपयोगकर्ता यहां टिप्पणी करेंगे।

यदि ऐसा कोई पथ मौजूद नहीं है, तो C:/gocode मान लें।

आप इसके बजाय सी: गोकोड चाहते हैं।
चीजों को C:\ की जड़ में रखना मुझे सही नहीं लगता। क्या आप GOPATH को Linux पर /gocode पर सेट करने की अनुशंसा करेंगे?
लेकिन, यह देखते हुए कि विंडोज इंस्टालर पहले से ही गो इन सी: गो, सी: गोकोड फॉर गोपाथ स्थापित करता है, कम से कम सुसंगत है।

एलेक्स

लेकिन, यह देखते हुए कि विंडोज इंस्टालर पहले से ही गो इन सी: गो, सी: गोकोड फॉर गोपाथ स्थापित करता है, कम से कम सुसंगत है।

प्रत्येक उपयोगकर्ता के लिए GOPATH प्रदान नहीं किया जाना चाहिए? यूनिक्स के समान होने के लिए, %USERPROFILE%\gocode , मुझे लगता है।

https://goo.gl/xAsgEj . पर गो+ पोल

जब मैंने लंबे समय तक $HOME/go-programs जैसे कुछ का उपयोग किया, तो मैंने GOPATH को $HOME में बदल दिया। तो, अब मेरे पास निम्न संरचना है:

$होम/बिन
$होम/पीकेजी
$होम/स्रोत/
$HOME/src/github.com/user/some_github_project
$HOME/src/some_project

यह संरचना अधिक सामान्य है और इसका उपयोग अन्य भाषाओं या परियोजनाओं और जीथब के साथ उपयोग करने के लिए भी किया जा सकता है। उदाहरण के लिए मेरे पास $ HOME/src/बातचीत है (इसे घर/स्रोत/मार्कडाउन फाइलों के लिए वार्ता पढ़ें) या कुछ भाषाओं में अन्य परियोजनाएं (जैसे $ HOME/src/github.com/user/html) लेकिन स्रोत भी हैं और मेरे पास एक है जीथब पत्राचार के साथ या बिना कई परियोजना स्रोतों के लिए जगह।

बिन या पीकेजी को गन्दा माना जा सकता है लेकिन मुझे लगता है कि यह इतना कष्टप्रद नहीं है। कई भाषाओं का उपयोग करने वाले लोगों के लिए कई स्रोत फ़ोल्डर रखना अधिक गन्दा है।

इसलिए, मेरे दृष्टिकोण से सबसे अच्छा GOPATH स्थान $HOME है।

मैं अपने GOPATH के रूप में $HOME/gocode का उपयोग कर रहा हूं।
मैं $HOME/go के खिलाफ हूं क्योंकि कभी-कभी आपके पास मूल विशेषाधिकार नहीं होता है और आपको अपनी होम निर्देशिका के तहत गो को स्थापित करने की आवश्यकता होती है। ऐसे मामले में, मुझे लगता है कि $HOME/go GOROOT के लिए सबसे अच्छा होगा।
इसलिए हमें $HOME/go से GOPATH के रूप में कुछ अलग उपयोग करना चाहिए।

@hnakamur वापस जब मैंने मैन्युअल रूप से (अब उबंटू मेक का उपयोग कर) स्थापित किया, तो मैंने इसे $HOME/bin/go-${go_version} ($HOME/bin/go to $HOME/bin/go-$ से एक सिमलिंक के साथ) में डाल दिया। {संस्करण}/बिन/गो, इसलिए मुझे अपना $PATH संपादित नहीं करना पड़ा)

@tbroyer यह आला है। मुझे लगता है कि अधिकांश उपयोगकर्ता अतिरिक्त कॉन्फ़िगरेशन या सेटिंग्स नहीं चाहते हैं। मेरी राय में, ~/bin का उपयोग पहले से ही (मेरी तरह) अपनी स्क्रिप्ट या बायनेरिज़ डालने के लिए किया जाता है। और मुझे लगता है कि ~/bin (~/src, ~/pkg) गो बायनेरिज़ को हटाना थोड़ा मुश्किल है।

मैं अपने GOPATH के लिए $HOME का उपयोग करता हूं।
GOPATH को ऑटो क्यों सेट करते हैं, अच्छी जानकारी के साथ चेतावनी क्यों नहीं बढ़ाते यदि GOPATH मौजूद नहीं है तो इसे कैसे सेट करें?

GOPATH को ऑटो क्यों सेट करते हैं, अच्छी जानकारी के साथ चेतावनी क्यों नहीं बढ़ाते यदि GOPATH मौजूद नहीं है तो इसे कैसे सेट करें?

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

मैं क्रिस और एंड्रयू से सहमत हूं: यदि कोई डिफ़ॉल्ट GOPATH होने जा रहा है, तो यह केवल $ HOME/go होना चाहिए, गोपथ या गोकोड नहीं। _अधिकांश_ उपयोगकर्ताओं के पास वहां चेक आउट गो वितरण नहीं है (और आज जो भी करता है वह पहले से ही GOPATH सेट करता है, इसलिए यह उन्हें परेशान नहीं करेगा)। डिफ़ॉल्ट को नए उपयोगकर्ताओं के लिए समझ में आने की आवश्यकता है, उन्नत लोगों के लिए नहीं, और अधिकांश उपयोगकर्ताओं के लिए $HOME/go बहुत मायने रखता है।

जाना ने गो कमांड के भ्रमित होने के बारे में चिंता जताई अगर $HOME/go एक गो वितरण होता है, लेकिन गो कमांड पहले से ही आकस्मिक GOPATH=$GOROOT के लिए जाँच करता है। यह जांचना आसान है कि क्या यह सच है जब GOPATH को भी निहित रूप से सेट किया गया है। वास्तव में, $HOME/go/src/cmd/go/alldocs.go देखने के लिए चेक को बढ़ाना भी आसान होगा, जब GOROOT!=$HOME/go लेकिन $HOME/go करता है तब भी भ्रम से बचने के लिए एक गो वितरण शामिल करें।

GOPATH के लिए $HOME/go एक अच्छा विकल्प नहीं है। आइए व्यवहार का एक सरल अभ्यास करें... नए उपयोगकर्ता डिफ़ॉल्ट को सर्वोत्तम अभ्यास की तरह आसानी से मान सकते हैं। मान लें कि मैं एक नया उपयोगकर्ता हूं, मुझे डिफ़ॉल्ट को एक बुरी चीज क्यों माननी चाहिए? गोलांग को स्थापित करने का सबसे आसान (और सबसे अच्छा?) तरीका $HOME में अनपैक करना है क्योंकि इस पद्धति के साथ कंपाइलर हमेशा अंतिम संस्करण में होता है और रूट अधिकारों की आवश्यकता नहीं होती है ताकि आप आसानी से मान सकें कि कई उपयोगकर्ताओं के पास कंपाइलर होगा $ HOME/go में। जब मैं बस नहीं कर सकता तो मुझे कंपाइलर को/usr/स्थानीय में क्यों स्थानांतरित करना चाहिए?
इससे अधिक वे प्रोजेक्ट बना सकते हैं और इस फ़ोल्डर में प्रोजेक्ट क्लोन कर सकते हैं। इसलिए, उनके पास एक गन्दा फ़ोल्डर होगा और थोड़ी सी लापरवाही से वे अपने प्रोजेक्ट फ़ोल्डर को एक नए गोलंग पुनर्स्थापना के साथ आसानी से हटा सकते हैं।
साथ ही, विंडोज़ उपयोगकर्ताओं के पास c:go डिफ़ॉल्ट रूप से है।

मुझे $HOME/gopath पसंद है। यह कहता है कि यह क्या है।
"gopath" के लिए Google पर पहला परिणाम सही पृष्ठ है।

यदि कोई डिफ़ॉल्ट अपनाया जाता है, तो क्या func GOPATH() string फ़ंक्शन को runtime जोड़ा जा सकता है? अभी कोई os.Getenv() उपयोग कर सकता है, लेकिन डिफ़ॉल्ट रूप से यह इतना आसान नहीं होगा।

@btracey , GOPATH एक सूची है, एक मान नहीं। filepath.SplitList उपयोग करें। साथ ही, GOPATH रनटाइम का कार्य नहीं है। यह केवल cmd/go ।

पश्चगामी संगतता के लिए हमें संभवतः प्रक्रिया में GOPATH सेट करना होगा'
पर्यावरण यदि कोई सेट नहीं है।

30 सितंबर 2016 को 08:10 बजे, ब्रेंडन ट्रेसी नोटिफिकेशन @github.com
लिखा था:

यदि कोई डिफ़ॉल्ट अपनाया जाता है, तो क्या एक func GOPATH() स्ट्रिंग फ़ंक्शन जोड़ा जा सकता है
रनटाइम के लिए? अभी कोई os.Getenv() का उपयोग कर सकता है, लेकिन डिफ़ॉल्ट रूप से it
इतना आसान नहीं होगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -250605418, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

आप सही कह रहे हैं @bradfitz। @adg द्वारा प्रस्तावित समाधान मेरे सभी

यह एक दिलचस्प शिकन है। मैं इसे वर्तमान में विफल होते हुए देख सकता हूं जब नहीं
GOPATH सेट है, लेकिन तब भी जब GOPATH में कई मान हों, और फिर
ऐसा मामला है जहां एप्लिकेशन एक मशीन पर बनाया गया है और इसे तैनात किया गया है
एक और।

मैं GOPATH के इस प्रयोग को खारिज नहीं करना चाहता, मैं इसका दर्द समझता हूं
आपके आवेदन के लिए समर्थन फाइलों का पता लगाने में सक्षम होने के नाते, लेकिन मैं चाहूंगा
यह समझने के लिए कि यह उपयोग कितना व्यापक है, और वर्तमान कैसे है
कार्यान्वयन उन मुद्दों से निपटते हैं जिन पर मैंने ऊपर प्रकाश डाला है।

शुक्र, 30 सितंबर 2016, 08:35 पर ब्रेंडन ट्रेसी नोटिफिकेशन @github.com ने लिखा:

आप सही कह रहे हैं https://github.com/bradfitz। समाधान
@adg द्वारा प्रस्तावित https://github.com/adg मेरे सभी उपयोगों को पूरा करेगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -250611813, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

मेरा उपयोग सामान्य नहीं है। मैं वैज्ञानिक अनुसंधान करता हूं, और मैंने इसे न केवल gopath/src और gopath/bin , बल्कि gopath/data और gopath/results भी बहुत प्रभावी पाया है। यह परिणाम फ़ाइलों (गीगाबाइट्स) की प्रतिलिपि किए बिना स्रोत फ़ाइलों को एक नए सिस्टम पर कॉपी करना आसान बनाता है। नई प्रणाली (क्लस्टर कहें) नई परिणाम फाइलें उत्पन्न करती है, और मैं उन परिणामों को केंद्रीय स्थान पर कॉपी कर सकता हूं। तब gopath = os.Getenv("GOPATH") कहना वास्तव में आसान है, और किसी फ़ाइल को filepath.Join(gopath, "results", "projectname", result.json) जैसी किसी चीज़ में सहेजना है।

धन्यवाद। स्पष्ट होने के लिए मेरा मतलब यह नहीं था कि आपका उपयोग गलत था या
गलत, मैं सिर्फ GOPATH wrt के इस उपयोग को समझना चाहता था
बाधाओं पर मैंने प्रकाश डाला।

शुक्र, 30 सितंबर 2016, 09:09 पर ब्रेंडन ट्रेसी नोटिफिकेशन @github.com ने लिखा:

मेरा उपयोग सामान्य नहीं है। मैं वैज्ञानिक शोध करता हूं, और मैंने पाया है
यह न केवल गोपथ/स्रोत और गोपथ/बिन के लिए बहुत प्रभावी है, बल्कि
गोपथ/डेटा और गोपथ/परिणाम। इससे स्रोत को कॉपी करना आसान हो जाता है
(गीगाबाइट) को कॉपी किए बिना एक नई प्रणाली में फ़ाइलें
परिणाम फ़ाइलें। नई प्रणाली (जैसे क्लस्टर) नई परिणाम फ़ाइलें उत्पन्न करती है,
और मैं उन परिणामों को एक केंद्रीय स्थान पर कॉपी कर सकता हूं। यह वास्तव में आसान है
फिर gopath = os.Getenv ("GOPATH") कहें, और फ़ाइल को फ़ाइलपथ जैसी किसी चीज़ में सहेजें। शामिल हों (गोपथ,
"परिणाम", "प्रोजेक्टनाम", परिणाम.जेसन)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -250617618, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

यदि आप वर्तमान में GOPATH=$HOME/.go उपयोग करते हैं, तो यहां पर विचार करें

@davecheney कोई अपराध नहीं हुआ, बस उपयोगी होने के लिए पर्याप्त संदर्भ प्रदान करना चाहता था।

आइए इस चर्चा से समर्थन फ़ाइलों को खोजने के लिए कृपया GOPATH का उपयोग छोड़ दें।

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

रन-टाइम पर संबंधित फाइलों को खोजने से संबंधित: #12773

एक बार फिर चर्चा को दूषित करने के लिए क्षमा करें @rsc , लेकिन @ Randall77 , #12773 का उपयोग करना अधिक कठिन है, बस इस मुद्दे पर सीधे काम करना। विशिष्ट कोड जिसे फ़ाइल की आवश्यकता होती है (या फ़ाइल को सहेजने के लिए) बहुत आगे बढ़ सकता है, और मैं इनपुट/आउटपुट के लिए एक निश्चित स्थान चाहता हूं ताकि रिफैक्टरिंग से स्वतंत्र (और अलग) रह सकें।

यह समस्या GOPATH के संभावित डिफ़ॉल्ट मान के बारे में है। यह GOPATH के वैकल्पिक उपयोगों के बारे में _not_ है।

यदि इस परिवर्तन के लिए लक्षित उपयोगकर्ता केवल वही हैं जो केवल चाहते थे
गो में लिखा गया एक नया प्रोग्राम इंस्टॉल करें, न कि वे जो वास्तव में चाहते हैं
जाओ लिखो, फिर हम प्रति-उपयोगकर्ता निर्देशिका में क्लोनिंग प्राप्त करने के बारे में क्या करते हैं
$TMPDIR, और $GOPATH सेट नहीं होने पर बाइनरी को $PWD पर छोड़ दें? (जाहिर है
यह केवल जाने के लिए समझ में आता है आयात.पथ/के लिए/ए/कमांड, अगर यह नहीं है
आदेश, जाओ $GOPATH सेट किए बिना विफल हो जाना चाहिए)

बाहरी व्यक्ति के लिए, यह बहुत मायने रखता है, ठीक उसी तरह जैसे किसी फ़ाइल को wget करना।

एक बार जब उपयोगकर्ता गो कोड लिखना शुरू करना चाहता है, तो उसे सीखना चाहिए कि कैसे सेट करना है
गोपथ ठीक से।

मैं $HOME/go के खिलाफ हूं क्योंकि कभी-कभी आपके पास मूल विशेषाधिकार नहीं होता है और आपको अपनी होम निर्देशिका के तहत गो को स्थापित करने की आवश्यकता होती है। ऐसे मामले में, मुझे लगता है कि $HOME/go GOROOT के लिए सबसे अच्छा होगा।

यदि आप एक Linux सिस्टम पर हैं, तो मैं तर्क दूंगा कि $GOROOT के लिए सबसे अच्छी जगह $HOME/.local/opt/go में हो सकती है, $HOME/go में नहीं, यह इस पर निर्भर करता है कि आप $HOME/.local के उद्देश्य की व्याख्या कैसे करते हैं। , क्योंकि केवल $HOME/.local/share (दर्पण/usr/स्थानीय/शेयर के रूप में दिखाई देने वाला) को XDG बेस डायरेक्टरी स्पेक में परिभाषित किया गया है: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest। एचटीएमएल.

कोई यह भी तर्क दे सकता है कि GOPATH / GOBIN (लिनक्स पर) के लिए सबसे अच्छा डिफ़ॉल्ट होना चाहिए:
GOPATH=$XDG_DATA_HOME/go, या $HOME/.local/share/go
GOBIN=$HOME/.local/bin

हालांकि नए उपयोगकर्ताओं के लिए शायद यह समझना सबसे आसान नहीं है? और यह यह भी स्पष्ट नहीं करेगा कि विंडोज़ पर सबसे अच्छा तरीका क्या है। $HOME/go और $USERPROFILE/go व्यावहारिक प्रतीत होता है।

कृपया, _कृपया_ इस थ्रेड को कैननिकल लिनक्स पथ नामों और भंडारण स्थानों की चर्चा में बदलने न दें। यह उत्पादक नहीं है, और मुझे लगता है कि यह चर्चा पहले ही डेव चेनी की मूल पोस्ट से बहुत दूर भटक चुकी है।

मुझे यह भी यकीन नहीं है कि वास्तविक पूर्ण स्थान इतना मायने रखता है, मुझे लगता है कि इस सभी धागे को वास्तव में यह तय करने की ज़रूरत है कि "क्या हम एक डिफ़ॉल्ट गोपथ चाहते हैं?" (ऐसा लगता है कि यह एक कम या ज्यादा जबरदस्त हां है) और "क्या इसे सिस्टमव्यापी साझा किया जाना चाहिए, या उपयोगकर्ता के लिए स्थानीय होना चाहिए" (अब तक अधिकांश चर्चा स्थानीय के बारे में रही है)। उसके बाद, जो भी उपकरण $HOME/gocode या $HOME/go या /usr/share/go/ या जो कुछ भी वे चाहते हैं वह चुन सकते हैं जो पीआर की समीक्षा करने वाले के लिए उचित लगता है, और चीजें शायद बहुत ठीक रहती हैं।

मुझे लगता है कि अनुमति के मुद्दों के कारण एक सिस्टमवाइड GOPATH एक गैर-स्टार्टर है।

मैं

सिस्टम वाइड पथ, बेहतर या बदतर के लिए, GOROOT है, जो विकृत करता है
जैसे डेबियन "सिस्टम वाइड" पैकेज स्थापित करने के लिए उपयोग कर रहे हैं, बेहतर या के लिए
और भी बुरा।

एक व्यापक प्रणाली GOPATH इस प्रस्ताव के दायरे से बाहर है, यह प्रस्ताव
लॉग इन उपयोगकर्ता के मान से प्राप्त पथ की अनुशंसा करता है।

मंगलवार को, 4 अक्टूबर 2016, 08:52 एंड्रयू गेरैंड नोटिफिकेशन @github.com ने लिखा:

मुझे लगता है कि अनुमति के मुद्दों के कारण एक सिस्टमवाइड GOPATH एक गैर-स्टार्टर है।

मैं

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -251238251, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

कृपया, कृपया इस धागे को कैननिकल लिनक्स पथ नामों और भंडारण स्थानों की चर्चा में बदलने न दें। यह उत्पादक नहीं है

ठीक है, चलो नहीं। मेरा मुख्य बिंदु वास्तव में एक और कारण को इंगित करना था कि $ HOME/go शायद GOPATH डिफ़ॉल्ट के रूप में समस्याग्रस्त नहीं है, क्योंकि यह संभवतः गो (उर्फ GOROOT) के स्थानीय उपयोगकर्ता इंस्टॉल के लिए सबसे "मुहावरेदार लिनक्स" पथ नहीं है।

इसके अलावा, मुझे विश्वास है कि डिफ़ॉल्ट GOPATH के लिए XDG_CACHE_HOME का उपयोग करने से पहले इस पर

$घर/काम.......

@adg @quentinmit @rsc इस प्रस्ताव के लिए अगले चरण क्या हैं?

वास्तव में यहां कुछ होता हुआ देखना अच्छा लगेगा। यह मेरी कक्षाओं में लगातार दर्द का बिंदु है। कोई भी डिफ़ॉल्ट (यहां तक ​​​​कि $home/go जिससे मैं असहमत हूं :)) किसी से भी बेहतर नहीं है।

$HOME/go यह होगा। कोई एक सबसे अच्छा उत्तर नहीं है लेकिन यह छोटा और प्यारा है, और उस नाम को चुनने में केवल एक समस्या हो सकती है यदि $HOME/go पहले से मौजूद है, जो केवल उन विशेषज्ञों के लिए खुश होगा जो पहले से ही स्थापित हो चुके हैं और GOPATH को समझेंगे।

काम कौन करना चाहता है?

मुझे निश्चित रूप से इस पर काम करने में खुशी होगी।

@campoy , क्या आप इसे <= इस शुक्रवार को कर सकते हैं?

मैं ऐसा कहूंगा, हाँ @bradfitz । ऐसा करने के लिए कोड की एक बड़ी मात्रा की तरह नहीं लगता है।
मैं कल शुरू कर सकता हूँ।

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

हे महान लोग! मैं

@robpike क्या आपने #17271 में मेरे वैकल्पिक प्रस्ताव पर भी विचार किया? मैं यह समझना चाहूंगा कि इस प्रस्ताव को बेहतर क्यों समझा गया

यह एक अच्छा विचार नहीं होगा कि गो इंस्टाल डायरेक्टरी और वर्कस्पेस डायरेक्टरी के नाम समान हों यानी go क्योंकि:

१) एक भोले-भाले उपयोगकर्ता के लिए कार्यक्षेत्र को दूषित/प्रदूषित करना बहुत आसान है यदि उपयोगकर्ता होम निर्देशिका में tar -xzf go$VERSION.$OS-$ARCH.tar.gz करता है

2) /usr/local (रूट के रूप में स्थापित नहीं करना चाहता) पर स्थापित नहीं होने पर एक नए उपयोगकर्ता का डिफ़ॉल्ट अनुभव सहज नहीं होगा क्योंकि यह प्रवाह होगा:
go$VERSION.$OS-$ARCH.tar.gz . डाउनलोड करें
tar -xzf go$VERSION.$OS-$ARCH.tar.gz -> $HOME/go . में इंस्टाल हो जाता है
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something -> cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath फेंकता है

@कृष्णश्रीनिवास यह मेरी समझ है कि यदि GOROOT=$HOME/go , तो यह डिफ़ॉल्ट या तो नहीं होगा या go त्रुटि करेगा क्योंकि GOROOT और GOPATH समान नहीं हो सकते। ऐसे मामलों में, जैसा कि पहले कहा गया है, यह अपेक्षा की जाती है कि उपयोगकर्ता अपना स्वयं का GOPATH सेट करने में सक्षम है।

@mvdan सही, नए उपयोगकर्ताओं के लिए जो इंस्टॉलेशन के लिए रूट विशेषाधिकारों का उपयोग नहीं करना चाहते हैं (और इसलिए ~/go में गो इंस्टॉल करने का उच्च मौका) हम चीजों को प्राप्त करना और चलाना आसान नहीं बना रहे हैं क्योंकि उन्हें स्पष्ट रूप से करना होगा GOPATH को किसी और चीज़ पर सेट करें। इसे आसानी से ठीक किया जा सकता है यदि डिफ़ॉल्ट GOPATH या तो ~/gopath या ~/gocode . है

गैर-रूट स्थापना के लिए, यदि नए उपयोगकर्ताओं को डिफ़ॉल्ट GOPATH=~/go का लाभ उठाना है, तो स्थापना दस्तावेज़ को थोड़ा और जटिल बनाना होगा, उपयोगकर्ताओं को स्पष्ट रूप से tar -C विकल्प का उपयोग करने के लिए कह कर ताकि इसे स्थापित न किया जा सके। ~/go

@rasky मैं # 17271 और इस प्रस्ताव को ऑर्थोगोनल

मैं @कृष्णाश्रीनिवास से सहमत हूं। मेरे पास रूट अनुमतियां नहीं थीं, इसलिए मैंने सिर्फ $HOME/go पर जाने की कोशिश नहीं की। मैंने अपना $GOPATH=$HOME/gowork भी सेट किया था।

@krishnasrinivas @joegrasse कोई सही समाधान है। GOPATH स्वयं सेट करना आसान है, और मुझे उम्मीद है कि अधिकांश लोग यही करेंगे। यहां मुद्दा यह है कि हमें उन लोगों के लिए क्या करना चाहिए जो Go में सबसे नए हैं। ये सामान्य लोग नहीं हैं जो कस्टम स्थानों में अपना स्वयं का गो वितरण स्थापित कर रहे हैं। जो लोग कस्टम स्थान में गो को स्थापित करने का तरीका जान सकते हैं, वे यह पता लगा सकते हैं कि GOPATH कैसे सेट किया जाए।

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

फिर, कोई सही समाधान नहीं है, लेकिन कुछ चुनना बुद्धिमानी है।

@ianlancetaylor मैं पूरी तरह से सहमत हूं कि कुछ चुनना चाहिए। मेरा मानना ​​​​है कि ./go को अनदेखा करना, $ HOME/go पर डिफ़ॉल्ट होना, सबसे अच्छा विकल्प नहीं हो सकता है।

@ianlancetaylor GOPATH=$HOME/gopath उपरोक्त कारणों से GOPATH=$HOME/go से बेहतर डिफ़ॉल्ट है।

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

@joegrasse @krishnasrinivas "पर एक नज़र डालें एक कस्टम स्थान पर स्थापित कर रहा है "।

यदि आप /usr/local/go अलावा किसी अन्य स्थान पर अतारांकित हैं - अनुमति के कारणों से या अन्यथा - तो GOROOT को भी सेट करना, या स्रोत से संकलित करना आवश्यक हो जाता है।

जब तक ऐसा है, प्रस्तावित $HOME/go पर $HOME/gopath, आदि का उपयोग करने में कोई लाभ नहीं है।

आप मानते हैं कि नए उपयोगकर्ता tar.gz से इंस्टॉल करना पसंद करते हैं। मैं नहीं का हवाला दे सकता हूँ
संख्याएं, लेकिन विश्वास करें कि आपका उत्तर Linux संस्थापनों पर आधारित है, जो
गो के लिए तीसरा सबसे लोकप्रिय स्थापना लक्ष्य हैं।

मंगलवार, 25 अक्टूबर 2016, 20:28 कृष्णा श्रीनिवास नोटिफिकेशन @github.com . पर
लिखा था:

@mvdan https://github.com/mvdan सही, उन उपयोगकर्ताओं के लिए जो नहीं चाहते हैं
स्थापना के लिए रूट विशेषाधिकारों का उपयोग करें (और इसलिए स्थापित करने की उच्च संभावना
अंदर जाओ ~/go) हम चीजों को ऊपर उठाना और चलाना आसान नहीं बना रहे हैं
उन्हें स्पष्ट रूप से GOPATH को किसी और चीज़ पर सेट करना होगा। यह हो सकता है
यदि GOPATH या तो ~/gopath या ~/gocode

गैर-रूट स्थापना के लिए, यदि नए उपयोगकर्ताओं को डिफ़ॉल्ट का लाभ उठाना है
GOPATH=~/go तो दस्तावेज़ीकरण को थोड़ा और जटिल बनाना होगा
उपयोगकर्ताओं को टार-सी विकल्प का उपयोग करने के लिए कहने के लिए स्पष्टीकरण द्वारा ताकि इसे यहां स्थापित न किया जा सके
~/गो

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -255984498, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

सभी डॉक्स को भी अपडेट करने की आवश्यकता है। शायद यही काम का बड़ा हिस्सा है।

25 अक्टूबर 2016 को 10:14 बजे, फ्रांसेस्क कैम्पॉय नोटिफिकेशन @github.com
लिखा था:

मैं ऐसा कहूंगा, हाँ। ऐसा करने के लिए कोड की एक बड़ी मात्रा की तरह नहीं लगता है।
मैं कल शुरू कर सकता हूँ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -255892314, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

मैं ऐसा कहूंगा, हाँ। ऐसा करने के लिए कोड की एक बड़ी मात्रा की तरह नहीं लगता है।
मैं कल शुरू कर सकता हूँ।

सोम 24 अक्टूबर, 2016 को शाम 4:05 बजे ब्रैड फिट्ज़पैट्रिक नोटिफिकेशन @github.com
लिखा था:

@campoy https://github.com/campoy , क्या आप इसे <= इस शुक्रवार से पहले कर सकते हैं?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -255890668, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

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

"या, जैसा कि आपने $GOPATH/bin को अपने PATH में जोड़ा है, बस बाइनरी नाम टाइप करें:"

या

"GOPATH के तहत पैकेज बनाएं, mkdir -p $GOPATH/src/github.com/user/hello"

GOPATH से जुड़े बिना और यह जानें कि यह क्या है, गो में थर्ड पार्टी पैकेज प्राप्त करने के अलावा कुछ भी करना लगभग असंभव है। यदि हम go env माध्यम से डिफ़ॉल्ट पथ की रिपोर्ट कर सकते हैं, तो इसे दस्तावेज़ों में संदर्भित करना आसान होगा।

हो सकता है कि $HOME/go/... को इसके बजाय (या विंडोज़ पर समकक्ष) प्रतिस्थापित किया जा सके?

जैसा कि आपने अपने PATH में $HOME/go/bin जोड़ा है (या $GOPATH/bin अगर GOPATH सेट है)...

शायद किसी बिंदु पर दस्तावेज़ीकरण व्यक्तियों से न केवल PATH पर्यावरण चर सेट करने की अपेक्षा कर सकता है, बल्कि GOPATH को $HOME/go पर भी सेट कर सकता है। बेमानी होने के बावजूद, यह उपयोगकर्ता को GOPATH के बाद के संदर्भों के लिए तैयार करता है।

प्रारंभिक दस्तावेज़ीकरण डिफ़ॉल्ट मान सकता है और पर्यावरण चर का बिल्कुल भी उल्लेख नहीं कर सकता है।

आप मानते हैं कि नए उपयोगकर्ता tar.gz से इंस्टॉल करना पसंद करते हैं। मैं नहीं का हवाला दे सकता हूँ
संख्याएं, लेकिन विश्वास करें कि आपका उत्तर Linux संस्थापनों पर आधारित है, जो
गो के लिए तीसरा सबसे लोकप्रिय स्थापना लक्ष्य हैं।

आप सही कह रहे हैं, मेरी राय लिनक्स इंस्टॉलेशन के प्रति पक्षपाती है। मैं देख सकता हूं कि नए उपयोगकर्ता जो गो/usr/लोकल में इंस्टॉल करते हैं, ~/go ~/gopath की तुलना में अधिक पहचानने योग्य निर्देशिका नाम हो सकता है

प्रारंभिक दस्तावेज डिफ़ॉल्ट मान सकते हैं और उल्लेख नहीं कर सकते हैं
पर्यावरण चर बिल्कुल?

हाँ, उम्मीद है कि GOPATH की स्थापना के बारे में सभी विचलित करने वाली बहस को आगे बढ़ाया जा सकता है
स्थापित दस्तावेज के एक परिशिष्ट में, जैसा कि हम GOROOT . के लिए करते हैं
वर्तमान में।

बुधवार को, २६ अक्टूबर २०१६, ०६:०१ नाथन यंगमैन नोटिफिकेशन @github.com ने लिखा:

हो सकता है कि $HOME/go/... को इसके बजाय प्रतिस्थापित किया जा सकता है (या समतुल्य on
खिड़कियाँ)?

जैसा कि आपने अपने PATH में $HOME/go/bin जोड़ा है (या $GOPATH/bin अगर GOPATH है तो)
सेट)...

शायद किसी बिंदु पर दस्तावेज़ीकरण व्यक्तियों से यह अपेक्षा नहीं कर सकता है
केवल पाथ पर्यावरण चर सेट करें, लेकिन GOPATH को $HOME/go पर भी सेट करें।
बेमानी होने के बावजूद, यह बाद के दस्तावेज़ीकरण को स्पष्ट करता है।

प्रारंभिक दस्तावेज डिफ़ॉल्ट मान सकते हैं और पर्यावरण का उल्लेख नहीं कर सकते हैं
चर बिल्कुल?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256142424, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

प्रारंभिक दस्तावेज़ीकरण डिफ़ॉल्ट मान सकता है और पर्यावरण चर का बिल्कुल भी उल्लेख नहीं कर सकता है।

एसजीटीएम

दो प्रकार के गो उपयोगकर्ता हैं:

• उपयोगकर्ता जो अभी-अभी मौजूदा पैकेज प्राप्त करते हैं
• उपयोगकर्ता जो गो डेवलपर हैं

डिफ़ॉल्ट GOPATH पहले समूह के मामले को ठीक कर रहा है। हम अभी भी GOPATH से संबंधित निर्देशों को डेवलपर्स के सामने आने वाले डॉक्स के लिए रख सकते हैं। स्थापना को अब GOPATH की स्थापना का उल्लेख नहीं करना चाहिए या हमारे पास @davecheney उल्लेख के रूप में एक परिशिष्ट हो सकता है।

किसी ऐसे व्यक्ति के रूप में जिसे गो के कारण ~/bin/go का नाम बदलना पड़ा, मैं यह सुझाव देना चाहता हूं कि जो कुछ भी डिफ़ॉल्ट है, यदि यह पहले से मौजूद है तो इसमें एक .dotfile होना चाहिए ताकि यह इंगित किया जा सके कि यह वास्तव में गो का ~/go है। जब ~/go मौजूद नहीं है, तो go इसे बना सकता है, .dotfile बना सकता है, और भविष्य के रन इसे ढूंढ सकते हैं। अगर मैं स्पष्ट रूप से GOPATH को ~/go पर सेट करता हूं तो कोई .dotfile आवश्यक नहीं होगा क्योंकि कोई डिफ़ॉल्ट मान उपयोग नहीं किया जा रहा है।

डॉटफाइल मौजूद है। यह $HOME/go के अंदर src/निर्देशिका है।

बुध, 26 अक्टू वर्ष 2016 पर, 7:59 RalphCorderoy [email protected] लिखा है:

किसी ऐसे व्यक्ति के रूप में जिसे गो के कारण ~/bin/go का नाम बदलना पड़ा, मुझे सुझाव देना पसंद है
कि जो कुछ भी डिफ़ॉल्ट है, यदि वह पहले से मौजूद है तो उसके पास होना चाहिए a
.dotfile यह इंगित करने के लिए कि यह वास्तव में गो का ~/go है। जब ~/go मौजूद न हो,
go इसे बना सकता है, .dotfile बना सकता है, और भविष्य के रन इसे ढूंढ सकते हैं। अगर मुझे
स्पष्ट रूप से GOPATH को ~/go पर सेट करें तो कोई .dotfile आवश्यक नहीं होगा क्योंकि no
डिफ़ॉल्ट मान का उपयोग किया जा रहा है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256173981, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019 में इस मुद्दे का उल्लेख है।

भले ही कुछ प्रोग्रामर पर्यावरण चर के बारे में नहीं जानते हों, वे
कम से कम _variables_ से परिचित होना चाहिए। मुझे लगता है कि हमें इसकी आवश्यकता होगी
दस्तावेज़ों में किसी कार्यस्थान के स्थान का वर्णन करने के लिए किसी चीज़ का उपयोग करना, और
स्ट्रिंग $GOPATH हो सकता है।

२६ अक्टूबर २०१६ को ०६:२४ बजे, जाना बुरकु डोगन नोटिफिकेशन @github.com
लिखा था:

प्रारंभिक दस्तावेज डिफ़ॉल्ट मान सकते हैं और पर्यावरण का उल्लेख नहीं कर सकते हैं
चर बिल्कुल।

एसजीटीएम

दो प्रकार के गो उपयोगकर्ता हैं:

• उपयोगकर्ता जो अभी-अभी मौजूदा पैकेज प्राप्त करते हैं
• उपयोगकर्ता जो गो डेवलपर हैं

डिफ़ॉल्ट GOPATH पहले समूह के मामले को ठीक कर रहा है। हम अभी भी रख सकते हैं
डेवलपर्स-सामना करने वाले दस्तावेज़ों के लिए GOPATH-संबंधित निर्देश। NS
स्थापना को अब GOPATH की स्थापना का उल्लेख नहीं करना चाहिए या हम
@davecheney https://github.com/davecheney . के रूप में एक परिशिष्ट हो सकता है
उल्लेख।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256149104, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

धन्यवाद इरादा है, कृपया मूल प्रस्ताव देखें।

असल में अब हम कह सकते हैं "गो गेट सोर्स को फोल्डर में डाउनलोड कर लेगा"
कॉल करें, go/src/github.com/Foo/Bar अपने होम डाइरेक्टरी के अंदर"

बुधवार को, २६ अक्टूबर २०१६, ०६:०१ नाथन यंगमैन नोटिफिकेशन @github.com ने लिखा:

हो सकता है कि $HOME/go/... को इसके बजाय प्रतिस्थापित किया जा सकता है (या समतुल्य on
खिड़कियाँ)?

जैसा कि आपने अपने PATH में $HOME/go/bin जोड़ा है (या $GOPATH/bin अगर GOPATH है तो)
सेट)...

शायद किसी बिंदु पर दस्तावेज़ीकरण व्यक्तियों से यह अपेक्षा नहीं कर सकता है
केवल पाथ पर्यावरण चर सेट करें, लेकिन GOPATH को $HOME/go पर भी सेट करें।
बेमानी होने के बावजूद, यह बाद के दस्तावेज़ीकरण को स्पष्ट करता है।

प्रारंभिक दस्तावेज डिफ़ॉल्ट मान सकते हैं और पर्यावरण का उल्लेख नहीं कर सकते हैं
चर बिल्कुल?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256142424, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Hacktoberfest के अंतिम सप्ताह के लिए यह एक अच्छा मुद्दा होगा

डॉटफाइल मौजूद है। यह $HOME/go . के अंदर src/निर्देशिका है

"src" सामान्य होने का तरीका है "यह गो द्वारा डिफ़ॉल्ट GOPATH के रूप में बनाया गया था" dotfile।

आप किस चीज को रोकने की कोशिश कर रहे हैं?

बुध, 26 अक्टूबर, 2016 को 9:20 AM पर, RalphCorderoy [email protected]
लिखा था:

डॉटफाइल मौजूद है। यह $HOME/go . के अंदर src/निर्देशिका है

"src" सामान्य होने का तरीका है "इसे डिफ़ॉल्ट GOPATH के रूप में बनाया गया था
गो" डॉटफाइल.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256194536, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$HOME/go यह होगा।

यह विंडोज यूजर्स के लिए क्या होगा?

एलेक्स

विंडोज उपयोगकर्ता %USERPROFILE%\go उपयोग करेंगे, जैसा कि डॉकर यहां करता

@davecheney , मैं दो घंटे पहले जो कहा था उसे रोकने की कोशिश कर रहा हूं: https://github.com/golang/go/issues/17262#issuecomment -256173981

जाना एक सामान्य शब्द है। मेरे पास ~/bin/go था। लोग गो खेलते हैं और गो खेलने के साथ स्रोत कोड रखते हैं। नाबिंग ~/डिफ़ॉल्ट रूप से जाना जब यह पहले से मौजूद है क्योंकि इसमें src होता है तो यह कठोर होता है। यदि ~/go मौजूद नहीं है तो गो नाम को पकड़ सकता है, निर्देशिका बना सकता है, इसे गोलंग के रूप में एक महत्वपूर्ण डॉटफाइल के साथ मुहर लगा सकता है, उदाहरण के लिए golang.org डोमेन नाम पर आधारित।

यही समस्या है, और एक संभावित समाधान, वैसे भी। यहां तक ​​कि अगर समाधान सही नहीं है, तो इसका मतलब यह नहीं है कि समस्या मौजूद नहीं है।

मैं $ HOME/group वोट देता हूँ

धन्यवाद।

क्या हम GOPATH डिफ़ॉल्ट का उपयोग ~/.gosrc ?

क्या हम GOPATH डिफ़ॉल्ट का उपयोग ~/.gosrc ?

यह लिनक्स और ओएस एक्स पर डिफ़ॉल्ट रूप से छिपा होगा, और विंडोज़ में दिखाई देगा। GOPATH को छुपाने की प्रेरणा क्या होगी?

डिफॉल्ट की वैल्यू पर चर्चा एक महीने पहले हुई थी। $HOME/go पर निर्णय किया जा चुका है और पहले से ही लागू किया जा रहा है। उस विषय पर वापस जाने से धागा असहनीय रूप से लंबा हो जाएगा।

लोग गो खेलते हैं और गो खेलने के साथ स्रोत कोड रखते हैं।

मैं वास्तव में आपका अनुसरण नहीं कर रहा हूं, लेकिन यह देखते हुए कि आपने GOPATH को सेट कर दिया होगा
कुछ और पहले से ही, आप पर कोई प्रभाव नहीं पड़ेगा।

बुध, 26 अक्टूबर, 2016 को 9:43 AM पर, RalphCorderoy [email protected]
लिखा था:

@davecheney https://github.com/davecheney , मैं क्या रोकने की कोशिश कर रहा हूँ I
दो घंटे पहले कहा: #17262 (टिप्पणी)
https://github.com/golang/go/issues/17262#issuecomment -256173981

जाना एक सामान्य शब्द है। मेरे पास ~/bin/go था। फोल्क्स गो खेलते हैं और सोर्स कोड रखते हैं
जाने के साथ खेलने के लिए। नाबिंग ~/डिफ़ॉल्ट रूप से जाना जब यह पहले से मौजूद है
क्योंकि ऐसा होता है कि src असभ्य होता है। अगर ~/go मौजूद नहीं है तो Go
नाम को पकड़ सकते हैं, निर्देशिका बना सकते हैं, इसे गोलंग के रूप में मुहर लगा सकते हैं a
महत्वपूर्ण डॉटफाइल, उदाहरण के लिए golang.org डोमेन नाम पर आधारित।

यही समस्या है, और एक संभावित समाधान, वैसे भी। भले ही समाधान
सही नहीं है, इसका मतलब यह नहीं है कि समस्या मौजूद नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256199766, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

हाय @davecheney , यह समस्या आपके द्वारा ~/gocode का प्रस्ताव देने से शुरू हुई थी। समय के साथ, यह ~/go बन गया। @robpike ने ऊपर कहा "यह केवल उस नाम को चुनने में एक समस्या हो सकती है यदि $ HOME/go पहले से मौजूद है, जो केवल उन विशेषज्ञों के लिए खुश होगा जो पहले से ही स्थापित हो चुके हैं और GOPATH को समझेंगे"। मुझे लगता है कि इतने लंबे समय तक गोलंग में लिपटे रहने से, आप सामूहिक रूप से भूल रहे हैं कि "गो" शब्द कितना सामान्य है, और इसके अन्य अर्थ कैसे हैं, जैसे बोर्ड गेम।

यह परिवर्तन नए लोगों को Go में लाने के उद्देश्य से है और उनमें से कुछ गैर-गो उपयोग के लिए ~/go पहले से ही ले सकते हैं। मैं सुझाव दे रहा हूं कि यदि गो साथ आता है, तो पाता है कि GOPATH सेट नहीं है, और कोई ~/go मौजूद नहीं है, तो यह नाम को हथियाने के लिए इसे बना सकता है। लेकिन अगर ~/go मौजूद है तो इसे केवल तभी इसका उपयोग करना चाहिए जब यह बता सके कि इसे पहले GOPATH- कम आमंत्रण में बनाया गया है। मैंने सुझाव दिया कि इस ध्वज के रूप में एक डॉटफाइल बनाया जाए। आपने कहा ~/go/src उस झंडे के रूप में काम करेगा। मेरी आपत्ति यह है कि src स्वयं प्रोग्रामर के बीच असामान्य नहीं है, अर्थात वे जो गो को स्थापित कर सकते हैं। एक असामान्य डॉटफाइल, जैसे ~/go/.default-gopath इस संभावित टकराव से बचा जाता है।

यदि वे मैन्युअल रूप से ~/go for Go बनाते हैं और GOPATH के बिना go चलाते हैं तो यह ~/go का उपयोग नहीं करेगा क्योंकि dotfile गायब है। मुझे लगता है कि यह ठीक है क्योंकि गो इंस्टॉलेशन को सेट करना शुरू करके उन्हें जारी रखना चाहिए, GOPATH सेट करना। वे सरल नहीं हैं "पैकेज स्थापित करें, रन गो (1)" केस जिसे लक्षित किया जा रहा है।

यदि इनमें से किसी को भी समस्या नहीं माना जाता है तो कोई बात नहीं। लेकिन जब तक आप शिकायत करते हैं कि आप मेरी बात को नहीं समझते हैं, तब तक मैं इसे समझाने की कोशिश करता रहूंगा।

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

इसके साथ ही, मुझे खुशी है कि _a_ पथ को चुना गया है क्योंकि मैं इसे अभ्यास के बिंदु के रूप में देखता हूं।

आपकी चिंताओं के लिए, मेरा सुझाव है कि आप https://go-review.googlesource.com/#/c/32019/ का अनुसरण

@RalphCorderoy , आपकी चिंता बोर्ड गेम हैकिंग के लिए ~/go निर्देशिका वाले गो-द-बोर्ड-गेम प्रोग्रामर हैं?

रोब और रस बहुत ही डॉटफाइल विरोधी हैं। यदि उत्तर में डॉटफाइल्स (या सिम्लिंक) शामिल हैं, तो उत्तर देने की तुलना में समस्या को बताना बेहतर है।

@bradfitz , हाँ, ~/gogame खिलाड़ियों के लिए पहले से मौजूद है, और आगे ~/go/src मौजूदा है क्योंकि वे प्रोग्रामर गोगम प्लेयर हैं अन्यथा वे गो के साथ नहीं रहेंगे। (मेरे पास ~/शतरंज/src जैसा होता है।)

एडीजी का सारांश तर्क https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c ठीक लगता है, और अगर यह मौजूद नहीं है तो मैं ~/go बनाने के पक्ष में हूं, लेकिन test -d ~/go/src यदि कोई GOPATH नहीं है, तो ~/go का उपयोग करने के लिए

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

@RalphCorderoy मुझे लगता है कि CL ३२०१९ में देखभाल और डबल जांघिया की मात्रा गेम-ऑफ-गो-प्रोग्रामर के छोटे सेट के लिए संभावित असुविधा के लिए पर्याप्त से अधिक है, जिन्होंने _हैव नॉट_ का उपयोग संस्करण 1.8 से पहले किया था और _हैव नॉट_ सेट GOPATH _और_ भी गो, भाषा सीखने लगे हैं।

go टूल किसी भी गैर-गो कोड को हटाने या भ्रष्ट करने वाला नहीं है, आपको _few_ स्थितियों में बस थोड़ा भ्रमित करने वाला संदेश मिलेगा। इसे समझाने के लिए, गो टूल $GOPATH/src के शीर्ष पर गो स्रोत नहीं बनाएगा क्योंकि वह कोड आयात योग्य पैकेज के भीतर नहीं है। इसके अतिरिक्त, इस परिवर्तन का दूसरा लक्ष्य स्रोत को डाउनलोड करने के लिए एक डिफ़ॉल्ट स्थान प्रदान करके go get कुछ कोड को आसान बनाना है, इसलिए _if_ ~/go/src में गेम-ऑफ-गो स्रोत कोड था

मुझे लगता है कि आप जिस स्थिति के बारे में चिंतित हैं, वह बहुत ही असंभव है, और ऊपर दिए गए स्पष्टीकरण से और कम हो गया है।

( GOPATH=$HOME खिलाफ सिर्फ एक संभावित वैध तर्क): क्या goimports के प्रदर्शन को संबोधित किया गया है? मुझे .goimport_ignore फ़ाइल के बारे में कुछ याद है। अन्यथा लोकप्रिय संपादकों का प्रदर्शन प्रभावित हो सकता है।

इस प्रकार, GOPATH!=$HOME एक टकराव-मुक्त/गैर-प्रदूषित विकल्प होने की संभावना है और प्रदर्शनकारी होना चाहिए।

@davecheney go get मेरे पास ~/go/{bin,src,pkg} से बाहर निकलने के लिए बकवास होगा और इंटरनेट पर मिली लाइन को चिपकाने के लिए यह एक अच्छा परिचय नहीं होगा।

@RalphCorderoy कृपया समझें कि इस परिवर्तन का लक्ष्य नए गो उपयोगकर्ताओं के लिए इसे आसान बनाना है - यह आप नहीं हैं - आपके पास पहले से ही $GOPATH सेट है, क्योंकि आपके पास 1.1 से गो के प्रत्येक संस्करण के साथ _हैव टू_ है। गो-द-गेम उपयोगकर्ताओं और _potential_ गो-द-प्रोग्रामिंग-भाषा उपयोगकर्ताओं के बीच ओवरलैप बहुत छोटा है। मुझे नहीं लगता कि कोई मुद्दा होगा।

@RalphCorderoy जिस स्थिति का आप वर्णन कर रहे हैं वह दुर्लभ है, और किसी भी यादृच्छिक वेबसाइट से शेल कमांड चलाने वाले को यह अपेक्षा नहीं होनी चाहिए कि उनके डिस्क मिटाए नहीं जाएंगे, अकेले कुछ फ़ाइलों को डाउनलोड करें और एक नामांकित निर्देशिका में चारों ओर फेरबदल करें। (संपादित करें: विचार करें शराब ऑटो बनाने और संशोधित .wine एक शब्द हम एक विशेष पेय के लिए उपयोग उपयोगकर्ता के घर निर्देशिका में उपयोगकर्ता कुछ है क्या होगा अगर किसी और वहाँ सब के बाद, "शराब" है।?।)

"गो" भाषा और "गो" बोर्ड गेम के बीच नामकरण टकराव निश्चित रूप से समझा और जाना जाता है। फाइलसिस्टम एक साझा संसाधन है, टकराव होते हैं और अपरिहार्य हैं।

@davecheney , कृपया मुझे बताना बंद करें कि यह परिवर्तन मेरी मदद करने के उद्देश्य से नहीं है क्योंकि मैं एक नया गो उपयोगकर्ता नहीं हूं। इससे पहले कि आप इसे इंगित करना शुरू करें, मैं हमेशा इसके बारे में जानता हूं। मैं यह भी समझता हूं कि आपकी स्थिति लेन है (प्रतिच्छेदन (मौजूदा-~/go, GOPATH-less)) चिंता का विषय होने के लिए बहुत छोटा है।

गो-गेट स्पू को साफ करने के बाद ~/go क्योंकि वह जानता था कि सामान्य रूप से वहां क्या नहीं था, फिर उसे यह देखने के लिए शोध करना होगा कि $ HOME के ​​तहत कमांड ने और क्या किया हो सकता है सफाई की आवश्यकता थी।

सदस्यता समाप्त

मुझे खेद है अगर मैंने आपको कोई अपराध किया है। मैं अब पत्राचार नहीं करना चाहता
इस मुद्दे पर आपके साथ। धन्यवाद।

शुक्र, अक्टूबर 28, 2016 को 3:28 AM पर, RalphCorderoy [email protected]
लिखा था:

@davecheney https://github.com/davecheney , कृपया मुझे यह बताना बंद करें
परिवर्तन का उद्देश्य मेरी मदद करना नहीं है क्योंकि मैं नया गो उपयोगकर्ता नहीं हूं। मेरे पास है
इससे पहले कि आप इसे इंगित करना शुरू करें, हमेशा इसके बारे में जागरूक रहें। मैं भी
समझें कि आपकी स्थिति लेन है (प्रतिच्छेदन (मौजूदा-~/go, GOPATH-less)) is
चिंता का विषय होने के लिए बहुत छोटा।

गो-गेट स्पू को साफ करने के बाद ~/go क्योंकि उसे पता होगा कि क्या
आम तौर पर वहां नहीं था, फिर उसे यह देखने के लिए शोध करना होगा कि और क्या है
यदि अधिक सफाई की आवश्यकता होती है तो कमांड (ओं) ने $HOME के ​​तहत किया हो सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/17262#issuecomment -256697043, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

डेवचेनी, नहीं, अपराध नहीं। बस एक ही मैदान को ढकते रहने का कोई मतलब नहीं है।

बस सोच रहा था - यदि $HOME सेट नहीं है तो अपेक्षित व्यवहार क्या है?

जबकि मैंने कभी ऐसी प्रणाली पर काम नहीं किया है जहां ऐसा था, ऐसा लगता है कि किसी ने किसी कारण से अपने डिफ़ॉल्ट एनवी वर्र्स को संशोधित किया है, और इस किनारे के मामले को लगातार संभाला जाना चाहिए।

मुझे लगता है कि यह वर्तमान में $GOPATH='' मूल्यांकन करता है; क्या इसका मतलब यह है कि यह वर्तमान कार्यशील निर्देशिका का उपयोग कर रहा है?

वर्तमान कार्यशील निर्देशिका का उपयोग करें

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

• यदि GOPATH सेट नहीं है:
  
  
  
  • यदि केवल एक या दो, लेकिन सभी नहीं, ~/{bin,pkg,src} मौजूद हैं:
  
  
  • उन्हें GOPATH सेट करना होगा, pkg असामान्य है
  
  
  • या तो सभी या कोई भी मौजूद नहीं है:
  
  
  • सुनिश्चित करें कि वे सभी मौजूद हैं
  
  
  • गोपथ=$(पीडब्ल्यूडी)
  
  

इस पर मेरी मिश्रित भावनाएँ हैं, लेकिन मेरी प्रचलित भावना (किसी ऐसे व्यक्ति के रूप में जिसने $GOPATH सेट किया है) यह है कि go get व्यवहार "निर्धारक" होना चाहिए और हमेशा $GOPATH तहत चीजों को स्थापित करना चाहिए - एक सुसंगत और अच्छी तरह से प्रलेखित गंतव्य।

भले ही मैं इस परिवर्तन से अप्रभावित हूं, यह अजीब लगता है कि go get कमांड जारी होने पर कार्यशील निर्देशिका के आधार पर विभिन्न स्थानों पर चीजें डाउनलोड करेगा। मुझे पता है कि यह वही है जो wget , npm install , और अन्य उपकरण करते हैं, लेकिन यह एक सुसंगत $GOPATH मूल्य के विचार से प्रस्थान जैसा लगता है (जो कि मैं कैसे इस परिवर्तन की भावना की व्याख्या की)।

यदि यह इस मुद्दे के दायरे से बाहर है, तो मैं केवल एक त्रुटि से बाहर निकलने और आउटपुट करने का प्रस्ताव करता हूं यदि $HOME वास्तव में सेट नहीं है।

मैंने 5 नए प्रोग्रामर्स को पढ़ाया है जो जावा दुनिया से तीसरी दुनिया के देश में आए हैं .. वे सभी निश्चित रूप से GOPATH के बारे में भ्रमित थे। हेक, मैं भी तब था जब मैंने गो 1 के रिलीज़ होने से पहले वापस शुरुआत की थी। मैं व्यक्तिगत रूप से "$HOME/gopath" का उपयोग करता हूं, लेकिन मेरा सुझाव है कि "go get" कमांड उन्हें एक ऐसे गो ब्लॉग की ओर इंगित करता है जो उनके ऑपरेटिंग सिस्टम के लिए एक गो पथ बनाने के तरीके पर स्पष्ट है। हमें बस इतना ही चाहिए। "गो गेट" कमांड द्वारा कुछ मार्गदर्शन जो एक कल्पना नहीं है .. लेकिन एक बहुत ही सरल ब्लॉग पोस्ट !!

जाहिर है मेरा मतलब है जब कोई GOPATH सेट नहीं किया गया है। वर्तमान में प्रदर्शित होने वाले त्रुटि संदेश को बस अपडेट करें। गोद लेने की दर पहले से ही है .. वर्तमान Google इट अप पद्धति के बजाय बस थोड़ी सी मदद की ज़रूरत है जो नए काम कर रहे हैं।

@einthusan मुझे लगता है कि यह https://golang.org/doc/code.html#GOPATH पर बहुत अच्छी तरह से प्रलेखित है, लेकिन मुझे नहीं पता कि गो के साथ शुरुआत करने वाले कितने लोग वास्तव में इस पृष्ठ को पढ़ते हैं।

स्पैम के लिए क्षमा करें .. कुछ गुगल करने के बाद .. मुझे लगता है कि "गो गेट" को उपयोगकर्ता को यह कहते हुए संकेत देना चाहिए कि "कोई GOPATH सेट नहीं किया गया है ... क्या आप वर्तमान कार्यशील निर्देशिका को अपने अस्थायी GOPATH के रूप में उपयोग करना चाहेंगे?" (हाँ नही)

@einthusan , cmd/go इंटरैक्टिव प्रॉम्प्ट करने के लिए कोई उदाहरण नहीं है।

यदि नया डिफ़ॉल्ट GOPATH $HOME/go है। क्या लोग उम्मीद नहीं करेंगे कि यह https://hub.docker.com/_/golang/ उसी व्यवहार को अपनाएगा?

@cescoferraro यह उस छवि के अनुरक्षकों के लिए एक प्रश्न है। इसे "आधिकारिक" के रूप में लेबल किए जाने के बावजूद, यह परियोजना गो से संबद्ध नहीं है।

अनसेट $HOME के बारे में मेरे अपने प्रश्न का उत्तर देना/प्रतिक्रिया देना:

वर्तमान कार्यान्वयन में (सीएल ऊपर लिंक किया गया है), $GOPATH डिफ़ॉल्ट रूप से "" यदि $HOME सेट नहीं है: https://go-review.googlesource.com/#/ c/32019/11/src/go/build/build.go मुझे लगता है कि यह वर्तमान व्यवहार के अनुरूप है।

मेरा मानना ​​​​है कि यह बढ़त का मामला बहुत ही असंभव है क्योंकि $HOME हमेशा सामान्य लॉगिन सत्र में सेट होता है, जो कि अधिकांश गो प्रोग्रामर के मामले में होता है। हालांकि मैं व्यक्तिगत रूप से _like_ व्यवहार को स्पष्ट रूप से स्पष्ट करता हूं, ऐसा लगता है कि कोई "दुष्प्रभाव" नहीं है (जैसे काम करने वाले डीआईआर में चीजों को स्थापित करना)। यदि मैं गलत हूं तो मुझे सही करों। :)

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

GOPATH=$(pwd)

export GOPATH=$(pwd) सेट करना परियोजनाओं के बीच स्विच करना आसान बनाता है

इस परिवर्तन के लिए मेरा प्रस्तावित व्यवहार:

पर्यावरण चर

• यदि GOPATH सेट किया गया है तो उपकरण हमेशा की तरह व्यवहार करता है
• अन्यथा, हम HOME ( home for plan9, USERPROFILE for windows) पर्यावरण चर की जांच करते हैं।
  
  
  
  • यदि वह env वेरिएबल सेट नहीं है तो GOPATH भी सेट नहीं किया जाएगा: इसका मतलब है कि "go get" cannot download, $GOPATH not set. साथ विफल हो जाएगा
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• अन्यथा GOPATH को $HOME/go ( $home/go , %USERPROFILE%\go ) के रूप में सेट किया जाएगा।

> unset GOPATH
> go env GOPATH
/Users/campoy/go

गोपथ निर्माण

वर्तमान में यदि $GOPATH मौजूद नहीं है तो यह तब बनाया जाता है जब हम go get import/path निष्पादित करते हैं। यह नहीं बदलेगा।

एकमात्र परिवर्तन यह है कि यदि उपयोगकर्ता वातावरण में $GOPATH सेट नहीं है (यानी echo $GOPATH कोई मूल्य प्रदर्शित नहीं करता है) तो यह सुनिश्चित करने के लिए एक अतिरिक्त जांच की जाती है कि डिफ़ॉल्ट मान स्वीकार्य है:

• यदि GOPATH सेट नहीं है और कोई डिफ़ॉल्ट मान नहीं बनाया गया है: आदेश विफल हो जाएगा

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

• यदि डिफ़ॉल्ट $GOPATH मौजूद नहीं है तो एक चेतावनी प्रदर्शित की जाएगी जिसमें बताया गया है कि निर्देशिका बनाई गई थी, और अधिक जानकारी के लिए go help gopath ओर इशारा करते हुए।

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

• यदि डिफ़ॉल्ट $GOPATH मौजूद है:
  
  
  
  • और यह एक निर्देशिका नहीं है: आदेश विफल हो जाएगा (जैसा कि उसने पहले किया था)
  
  

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

• और यह या तो एक खाली निर्देशिका या एक निर्देशिका है जिसमें src नामक उपनिर्देशिका है, आदेश सफल होगा (कोई चेतावनी नहीं)

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

• और यह src नामक उपनिर्देशिका के बिना एक गैर-खाली निर्देशिका है, कमांड विफल हो जाएगी

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

इसलिए जब भी डिफ़ॉल्ट GOPATH का उपयोग करके कोई निर्देशिका बनाई जाती है तो केवल एक नई चेतावनी शामिल की जाती है।

@campoy व्यवहार प्रस्ताव बहुत अच्छा लग रहा है।

लेकिन एक उन्नत उपयोगकर्ता के रूप में मैं फिर से जानना चाहता हूं कि हममें से कितने लोग $HOME/go को दैनिक आधार पर GOPATH रूप में गंभीरता से उपयोग करते हैं? मैं यह भी सोच रहा था कि शायद GOPATH को एक पायथन कार्य निर्देशिका पर वर्चुअल एनवी शुरू करने के समान सेट करने के लिए एक गो कमांड होना चाहिए।

चूंकि मैं कई परियोजनाओं पर काम करता हूं, इसलिए मैं आमतौर पर ऐसा कुछ करता हूं:

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

@jinmatt
यह परिवर्तन केवल अनसेट GOPATH के व्यवहार को संशोधित करता है, यही परिवर्तन का दायरा है।
समुदाय पहले ही $HOME/go पर एक समझौते पर पहुंच चुका है।

अगर आपको $HOME/go पसंद नहीं है, तो बस GOPATH को जो भी मूल्य आप पसंद करते हैं उसे सेट करें (उदाहरण के लिए $HOME मेरे मामले में)।

डिजाइन स्केच के लिए धन्यवाद।

1. चूंकि हमने अब यह स्थापित कर लिया है कि GOPATH केवल 'go get' के दौरान ही बनाया जा रहा है, चलो केवल संदेशों को प्रिंट करें यदि -v ध्वज दिया गया है, जो शेष 'go get -v' व्यवहार के अनुरूप है।
2. यदि निर्देशिका बनाई जाती है, तो संदेश अधिक से अधिक होना चाहिए

# बनाया गया GOPATH=/users/campoy/go; देखें 'गोपथ की मदद करें'

यह चेतावनी नहीं है: चेतावनियां खराब हैं। दूसरी ओर यदि निर्माण विफल हो जाता है तो आप अच्छी तरह से प्रिंट करना चाह सकते हैं

go: creating GOPATH=/users/campoy/go: %v

उन दोनों संदेशों को मुद्रित किया जा सकता है, भले ही GOPATH का अनुमान लगाया गया हो या स्पष्ट रूप से सेट किया गया हो।

1. खाली निर्देशिका और src उपनिर्देशिका होने के बारे में अनुमान बहुत जटिल हैं। इससे भी बदतर, वे काल्पनिक समस्याओं को संबोधित कर रहे हैं, और काल्पनिक के लिए डिजाइन करना बहुत मुश्किल है। सरल, अधिक अनुमानित व्यवहार रखने के लिए बेहतर है। शुरू करने के लिए, मुझे लगता है कि यह समझ में आता है कि वास्तविक समस्याओं के ठोस उदाहरण होने तक कोई नियम नहीं है। लोगों के पास बीटा के दौरान समस्याओं की रिपोर्ट करने और उम्मीदवारों को रिहा करने का समय होगा। आइए बस GOPATH=$HOME/go सेट करें (बशर्ते $HOME सेट हो)।

संपादित करें: दिखावा करें कि जीथब मार्कडाउन ने इसे पूरी तरह से खराब नहीं किया है।

@campoy src/ निर्देशिका के संबंध में, GOPATH सेट होने पर go get का वर्तमान व्यवहार क्या है लेकिन कोई src निर्देशिका मौजूद नहीं है? क्या इसे न बनाने का भी कोई अच्छा कारण है?

यह समझाने में आसान लगता है कि $ HOME/go/src पहले जाने पर बनाया गया है (या $ GOPATH/src यदि वह पर्यावरण चर सेट है)

आज, जब GOPATH सेट किया जाता है, तो आवश्यक निर्देशिकाएं, बिना शर्त, आवश्यकतानुसार बनाई जाती हैं।

CL https://golang.org/cl/33356 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/33730 इस मुद्दे का उल्लेख करता है।