Go: cmd / go: افترض أن GOPATH = $ HOME / go إذا لم يتم تعيينها

/ سم مكعبadgbroadycampoyianlancetaylorgriesemerrobpikersc

يعجبني ذلك ، ولكن هل لدينا أي تفضيل محدد لـ "gocode" وليس شيئًا مثل "gopath"؟

كم عدد الأشخاص الذين يستخدمون بالفعل 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٪
$ HOME / go: 50.6٪
أخرى: 40.5٪

أتمنى حقًا لو قمت بتقسيم المزيد من الخيارات لهذا الخيار.

بدأ التصويت: https://twitter.com/golang/status/781189567437164544

يوم الأربعاء ، 28 سبتمبر 2016 ، الساعة 10:51 صباحًا ، Edward Muller [email protected]
كتب:

ماذا عن $ HOME / go (وهو ما أستخدمه).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -250244110 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

انظر أيضًا العمود الأول هنا: https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid = 1525640201

freeformz ،

يتعارض $ HOME / go مع المسار go. غالبًا ما يتم سحب الكود المصدري (go.googlesource.com/go). إنه لأمر سيء أن المجتمع بارك هذا الموقع باعتباره موقعًا افتراضيًا لـ GOPATH: (أنا قلق إذا نسي شخص ما تعيين GOPATH الخاص به وقام بتشغيل أداة go ، فسيؤدي ذلك إلى العبث في دليل التطوير الحالي الخاص به.

rakyll لكل منهم ، أردت فقط الإشارة إلى ما أستخدمه أنا والعديد من الآخرين. تم سحب go.googlesource.com/go في /usr/local/go.git على نظامي.

كم عدد الأشخاص الذين يستخدمون بالفعل GOPATH = $ HOME / gocode؟ لا يبدو لي الكثير. هذا يشير إلى أن هذا هو التقصير الخاطئ.

بالنسبة للسجل ، أستخدم GOPATH=$HOME ، لكنني شعرت أن هذا سيكون مثيرًا للجدل للغاية وينتقص من هدف هذا الاقتراح وهو تحسين تجربة المستخدم الجديد.

freeformz ، أعتقد أننا لسنا

يبدو $ HOME / gocode غريبًا بالنسبة لي ولكنه قد يكون اختيارًا جيدًا للغاية.

النقطة المهمة هي أنه لا يهم ما هو الافتراضي ، فقط أن هناك واحدًا.

لا يهم ما هو الإعداد الافتراضي ، لأن تعيين هذا الإعداد الافتراضي سيجعله بشكل أساسي كيف يعمل كل شخص جديد على Go بعد بضع سنوات من الآن.

يخرج الأمر go عن طريقه حتى لا يتم الخلط بينه وبين GOPATH = $ GOROOT صراحة ؛ أنا متأكد من أنه يمكن تطبيق نفس المنطق على الإعداد الضمني أيضًا. لذلك أنا لست قلقًا جدًا بشأن تحطيم $ HOME / اذهب عن طريق الخطأ.

ما زلت أتساءل عما إذا كان يجب علينا بدلاً من التقصير الثابت أن نتعرف تلقائيًا على والدي الدليل الحالي لمعرفة مكان GOPATH. هذا ما تفعله العديد من أدوات المصدر هذه الأيام (على سبيل المثال ، كل نظام تحكم في الإصدار) ، لذلك فهو مفهوم يفهمه الناس. ولا يجبرهم على استخدام اسم دليل واحد أو امتلاك مساحة عمل GOPATH واحدة فقط. ولكن ربما نجري هذا النقاش حول القضية الأصلية.

rsc ، أود أن يكون هذا GOPATH=$HOME لأن هذا يعني أن $GOPATH/bin سيكون في مسارهم (في معظم توزيعات Linux على الأقل ، لست متأكدًا من darwin).

$GOPATH=$HOME/go هو أيضًا اختيار جيد وأولئك الذين لديهم مصدر المترجم المعتمد هناك سيكونون قد قاموا بالفعل بتعيين GOPATH=something else لذلك لا توجد فرصة للتعارض.

لأكون واضحًا ، لم أكن أحاول أن أكون متهورًا عندما قلت

النقطة المهمة هي أنه لا يهم ما هو الافتراضي ، فقط أن هناك واحدًا.

بدلاً من محاولة التأكيد على الهدف من هذا الاقتراح هو جعل أداة go تستخدم قيمة افتراضية لـ $GOPATH عندما لا يتم توفيرها لأن هذا مصدر دائم للارتباك والإحباط للعديد من الوافدين الجدد إلى اللغة.

أنا أعمل على الاستنشاق التلقائي لأنه فشل في حالة استخدام رئيسية ، وهي:

1. لقد قمت بتثبيت Go ، ولم أقرأ مستندات تثبيت Go في الواقع ، فقط اتبعت ما ورد في README في الريبو الذي يقول brew install go
2. لقد قمت بتشغيل go get github.com/thething/theproject
3. تلقيت الآن خطأ بشأن عدم تعيين $ GOPATH. ما هذا؟ أردت فقط تشغيل هذا البرنامج الذي قام شخص ما بالتغريد عنه!

قيمة افتراضية قدرها GOPATH=$HOME/go SGTM ، بافتراض أننا قررنا طريقة افتراضية وليس أسلوب شم تلقائي.

يخرج الأمر go عن طريقه حتى لا يتم الخلط بينه وبين GOPATH = $ GOROOT صراحة ؛ أنا متأكد من أنه يمكن تطبيق نفس المنطق على الإعداد الضمني أيضًا.

يبدو عظيما.

لست متأكدا بشأن داروين

ليس على داروين.

إذا كان هذا للوافدين الجدد ، فإنني أنصح ضد GOPATH=$HOME لأن ذلك سيؤدي إلى إنشاء ثلاثة أدلة في دليلهم الرئيسي مقابل دليل واحد فقط. أنا لست حريصًا على البرامج التي تلوث دير منزلي بما يتجاوز الضرورة.

mvdan أفهم وكان رد فعلك هو سبب عدم GOPATH=$HOME .

إذا أردت _I_ شخصيًا تعيين GOPATH على $HOME ، فسيظل هذا الخيار متاحًا لي ، وسأضطر إلى عدم إجراء أي تغييرات في حالة قبول هذا الاقتراح لـ Go 1.8.

تضمين التغريدة

الافتراضي إلى قيمة GOPATH = $ HOME / gocode

لا يوجد متغير HOME افتراضي على Windows. ماذا تقترح أن تفعل على Windows؟

أحب أن يكون هذا الإعداد الافتراضي هو GOPATH = $ HOME لأن هذا يعني أن $ GOPATH / bin سيكون في طريقهم

أنا دائمًا قلق بشأن وجود GOPATH / bin في مساري. go get بتثبيت برامج الآخرين هناك. هل نريد حقًا أن يقوم مستخدم Go جديد بتثبيت برامج عشوائية من الإنترنت في مكان ما في مسارهم؟

اليكس

أنا لست مستخدمًا متمرسًا لنظام التشغيل windows ، لكنني أفترض أن هناك فكرة عن المسار الأساسي حيث يتم تخزين المستندات والإعدادات. لغرض هذه المناقشة ، افترض أنني أتحدث عن هذا المسار في سياق مستخدمي windows.

في حالة عدم وجود مثل هذا المسار ، افترض أن C: / gocode.

كتبت لتعليقي على GOPATH = $ HOME ، بينما هذا هو تفضيلي الشخصي وسيظل كذلك ، أدرك أن هذا خيار مثير للجدل لقيمة افتراضية وعلى هذا النحو لم أقترحه كقيمة مقترحة.

الاكتشاف التلقائي محفوف بالمخاطر. لقد بدأت في وضع النماذج الأولية لهذا منذ فترة ، لكنه أضاف تعقيدًا كبيرًا لكل من أداة الانتقال وتجربة المستخدم.

لست على دراية بما يحدث مع مجموعة عمل إدارة الحزم ، لكن يمكنني تخيل مستقبل غير بعيد جدًا حيث يتم القضاء على GOPATH تمامًا.

ومع ذلك ، حتى إذا اختفى GOPATH في وقت ما في المستقبل القريب ، فربما لا تزال هناك قيمة في تعيين الإعداد الافتراضي. إذا كنا نعتقد أنه من المحتمل أن يختفي GOPATH ، فلا يهم كثيرًا ما حددناه له.

مما قرأته أعلاه ، هناك بعض الإجماع على أن:

1. كإعداد افتراضي ، يعد GOPATH=$HOME غازيًا للغاية.
2. يجب أن تتضمن القيمة الافتراضية السلسلة go مكان ما (من المحتمل أن تكون بادئة).

لست قلقًا بشأن كون GOPATH نسخة من مستودعات go الرئيسية (أي GOPATH == GOROOT). من المحتمل أن يكون لدى الأشخاص الذين يقومون بفحص go repo مجموعة GOPATH. ستكتشف أداة go التعارض على أي حال ، كما هو الحال اليوم.

مع أخذ ذلك في الاعتبار ، سيكون الخيار الافتراضي الأكثر إيجازًا هو $HOME/go ، وهو ما أعتقد أنه معقول تمامًا.

أفترض أن هناك فكرة عن المسار الأساسي حيث يتم تخزين المستندات والإعدادات.

أنا لا أعرف شيئًا من هذا القبيل. ربما يعلق مستخدمو Windows الآخرون هنا.

في حالة عدم وجود مثل هذا المسار ، افترض أن C: / gocode.

تريد C: gocode بدلاً من ذلك.
وضع الأشياء في جذر C: \ لا يبدو صحيحًا بالنسبة لي. هل تنصح بضبط GOPATH على / gocode على Linux؟
ولكن ، نظرًا لأن برنامج تثبيت Windows يقوم بالفعل بتثبيت Go to C: go ، فإن C: gocode لـ GOPATH ثابت على الأقل.

اليكس

ولكن ، نظرًا لأن برنامج تثبيت Windows يقوم بالفعل بتثبيت Go to C: go ، فإن C: gocode لـ GOPATH ثابت على الأقل.

لا ينبغي توفير GOPATH لكل مستخدم؟ أن تكون مثل UNIX ، %USERPROFILE%\gocode ، على ما أعتقد.

اذهب + استطلاع على https://goo.gl/xAsgEj

بعد أن استخدمت شيئًا مثل $ HOME / go-Programs لفترة طويلة ، قمت بتحويل GOPATH إلى $ HOME. لذلك ، لدي الآن الهيكل التالي:

منزل $ / بن
$ HOME / pkg
$ HOME / src /
$ HOME / src / github.com / user / some_github_project
$ HOME / src / some_project

هذا الهيكل أكثر عمومية ويمكن استخدامه أيضًا للاستخدام مع لغات أو مشاريع أخرى ومع جيثب. على سبيل المثال ، لدي $ HOME / src / talks (اقرأها الصفحة الرئيسية / المصادر / المحادثات لملفات تخفيض السعر) أو مشاريع أخرى في بعض اللغات (مثل $ HOME / src / github.com / user / html) ولكن أيضًا مصادر ولدي واحد ضع للعديد من مصادر المشاريع مع أو بدون مراسلات جيثب.

يمكن اعتبار bin أو pkg فوضويًا لكنني أعتقد أنه ليس مزعجًا للغاية. هو أكثر فوضى أن يكون لديك العديد من مجلدات المصدر للأشخاص الذين يستخدمون لغات متعددة.

لذلك ، من وجهة نظري ، أفضل مكان لـ GOPATH هو $ HOME.

أنا أستخدم $ HOME / gocode باعتباره GOPATH الخاص بي.
أنا ضد $ HOME / go لأنه في بعض الأحيان ليس لديك امتياز الجذر وتحتاج إلى تثبيت Go ضمن دليل منزلك. في مثل هذه الحالة ، أعتقد أن $ HOME / go سيكون الأفضل لـ GOROOT.
لذلك يجب أن نستخدم شيئًا مختلفًا عن $ HOME / go كـ GOPATH.

hnakamur رجوع عندما قمت بتثبيت Go يدويًا (الآن باستخدام Ubuntu Make) ، وضعته في $ HOME / bin / go - $ {go_version} (مع رابط رمزي من $ HOME / bin / انتقل إلى $ HOME / bin / go- $ {version} / bin / go ، لذلك لم أضطر إلى تعديل $ PATH)

tbroyer إنه

أستخدم $ HOME من أجل GOPATH الخاص بي.
لماذا يتم ضبط GOPATH تلقائيًا ، لماذا لا نرفع التحذير بمعلومات جيدة كيف يتم ضبطه إذا لم يكن GOPATH موجودًا؟

لماذا يتم ضبط GOPATH تلقائيًا ، لماذا لا نرفع التحذير بمعلومات جيدة كيف يتم ضبطه إذا لم يكن GOPATH موجودًا؟

لا تكمن المشكلة في أن الأشخاص لا يعرفون كيفية تعيين متغير بيئة (في معظم الأحيان) ، بل إنه حتى لو فعلت ذلك ، فإنك تشعر بالضيق للقفز عبر الأطواق للبدء في استخدام Go. القدرة على استخدام Go out of the box مع الإعدادات الافتراضية السليمة بمجرد تثبيتها تجعل التجربة سلسة قدر الإمكان ، ويعني أن المزيد من الأشخاص من المحتمل أن يحاولوا فعلاً Go بعد تنزيله ، بدلاً من الوصول إلى طريق مسدود ، وفقدان الزخم ، و أن تقرر أنه لا يستحق العبث به.

أميل إلى الاتفاق مع كريس وأندرو: إذا كان هناك GOPATH افتراضي ، فيجب أن يكون $ HOME / go فقط ، وليس gopath أو gocode. _ معظم_ المستخدمين ليس لديهم توزيع Go تم فحصه هناك (وكل من يقوم بذلك اليوم يقوم بالفعل بتعيين GOPATH ، لذلك لن يزعجهم هذا). يجب أن يكون الإعداد الافتراضي منطقيًا للمستخدمين الجدد ، وليس المتقدمين ، وبالنسبة لمعظم المستخدمين ، فإن $ HOME / go له معنى كبير.

أثار Jaana قلقًا بشأن أمر go بالارتباك إذا حدث أن $ HOME / go هو توزيع Go ، لكن الأمر go يتحقق بالفعل من GOPATH العرضي = $ GOROOT. من السهل التحقق مما إذا كان هذا صحيحًا عند تعيين GOPATH ضمنيًا أيضًا. في الواقع ، سيكون من السهل أيضًا زيادة الشيك للبحث عن ، على سبيل المثال ، $ HOME / go / src / cmd / go / alldocs.go ، لتجنب الارتباك حتى عندما يكون GOROOT! = $ HOME / go لكن $ HOME / go يفعل تحتوي على توزيع Go.

$ HOME / go ليس خيارًا جيدًا لـ GOPATH. دعنا نجري تمرينًا بسيطًا على السلوك ... يمكن للمستخدمين الجدد اعتبار الإعداد الافتراضي بسهولة كأفضل ممارسة. لنفترض أنني مستخدم جديد ، فلماذا أعتبر التقصير أمرًا سيئًا؟ أكثر من ذلك ، الطريقة الأسهل (والأفضل؟) لتثبيت golang هي عن طريق فك الحزمة في $ HOME لأنه بهذه الطريقة يكون المترجم دائمًا في الإصدار الأخير ولا يحتاج إلى حقوق الجذر ، لذا يمكنك بسهولة أن تفترض أن العديد من المستخدمين سيحصلون على برنامج التحويل البرمجي go compiler في $ HOME / go. لماذا يجب أن أقوم بنقل المترجم إلى / usr / local بينما لا يمكنني ذلك؟
أكثر من ذلك ، يمكنهم إنشاء مشاريع ويمكنهم استنساخ المشاريع في هذا المجلد. لذلك ، سيكون لديهم مجلد فوضوي وبقليل من الإهمال يمكنهم بسهولة حذف مجلد المشروع الخاص بهم من خلال إعادة تثبيت golang الجديدة.
أيضًا ، لدى مستخدمي windows c: go افتراضيًا.

أنا أحب $ HOME / Gopath. تقول ما هي.
أول نتيجة على Google لـ "gopath" هي الصفحة الصحيحة.

إذا تم اعتماد الافتراضي ، فهل يمكن إضافة دالة func GOPATH() string إلى runtime ؟ في الوقت الحالي ، يمكن للمرء استخدام os.Getenv() ، ولكن مع الإعداد الافتراضي ، لن يكون الأمر بهذه البساطة.

btracey ، GOPATH هي قائمة وليست قيمة واحدة. استخدم filepath.SplitList . أيضًا ، GOPATH ليست دالة في وقت التشغيل. يتعلق الأمر فقط بـ cmd/go .

للتوافق مع الإصدارات السابقة ، ربما نحتاج إلى تعيين GOPATH في هذه العملية "
إذا لم يتم تعيين أي بيئة.

في 30 سبتمبر 2016 الساعة 08:10 ، Brendan Tracey [email protected]
كتب:

إذا تم اعتماد الافتراضي ، فهل يمكن إضافة دالة سلسلة func GOPATH ()
لوقت التشغيل؟ في الوقت الحالي ، يمكن للمرء استخدام os.Getenv () ، ولكن باستخدامه افتراضيًا
لن يكون بهذه البساطة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -250605418 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

أنت على حق @ برادفيتز. الحل الذي اقترحه adg سيلبي جميع استخداماتي.

هذا تجعد مثير للاهتمام. أستطيع أن أرى هذا الفشل حاليًا عندما لا
يتم تعيين GOPATH ، ولكن أيضًا عندما يحتوي GOPATH على قيم متعددة ، وبعد ذلك
هناك حالة يتم فيها إنشاء التطبيق على جهاز واحد ونشره
اخر.

لا أريد رفض هذا الاستخدام لـ GOPATH ، أنا أفهم ألم
أن تكون قادرًا على تحديد موقع ملفات الدعم لتطبيقك ، لكني أرغب في ذلك
لفهم مدى انتشار هذا الاستخدام ، ومدى انتشاره
تطبيقات التعامل مع القضايا التي أبرزتها أعلاه.

في الجمعة ، 30 سبتمبر 2016 ، 08:35 كتب Brendan Tracey [email protected] :

أنت محق bradfitz 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 كتب Brendan Tracey [email protected] :

استخدامي ليس هو المعتاد. أقوم ببحث علمي ووجدته
انها فعالة جدا ليس فقط gopath / src و gopath / bin ، ولكن أيضا
جوبات / البيانات وجوبات / النتائج. هذا يجعل من السهل نسخ المصدر
من الملفات إلى نظام جديد دون الحاجة أيضًا إلى نسخ (غيغابايت من)
ملفات النتائج. يولد النظام الجديد (على سبيل المثال الكتلة) ملفات نتائج جديدة ،
ويمكنني نسخ هذه النتائج إلى موقع مركزي. من السهل حقًا
ثم قل gopath = os.Getenv ("GOPATH") ، واحفظ الملف في شيء مثل filepath.Join (gopath،
"النتائج" ، "اسم المشروع" ، result.json).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 ، # حل هذه المشكلة مباشرة. يمكن للكود المحدد الذي يحتاج إلى ملف (أو لحفظ ملف) أن يتحرك كثيرًا ، وأريد مكانًا ثابتًا للمدخلات / المخرجات للعيش بشكل مستقل عن (ومنفصل عن) إعادة البناء.

تتعلق هذه المشكلة بقيمة افتراضية محتملة لـ GOPATH. لا يتعلق الأمر بالاستخدامات البديلة لـ GOPATH.

إذا كان المستخدمون المستهدفون لهذا التغيير هم فقط أولئك الذين أرادوا ذلك فقط
تثبيت برنامج جديد مكتوب في Go ، وليس البرامج التي تريد ذلك بالفعل
اكتب Go ، ثم ماذا عن الاستنساخ في دليل لكل مستخدم في
$ TMPDIR ، واترك الثنائي عند $ PWD إذا لم يتم تعيين GOPATH $؟ (بوضوح
هذا منطقي فقط لـ go get import.path / for / a / command ، إذا لم يكن ملف
الأمر ، go get يجب أن يفشل دون تعيين GOPATH $)

بالنسبة إلى الخارج ، هذا منطقي جدًا ، تمامًا مثل wget ملف.

بمجرد أن يريد المستخدم البدء في كتابة كود Go ، يجب أن يتعلم كيفية التعيين
GOPATH بشكل صحيح.

أنا ضد $ HOME / go لأنه في بعض الأحيان ليس لديك امتياز الجذر وتحتاج إلى تثبيت Go ضمن دليل منزلك. في مثل هذه الحالة ، أعتقد أن $ HOME / go سيكون الأفضل لـ GOROOT.

إذا كنت تستخدم نظام Linux ، فسأجادل بأن أفضل مكان لـ $ GOROOT قد يكون في $ HOME / .local / opt / go ، وليس $ HOME / go ، اعتمادًا على كيفية تفسيرك لغرض $ HOME / .local ، حيث إن $ HOME / .local / share فقط (يظهر على شكل مرآة / usr / local / share) معرَّف في مواصفات دليل XDG Base: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. لغة البرمجة.

يمكن للمرء أيضًا أن يجادل بأن أفضل خيار افتراضي لـ GOPATH / GOBIN (على Linux) يجب أن يكون:
GOPATH = $ XDG_DATA_HOME / go ، أو $ HOME / .local / share / go
GOBIN = $ HOME / .local / bin

ومع ذلك ، ربما لا يكون هذا هو الأسهل فهمًا للمستخدمين الجدد؟ وسيترك الأمر أيضًا غير واضح ما هو أفضل نهج على Windows. يبدو أن $ HOME / go و $ USERPROFILE / go عمليًا.

من فضلك ، من فضلك ، دعونا لا ندع هذا الموضوع يتحول إلى مناقشة لأسماء مسارات Linux الأساسية ومواقع التخزين. إنه ليس مثمرًا ، وأشعر أن هذا النقاش قد انحرف بالفعل بعيدًا عن منشور ديف تشيني الأصلي.

لست متأكدًا أيضًا من أهمية الموقع الفعلي المطلق كثيرًا ، أعتقد أن كل هذا الموضوع يحتاج إلى تحديده حقًا هو "هل نريد Gopath افتراضيًا؟" (يبدو أن هذا يمثل إجابة ساحقة إلى حد ما) و "هل يجب مشاركته على مستوى النظام ، أو محليًا للمستخدم" (حتى الآن كانت معظم المناقشات تدور حول محلي). بعد ذلك ، يمكن لأي شخص أن يختار $HOME/gocode أو $HOME/go أو /usr/share/go/ أو أيًا كان ما يريده يبدو معقولًا لمن يراجع العلاقات العامة ، ومن المحتمل أن تستمر الأمور على ما يرام.

أعتقد أن GOPATH على مستوى النظام ليست بداية بسبب مشكلات الأذونات.

المسار الواسع للنظام ، في السراء والضراء ، هو GOROOT ، وهو التوزيعات
مثل دبيان تستخدم لتثبيت حزم "على مستوى النظام" ، للأفضل أو لصالح
أسوأ.

نظام GOPATH على نطاق واسع هو خارج نطاق هذا الاقتراح ، هذا الاقتراح
يوصي بمسار مشتق من قيمة المستخدم الذي قام بتسجيل الدخول.

في الثلاثاء ، 4 أكتوبر 2016 ، 08:52 كتب Andrew Gerrand [email protected] :

أعتقد أن GOPATH على مستوى النظام ليست بداية بسبب مشكلات الأذونات.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -251238251 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

من فضلك ، من فضلك ، دعونا لا ندع هذا الموضوع يتحول إلى مناقشة لأسماء مسارات Linux الأساسية ومواقع التخزين. إنه غير منتج

حسنًا ، دعنا لا. كانت نقطتي الرئيسية حقًا هي الإشارة إلى سبب آخر هو أن $ HOME / go ربما لا يمثل مشكلة باعتباره افتراضيًا لـ GOPATH ، لأنه ربما ليس أكثر مسارات Linux "اصطلاحية" لتثبيتات المستخدم المحلي لـ Go (المعروف أيضًا باسم GOROOT) على أي حال.

بخلاف ذلك ، أعتقد أنه قد تمت مناقشته من قبل لاستخدام XDG_CACHE_HOME لـ GOPATH الافتراضي ، ولهذا السبب ذكرت XDG_DATA_HOME - على الرغم من أنني لا أعرف الدور الذي يخدمه مؤلفو المستند المرتبط ، أو مدى كونه "رسميًا" .

$ المنزل / العمل .......

adgquentinmitrsc ما هي الخطوات التالية لهذا الاقتراح؟

أود حقا أن أرى شيئا يحدث هنا. إنها نقطة ألم متكررة في فصولي. أي تقصير (حتى $ home / go الذي لا أتفق معه :)) أفضل من لا شيء.

$ HOME / اذهب سيكون. لا توجد أفضل إجابة واحدة ولكن هذا قصير ولطيف ، ويمكن أن يكون اختيار هذا الاسم مشكلة فقط إذا كان $ HOME / go موجودًا بالفعل ، وهو ما سيسعد فقط للخبراء الذين سبق لهم التثبيت بالفعل وسيفهمون GOPATH.

من يريد القيام بالعمل؟

سأكون سعيدًا بالتأكيد للعمل على هذا.

campoy ، هل يمكنك أن تفعل ذلك <= يوم الجمعة؟

أود أن أقول ذلك ، نعم @ برادفيتز . لا يبدو أنه يجب عمل كمية هائلة من التعليمات البرمجية.
يمكنني أن أبدأ غدا.

تحديث: لقد ألقيت نظرة سريعة على هذا وكتبت بعض التعليمات البرمجية بالفعل ، وسوف أقوم بإضافة بعض الاختبارات وإرسال التغيير في وقت لاحق اليوم

هذا رائع يا رفاق! 👍

robpike هل فكرت أيضًا في اقتراحي البديل في # 17271؟ أود أن أفهم سبب اعتبار هذا الاقتراح أفضل

لن تكون فكرة جيدة أن يكون لديك نفس أسماء دليل Go install ودليل مساحة العمل مثل go للأسباب التالية:

1) من السهل جدًا على المستخدم الساذج أن يفسد / يلوث مساحة العمل إذا قام المستخدم بعمل 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

krishnasrinivas أفهم أنه إذا كان GOROOT=$HOME/go ، فإن هذا الإعداد الافتراضي لن يحدث أو يؤدي إلى خطأ go لأن GOROOT و GOPATH لا يمكن أن يكونا متماثلين. في مثل هذه الحالات ، كما ذكرنا سابقًا ، من المتوقع أن يكون المستخدم قادرًا بشكل كافٍ على تعيين GOPATH .

mvdan ، صحيح ، بالنسبة للمستخدمين الجدد الذين لا يرغبون في استخدام امتيازات الجذر للتثبيت (وبالتالي هناك فرصة كبيرة لتثبيت Go in ~ / go) ، فإننا لا نجعل الأمر أسهل في تشغيل الأشياء كما سيتعين عليهم ذلك صراحة اضبط GOPATH على شيء آخر. يمكن إصلاح ذلك بسهولة إذا كان GOPATH الافتراضي هو إما ~ / gopath أو ~ / gocode

بالنسبة للتثبيت غير الجذر ، إذا كان على المستخدمين الجدد الاستفادة من الافتراضي GOPATH = ~ / go ، فيجب أن تكون وثائق التثبيت أكثر تعقيدًا بعض الشيء من خلال مطالبة المستخدمين صراحة باستخدام الخيار tar -C حتى لا يتم تثبيته بسعر ~/go

rasky أنا أعتبر #

أتفق مع krishnasrinivas. لم يكن لدي أذونات جذر ، لذلك لم أرغب في الذهاب إلى $ HOME / go. لقد قمت أيضًا بتعيين GOPATH $ الخاص بي = $ HOME / gowork.

krishnasrinivasjoegrasse لا يوجد حل مثالي. من السهل تعيين GOPATH بنفسك ، وأتوقع أن هذا ما سيفعله معظم الناس. القضية هنا هي ما يجب أن نفعله للأشخاص الجدد في الذهاب. هؤلاء ليسوا عمومًا أشخاصًا يقومون بتثبيت توزيع Go الخاص بهم في مواقع مخصصة. يمكن للأشخاص الذين يمكنهم معرفة كيفية تثبيت Go في موقع مخصص معرفة كيفية تعيين GOPATH .

فكر بدلاً من فئة من المبرمجين الجدد الذين يستخدمون توزيعات Go المثبتة مسبقًا. نريدهم أن يكونوا قادرين على البدء في كتابة كود Go. لا نريد أن تكون الخطوة الأولى "هذا هو متغير البيئة. هذه هي الطريقة التي تحدد بها واحدًا. الآن قم بتعيين GOPATH لهذا." هذه الخطوات لا علاقة لها بـ Go على هذا النحو.

مرة أخرى ، لا يوجد حل مثالي ، ولكن يبدو من الحكمة اختيار شيء ما.

ianlancetaylor أوافق تمامًا على أنه يجب اختيار شيء ما. أنا أؤمن فقط بالذهاب إلى ./go ، التخلف عن السداد إلى $ HOME / go ، قد لا يكون الخيار الأفضل.

ianlancetaylor GOPATH = $ HOME / gopath هو خيار افتراضي أفضل من GOPATH = $ HOME / go للأسباب المذكورة أعلاه.

لا أعتقد أن الاسم الحالي يمثل مشكلة - إذا كنت تعرف كيفية تعيين PATH لموقع go / bin مخصص تحت homedir ، فأنت تعرف كيفية تعيين GOPATH.

krishnasrinivasjoegrasse نلقي نظرة على " تثبيت إلى موقع مخصص ".

إذا كنت لا تتعامل مع أي مكان آخر غير /usr/local/go - لأسباب تتعلق بالأذونات أو غير ذلك - يصبح من الضروري تعيين GOROOT أيضًا ، أو التحويل البرمجي من المصدر.

طالما كان هذا هو الحال ، فلا فائدة من استخدام $ HOME / gopath ، وما إلى ذلك ، على $ HOME / go المقترح.

أنت تفترض أن المستخدمين الجدد يفضلون التثبيت من tar.gz. لا أستطيع أن أذكر
الأرقام ، ولكن أعتقد أن الإجابة تستند إلى عمليات تثبيت Linux ، والتي
هي ثالث أكثر أهداف التثبيت شيوعًا بالنسبة إلى go.

في الثلاثاء ، 25 أكتوبر 2016 ، الساعة 20:28 كريشنا سرينيفاس [email protected]
كتب:

mvdan https://github.com/mvdan صحيح ، للمستخدمين الذين لا يريدون
استخدام امتيازات الجذر للتثبيت (وبالتالي فرصة كبيرة للتثبيت
Go in ~ / go) نحن لا نجعل الأمر أسهل في تشغيل الأشياء وتشغيلها
سيتعين عليهم تعيين GOPATH بشكل صريح لشيء آخر. هذا يمكن أن يكون
يمكن إصلاحه بسهولة إذا كان GOPATH إما ~ / gopath أو ~ / gocode

للتثبيت غير الجذر ، إذا كان على المستخدمين الجدد الاستفادة من الافتراضي
GOPATH = ~ / go إذن يجب أن تكون الوثائق أكثر تعقيدًا بعض الشيء
من خلال طلب الصراحة من المستخدمين استخدام خيار tar -C حتى لا يتم تثبيته في
~ / انطلق

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -255984498 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

تحتاج جميع المستندات إلى التحديث أيضًا. ربما يكون هذا هو الجزء الأكبر من العمل.

في 25 أكتوبر 2016 الساعة 10:14 ، أرسل Francesc Campoy [email protected]
كتب:

سأقول ذلك ، نعم. لا يبدو أنه يجب عمل كمية هائلة من التعليمات البرمجية.
يمكنني أن أبدأ غدا.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -255892314 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

سأقول ذلك ، نعم. لا يبدو أنه يجب عمل كمية هائلة من التعليمات البرمجية.
يمكنني أن أبدأ غدا.

يوم الإثنين 24 أكتوبر 2016 الساعة 4:05 مساءً Brad Fitzpatrick [email protected]
كتب:

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 بخلاف الحصول على حزم طرف ثالث. إذا تمكنا من الإبلاغ عن المسار الافتراضي عبر go env ، فسيكون من السهل الإشارة إلى ذلك في المستندات.

ربما يمكن استبدال $ HOME / go / ... بدلاً من ذلك (أو ما يعادله على Windows)؟

نظرًا لأنك أضفت $HOME/go/bin إلى PATH (أو $GOPATH/bin إذا تم تعيين GOPATH) ...

ربما في مرحلة ما ، يمكن أن تتوقع الوثائق من الأفراد ليس فقط تعيين متغير بيئة PATH ، ولكن أيضًا تعيين GOPATH إلى $ HOME / go. على الرغم من أنها زائدة عن الحاجة ، إلا أنها تعد المستخدم لمراجع لاحقة إلى GOPATH.

قد يفترض التوثيق الأولي الإعداد الافتراضي ولا يذكر متغيرات البيئة على الإطلاق.

أنت تفترض أن المستخدمين الجدد يفضلون التثبيت من tar.gz. لا أستطيع أن أذكر
الأرقام ، ولكن أعتقد أن الإجابة تستند إلى عمليات تثبيت Linux ، والتي
هي ثالث أكثر أهداف التثبيت شيوعًا بالنسبة إلى go.

أنت محق ، رأيي منحاز نحو تثبيتات Linux. أستطيع أن أرى أنه بالنسبة للمستخدمين الجدد الذين قاموا بالتثبيت ، انتقل إلى / usr / local ، قد يكون ~ / go اسم دليل يمكن التعرف عليه أكثر من ~ / gopath

يمكن أن تفترض الوثائق الأولية التقصير ولا تذكر
متغيرات البيئة على الإطلاق؟

نعم ، نأمل أن يتم نقل كل الجدل المشتت للانتباه حول إعداد GOPATH
إلى ملحق وثيقة التثبيت ، فقط كذب نحن من أجل GOROOT
حاليا.

في الأربعاء ، 26 أكتوبر 2016 ، 06:01 كتب ناثان يونغ مان [email protected] :

ربما يمكن استبدال $ HOME / go / ... بدلاً من ذلك (أو ما يعادله في
شبابيك)؟

نظرًا لأنك أضفت $ HOME / go / bin إلى PATH (أو $ GOPATH / bin إذا كان GOPATH
يضع)...

ربما في مرحلة ما قد تتوقع الوثائق من الأفراد عدم القيام بذلك
قم فقط بتعيين متغير بيئة PATH ، ولكن أيضًا قم بتعيين GOPATH على $ HOME / go.
على الرغم من أنها زائدة عن الحاجة ، إلا أنها توضح الوثائق اللاحقة.

يمكن أن تفترض التوثيق الأولي الوضع الافتراضي ولا يذكر البيئة
المتغيرات على الإطلاق؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

قد يفترض التوثيق الأولي الإعداد الافتراضي ولا يذكر متغيرات البيئة على الإطلاق.

SGTM

هناك نوعان من مستخدمي Go:

• المستخدمون الذين يحصلون للتو على الحزم الحالية
• المستخدمون هم مطورو Go

يقوم GOPATH الافتراضي بإصلاح الحالة للمجموعة الأولى. لا يزال بإمكاننا الاحتفاظ بالتعليمات المتعلقة بـ GOPATH حول المستندات التي تواجه المطورين. لا ينبغي أن يذكر التثبيت إعداد GOPATH على الإطلاق بعد الآن أو يمكننا الحصول على ملحق كما يذكر davecheney .

بصفتي شخصًا اضطر إلى إعادة تسمية ~ / bin / go بسبب Go ، أود أن أقترح أنه مهما كان الإعداد الافتراضي ، إذا كان موجودًا بالفعل ، فيجب أن يحتوي على ملف .dotfile للإشارة إلى أنه Go's بالفعل ~ / go. عندما لا يكون ~ / go موجودًا ، يمكن لـ go إنشاءه ، وإنشاء ملف .dotfile ، ويمكن لعمليات التشغيل المستقبلية العثور عليه. إذا قمت بتعيين GOPATH بشكل صريح على ~ / go ، فلن يكون هناك أي ملف dotfile ضروريًا نظرًا لعدم استخدام قيمة افتراضية.

الملف النقطي موجود. إنه دليل src / داخل $ HOME / go.

في الأربعاء ، 26 أكتوبر 2016 ، 07:59 كتب RalphCorderoy [email protected] :

بصفتي شخصًا اضطر إلى إعادة تسمية ~ / bin / go بسبب Go ، أود اقتراح ذلك
أنه مهما كان الإعداد الافتراضي ، إذا كان موجودًا بالفعل ، فيجب أن يحتوي على ملف
.dotfile فيه للإشارة إلى أنه حقًا Go's ~ / go. عندما ~ / go غير موجود ،
go يمكنه إنشائه ، وإنشاء ملف .dotfile ، ويمكن لعمليات التشغيل المستقبلية العثور عليه. اذا انا
اضبط GOPATH بشكل صريح على ~ / go ، فلن يكون هناك أي ملف .dotfile ضروريًا لأنه لا
يتم استخدام القيمة الافتراضية.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256173981 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

يذكر CL https://golang.org/cl/32019 هذه المشكلة.

حتى لو لم يكن بعض المبرمجين على دراية بمتغيرات البيئة ، فهم
يجب أن يكون على الأقل على دراية بـ _المتغيرات_. أعتقد أننا سنحتاج
لاستخدام شيء ما لوصف موقع مساحة العمل في المستندات ، و
قد تكون السلسلة $GOPATH كذلك.

في 26 أكتوبر 2016 في تمام الساعة 06:24 ، تم إرسال إخطارات إلى Jaana Burcu [email protected]
كتب:

يمكن أن تفترض التوثيق الأولي الوضع الافتراضي ولا يذكر البيئة
المتغيرات على الإطلاق.

SGTM

هناك نوعان من مستخدمي Go:

• المستخدمون الذين يحصلون للتو على الحزم الحالية
• المستخدمون هم مطورو Go

يقوم GOPATH الافتراضي بإصلاح الحالة للمجموعة الأولى. ما زلنا نستطيع الاحتفاظ بها
التعليمات المتعلقة بـ GOPATH حول المستندات التي تواجه المطورين. ال
لا ينبغي أن يذكر التثبيت إعداد GOPATH على الإطلاق أو نحن
يمكن أن يحتوي على ملحق مثل davecheney https://github.com/davecheney
يذكر.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256149104 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

شكرا هي النية ، يرجى الاطلاع على الاقتراح الأصلي.

في الواقع يمكننا الآن أن نقول "go get سوف يقوم بتنزيل المصدر إلى مجلد
تم الاتصال به ، go / src / github.com / Foo / Bar داخل دليل منزلك "

في الأربعاء ، 26 أكتوبر 2016 ، 06:01 كتب ناثان يونغ مان [email protected] :

ربما يمكن استبدال $ HOME / go / ... بدلاً من ذلك (أو ما يعادله في
شبابيك)؟

نظرًا لأنك أضفت $ HOME / go / bin إلى PATH (أو $ GOPATH / bin إذا كان GOPATH
يضع)...

ربما في مرحلة ما قد تتوقع الوثائق من الأفراد عدم القيام بذلك
قم فقط بتعيين متغير بيئة PATH ، ولكن أيضًا قم بتعيين GOPATH على $ HOME / go.
على الرغم من أنها زائدة عن الحاجة ، إلا أنها توضح الوثائق اللاحقة.

يمكن أن تفترض التوثيق الأولي الوضع الافتراضي ولا يذكر البيئة
المتغيرات على الإطلاق؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

ستكون هذه مشكلة كبيرة للأسبوع الأخير من Hacktoberfest

الملف النقطي موجود. إنه دليل src / داخل $ HOME / go

"src" هي طريقة شائعة لتكون "تم إنشاء هذا كملف نقطي افتراضي لـ GOPATH by Go".

ما هو الشيء الذي تحاول منعه؟

يوم الأربعاء 26 أكتوبر 2016 الساعة 9:20 صباحًا ، RalphCorderoy [email protected]
كتب:

الملف النقطي موجود. إنه دليل src / داخل $ HOME / go

"src" هي وسيلة مشتركة لتكون "تم إنشاء هذا كإعداد افتراضي لـ GOPATH بواسطة
انتقل "dotfile.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256194536 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$ HOME / اذهب سيكون.

ماذا سيكون لمستخدمي Windows؟

اليكس

سيستخدم مستخدمو Windows %USERPROFILE%\go ، مثلما يستخدم Docker هنا .

davecheney ، أحاول منع ما قلته منذ ساعتين: https://github.com/golang/go/issues/17262#issuecomment -256173981

اذهب هي كلمة شائعة. كان لدي ~ / bin / go. يلعب الأشخاص لعبة Go ولديهم شفرة مصدر تتعلق بلعب go. Nabbing ~ / go بشكل افتراضي عندما يكون موجودًا بالفعل لمجرد أنه يحتوي على src هو أمر غير مهذب. إذا لم يكن ~ / go موجودًا ، فقد يقوم Go بإمساك الاسم ، وإنشاء الدليل ، وختمه على أنه golang مع ملف نقطي مهم ، على سبيل المثال بناءً على اسم مجال golang.org.

هذه هي المشكلة والحل المحتمل على أي حال. حتى لو لم يكن الحل هو الحل الصحيح ، فهذا لا يعني أن المشكلة غير موجودة.

أصوت $ HOME / group

شكرا.

هل يمكننا استخدام GOPATH الافتراضي كـ ~/.gosrc ؟

هل يمكننا استخدام GOPATH الافتراضي كـ ~/.gosrc ؟

سيكون هذا مخفيًا افتراضيًا على Linux و OS X ، وسيكون مرئيًا في Windows. ماذا سيكون الدافع لإخفاء GOPATH؟

جرت المناقشة حول قيمة التخلف عن السداد قبل شهر. تم اتخاذ القرار بشأن $HOME/go وهو قيد التنفيذ بالفعل. العودة إلى هذا الموضوع لن يؤدي إلا إلى جعل سلسلة المحادثات طويلة بشكل لا يطاق.

يلعب الأشخاص لعبة Go ولديهم شفرة مصدر تتعلق بلعب go.

أنا لا أتابعك حقًا ، لكن نظرًا لأنك ستضبط GOPATH على
شيء آخر بالفعل ، لن يكون هناك تأثير عليك.

يوم الأربعاء 26 أكتوبر 2016 الساعة 9:43 صباحًا ، RalphCorderoy [email protected]
كتب:

davecheney https://github.com/davecheney ، أحاول منع ما أنا
قال منذ ساعتين: # 17262 (تعليق)
https://github.com/golang/go/issues/17262#issuecomment -256173981

اذهب هي كلمة شائعة. كان لدي ~ / bin / go. يلعب الناس Go ولديهم شفرة المصدر
للقيام بلعب الذهاب. Nabbing ~ / go افتراضيًا عندما يكون موجودًا بالفعل
لأنه يحدث لاحتواء src هو وقح. إذا لم يكن ~ / go موجودًا ، فانتقل
قد يمسك الاسم ، وأنشئ الدليل ، وختمه على أنه golang بامتداد
ملف dotfile مهم ، على سبيل المثال بناءً على اسم مجال 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 وسيفهمون GOPATH". أعتقد أنه من خلال كونك محاطًا بـ golang لفترة طويلة ، فإنك تنسى بشكل جماعي مدى شيوع كلمة "go" وكيف لها معاني أخرى ، مثل لعبة اللوحة.

يستهدف هذا التغيير القادمين الجدد إلى Go وقد يكون لدى البعض منهم ~ / go بالفعل لاستخدام غير Go. أقترح أنه إذا جاء go ، ووجد أن GOPATH لم يتم تعيينه ، ولا يوجد ~ / go ، فقد يقوم بإنشائه ، والاستيلاء على الاسم. ولكن إذا كان ~ / go موجودًا فعليه استخدامه فقط إذا كان بإمكانه إخباره بإنشائه في استدعاء سابق لا يحتوي على GOPATH. اقترحت إنشاء ملف dotfile كهذا العلم. قلت أن ~ / go / src ستكون بمثابة هذا العلم. اعتراضي هو أن src نفسها ليست غير شائعة بين المبرمجين ، أي أولئك الذين قد يقومون بتثبيت Go. يتجنب الملف النقطي غير المعتاد ، على سبيل المثال ~ / go / .default-gopath هذا الصدام المحتمل.

إذا قاموا بإنشاء ~ / go for Go وتشغيله يدويًا ، فلن يستخدمه ~ / go لأن الملف النقطي مفقود. أعتقد أن هذا أمر جيد لأنه من خلال البدء في إعداد تثبيت Go ، يجب أن يستمروا في إعداد GOPATH. إنها ليست حالة "تثبيت الحزمة ، تشغيل go (1)" البسيطة التي يتم استهدافها.

إذا لم يتم اعتبار أي من هذا مشكلة ، فلا بأس بذلك. لكن ما دمت تشكو من أنك لا تفهم وجهة نظري ، فأنا محكوم عليّ بمواصلة محاولة شرحها.

لهذا السبب اقترحت في الأصل مسارًا مختلفًا ، مع اقتراح روب أنه الآن خارج يدي رسميًا.

مع ذلك ، يسعدني أنه تم اختيار مسار _a_ لأنني أرى ذلك كنقطة للتمرين.

بسبب مخاوفك ، أوصيك بمتابعة https://go-review.googlesource.com/#/c/32019/ حيث تتم مناقشة المشكلة التي تثير قلقك على وجه التحديد.

RalphCorderoy ، ما

روب وروس مضادان للغاية لملفات dotfiles. من الأفضل تحديد المشكلة بدلاً من ذكر الإجابة إذا كانت الإجابة تتضمن ملفات نقطية (أو روابط رمزية).

bradfitz ، نعم ، ~ / انتقل بالفعل إلى مشغلات gogame ، والمزيد من ~ / go / src موجود لأنهم لاعبون مبرمجون gogame وإلا فلن يلعبوا مع Go. (لدي ~ / chess / src فور حدوثها.)

منطق ملخص adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c يبدو جيدًا ، وأنا أؤيد إنشاء ~ / go إذا لم يكن موجودًا ، ولكن test -d ~/go/src هو اختبار غير مستقر لاستخدام ~ / go إذا لم يكن هناك GOPATH.

إذا لم يكن الأمر كذلك ~ / go ، لكن شيئًا أكثر غرابة ، مثل اقتراح Dave الأصلي ، فلن يكون الأمر مهمًا. أعتقد أن استطلاعات الرأي حول ما هو مستخدم حاليًا والتي أظهرت أن ~ / go كانت شائعة جدًا ليست مفيدة جدًا عندما يكون الناخبون مبرمجي Go حريصين بدرجة كافية على متابعة المشكلات ووسائل التواصل الاجتماعي.

RalphCorderoy ، أعتقد أن مقدار الرعاية والسراويل الداخلية المزدوجة التي يتم تصميمها في CL 32019 أكثر من كافية للإزعاج المحتمل لمجموعة صغيرة من مبرمجي Game of-go الذين _ لم يستخدموا Go قبل الإصدار 1.8 و _ لم يتم تعيينهم GOPATH _and_ بدأوا أيضًا في تعلم اللغة Go.

لن تقوم أداة go بحذف أو إتلاف أي رمز non go يأتي عبره ، بل ستصلك رسالة مربكة بعض الشيء في مواقف قليلة. لتوضيح ذلك ، لن تقوم أداة go بإنشاء مصدر Go أعلى $GOPATH/src لأن هذا الرمز ليس ضمن حزمة قابلة للاستيراد. بالإضافة إلى ذلك ، يتمثل الهدف الآخر من هذا التغيير في تسهيل الحصول على بعض الرموز go get خلال توفير موقع افتراضي لتنزيل المصدر إليه ، لذلك _if_ كان هناك كود مصدر Game-of-go في ~/go/src ، فإن فرص تعارضه مع دليل فرعي مشتق من مستودع go gettable بعيدة جدًا ، وحتى لو حدث ذلك ، فإن أداة go أو git ستتعطل قبل تغيير أي بيانات.

أعتقد أن الموقف الذي يثير قلقك غير مرجح للغاية ، ويخفف من حدة الشرح أعلاه.

(مجرد حجة صحيحة محتملة مقابل GOPATH=$HOME ): هل تم التعامل مع أداء goimports ؟ أتذكر شيئًا عن ملف .goimport_ignore . وإلا فقد يتأثر أداء المحررين المشهورين.

وبالتالي ، من المحتمل أن يكون GOPATH!=$HOME خيارًا خاليًا من الاصطدام / غير ملوث ويجب أن يكون فعالاً.

davecheney بعد go get سيكون لدي حماقة لمحوها من ~ / go / {bin، src، pkg} ولن تكون مقدمة جيدة لـ Go بعد أن ألصق السطر الذي وجدته على الإنترنت.

RalphCorderoy ، يرجى تفهم أن الهدف من هذا التغيير هو تسهيل الأمر على مستخدمي Go الجدد - هذا ليس أنت - لديك بالفعل مجموعة GOPATH $ ، لأنك _لديك _ مع كل إصدار من Go بدءًا من 1.1 وما بعده. التداخل بين مستخدمي go-the-game ومستخدمي go-the-program-language _potential_ (المحتملين) صغير جدًا. لا أعتقد أنه ستكون هناك مشكلة.

RalphCorderoy الموقف الذي تصفه نادرًا ، ولا ينبغي أن يتوقع أي شخص يقوم بتشغيل أوامر shell من موقع ويب عشوائي أنه لن يتم مسح أقراصه ، ناهيك عن تنزيل بعض الملفات وتعديلها في دليل مسمى. (تحرير: النظر في النبيذ لصناعة السيارات في إنشاء وتعديل .wine في الدليل الرئيسي للمستخدم ما إذا كان المستخدم لديه شيء آخر هناك بعد كل شيء، "النبيذ" هو المصطلح الذي نستخدمه لمشروب معين.؟.)

تضارب التسمية بين لعبة "Go" the language و "Go" the board game مفهوم ومعروف بالتأكيد. نظام الملفات هو مورد مشترك ، وتصادمات تحدث ولا مفر منها.

davecheney ، يُرجى التوقف عن إخباري بأن هذا التغيير لا يهدف إلى مساعدتي لأنني لست مستخدم Go جديدًا. لقد كنت دائمًا على علم بذلك حتى قبل أن تبدأ في الإشارة إليه. أنا أفهم أيضًا أن موقعك لين (التقاطع (موجود - ~ / اذهب ، أقل من GOPATH)) صغير جدًا بحيث لا يكون مصدر قلق.

بعد تنظيف go-get spew في ~ / go لأنه كان يعرف ما لم يكن موجودًا بشكل طبيعي ، فسيتعين عليه بعد ذلك البحث ليرى ما الذي قد يفعله الأمر (الأوامر) أيضًا تحت $ HOME في حالة وجود المزيد التنظيف كان مطلوبًا.

إلغاء الاشتراك

أنا آسف إذا كنت قد سببت لك أي إهانة. لم أعد أرغب في المراسلة
معك في هذه المسألة. شكرا لك.

يوم الجمعة ، 28 أكتوبر 2016 ، الساعة 3:28 صباحًا ، RalphCorderoy [email protected]
كتب:

davecheney https://github.com/davecheney ، من فضلك توقف عن إخباري بهذا
لا يهدف التغيير إلى مساعدتي لأنني لست مستخدم Go جديدًا. أملك
كنت دائمًا على دراية بذلك حتى قبل أن تبدأ في الإشارة إليه. أنا أيضا
فهم موقفك لين (تقاطع (موجود- ~ / اذهب ، أقل من GOPATH)) هو
أصغر من أن يكون مصدر قلق.

بعد تنظيف go-get spew في ~ / go لأنه يعرف ماذا
لم يكن هناك بشكل طبيعي ، فسيتعين عليه بعد ذلك البحث ليرى ما الذي يمكن أن يكون
قد يكون الأمر (الأوامر) قد تم تنفيذه ضمن $ HOME في حالة الحاجة إلى مزيد من التنظيف.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/17262#issuecomment -256697043 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney ، لا ، ليس إهانة. فقط ليس هناك فائدة من الاستمرار في تغطية نفس الأرض.

فقط أتساءل - ما هو السلوك المتوقع إذا لم يتم تعيين $HOME ؟

على الرغم من أنني لم أعمل مطلقًا على نظام كان هذا هو الحال ، يبدو أنه من الممكن أن يكون شخص ما قد قام بتعديل متغيرات البيئة الافتراضية الخاصة به لسبب ما ، ويجب التعامل مع حالة الحافة هذه باستمرار.

أعتقد أنه يقيم حاليًا $GOPATH='' ؛ هل هذا يعني أنها ستستخدم دليل العمل الحالي؟

استخدم دليل العمل الحالي

لقد خطر لي أن هذا قد يكون أكثر فائدة لمستخدم Go الجديد الذي لم يقم بتعيين GOPATH. سيكون go get مشابهًا لـ wget ، وما إلى ذلك ، لملء الدليل الحالي. إنهم ليسوا مهتمين بجانب مسار GOPATH في هذه المرحلة ، وربما يريدون تمامًا أن يكون كل مشروع خاص بهم في اللعب بأشياء مختلفة عبر الإنترنت مميزًا ، حيث أن دليلًا مؤقتًا جديدًا من صنعهم سيمنحهم ذلك. يمكنهم الحصول على عمليات إعادة الشراء المختلفة وتشغيلها وحذفها بسهولة.

• إذا لم يتم تعيين GOPATH:
  
  
  
  • في حالة وجود واحد أو اثنين فقط ، وليس كل ، من ~ / {bin، pkg، src}:
  
  
  • عليهم تعيين GOPATH ، pkg هو غير عادي
  
  
  • إما أن يكون الكل أو لا يوجد:
  
  
  • تأكد من وجودهم جميعًا
  
  
  • GOPATH = دولار (pwd)
  
  

لدي مشاعر مختلطة حول هذا الأمر ، لكن شعوري السائد (بصفتي شخصًا حدد $GOPATH ) هو أن سلوك go get يجب أن يكون "حتميًا" وأن يثبت الأشياء دائمًا بأقل من $GOPATH - وجهة متسقة وموثقة جيدًا.

على الرغم من أنني لم أتأثر بهذا التغيير ، إلا أنه من الغريب أن يقوم go get بتنزيل الأشياء إلى مواقع مختلفة اعتمادًا على دليل العمل عند إصدار الأمر. أدرك أن هذا هو ما تفعله wget و npm install والأدوات الأخرى ، لكن يبدو الأمر وكأنه خروج عن فكرة قيمة $GOPATH ثابتة (وهذا ما أفعله فسر روح هذا التغيير).

إذا كان هذا خارج نطاق هذه المشكلة ، فأنا أقترح ببساطة الخروج وإخراج خطأ إذا لم يتم تعيين $HOME بالفعل.

لقد قمت بتدريس 5 مبرمجين جدد جاءوا من عالم جافا في بلد من العالم الثالث .. لقد تم الخلط بينهم جميعًا بالتأكيد بشأن GOPATH. هيك ، لقد كنت أيضًا عندما بدأت مرة أخرى قبل إطلاق Go 1. أنا شخصياً أستخدم "$ HOME / gopath" ولكني أقترح أن يقوم الأمر "go get" بتوجيههم إلى مدونة go التي تكون واضحة حول كيفية إنشاء مسار Go لنظام التشغيل الخاص بهم. هذا كل ما نحتاجه. بعض التوجيهات بأمر "go get" ليست من المواصفات .. لكنها تدوينة بسيطة لعنة !!

من الواضح أنني أعني عندما لم يتم تعيين GOPATH. ما عليك سوى تحديث رسالة الخطأ التي يتم عرضها حاليًا. معدل التبني موجود بالفعل .. فقط بحاجة إلى القليل من المساعدة بدلاً من طريقة google الحالية التي يقوم بها القادمون الجدد.

einthusan أشعر أنه موثق جيدًا على https://golang.org/doc/code.html#GOPATH ، لكنني لا أعرف عدد الأشخاص الذين بدأوا مع Go بالفعل قرأوا هذه الصفحة.

آسف على الرسائل غير المرغوب فيها .. بعد إجراء بعض البحث على Google .. أعتقد أن "go get" يجب فقط مطالبة المستخدم بالقول "لم يتم تعيين GOPATH ... هل ترغب في استخدام دليل العمل الحالي باعتباره GOPATH المؤقت الخاص بك؟" (نعم / لا)

einthusan ، لا توجد سابقة لـ cmd / go للقيام

إذا كان GOPATH الافتراضي الجديد هو $ HOME / go. ألا يتوقع الناس أن يتبنى https://hub.docker.com/_/golang/ نفس السلوك؟

cescoferraro هذا سؤال

الإجابة / الرد على سؤالي الخاص حول عدم تحديد $HOME :

في التطبيق الحالي (تم ربط CL أعلاه) ، يتم تعيين $GOPATH افتراضيًا على "" إذا لم يتم تعيين $HOME : https://go-review.googlesource.com/#/ c / 32019/11 / src / go / build / build.go أعتقد أن هذا يتفق مع السلوك الحالي.

أعتقد أن حالة الحافة هذه غير مرجحة للغاية نظرًا لأن $HOME يتم تعيينه دائمًا في جلسة تسجيل دخول عادية ، وهو على الأرجح الحال بالنسبة لمعظم مبرمجي Go. على الرغم من أنني شخصيًا _ مثل _ يجب توضيح السلوك بشكل صريح ، يبدو أنه لا توجد "آثار جانبية" (مثل تثبيت الأشياء في عمل دير). صححني إذا كنت مخطئا. :)

إذا كان هذا سيسهل على الأشخاص الذين بدأوا بـ Go للمرة الأولى ، فليكن شيئًا مثل المسار الحالي:

GOPATH=$(pwd)

تعيين export GOPATH=$(pwd) يجعل من السهل التبديل بين المشاريع

سلوكي المقترح لهذا التغيير:

متغيرات البيئة

• إذا تم تعيين GOPATH ، فستتصرف الأدوات كما هو الحال دائمًا
• بخلاف ذلك ، نتحقق من متغير البيئة HOME ( home لـ plan9 ، USERPROFILE للنوافذ).
  
  
  
  • إذا لم يتم تعيين متغير 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

حاليًا إذا لم يكن $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 على أساس يومي؟ كنت أفكر حتى أنه ربما يجب أن يكون هناك أمر go لتعيين GOPATH مشابهًا لبدء بيئة افتراضية في دليل عمل Python.

نظرًا لأنني أعمل في عدة مشاريع ، فأنا عادةً ما أفعل شيئًا كالتالي:

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

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

تضمين التغريدة
هذا التغيير يعدل فقط سلوك 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).

تحرير: تظاهر بأن تخفيض سعر Github لم يفسد هذا الأمر تمامًا.

campoy فيما يتعلق src/ ، ما هو السلوك الحالي لـ go get عند تعيين GOPATH ولكن لا يوجد دليل src؟ هل هناك سبب وجيه لعدم إنشائه أيضًا؟

يبدو من الأسهل توضيح ما إذا كان قد تم إنشاء $ HOME / go / src عند أول انتقال (أو $ GOPATH / src إذا تم تعيين متغير البيئة هذا)

اليوم ، عندما يتم تعيين GOPATH ، يتم إنشاء الدلائل الضرورية ، دون قيد أو شرط ، حسب الحاجة.

يذكر CL https://golang.org/cl/33356 هذه المشكلة.

يذكر CL https://golang.org/cl/33730 هذه المشكلة.