Go: cmd / go：設定されていない場合はGOPATH = $ HOME / goと見なします

/ cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

私はそれが好きですが、「gopath」のようなものではなく、「gocode」に特定の好みがありますか？

すでにGOPATH = $ HOME / gocodeを使用している人は何人いますか？ 私には多くはないようです。 これは、デフォルトが間違っていることを示しています。

「gocode」には、人気のあるツールgithub.com/nsf/gocodeとの検索エンジンやその他の混乱があります。

ほとんどの人が何をしているのかについての情報はありますか？

私はGOPATH = $ HOME / gopathを自分で使用しています。

現在GOPATH = $ HOMEを使用している場合は、ここで高く評価してください

現在GOPATH = $ HOME / gopathを使用している場合は、ここで高く評価してください

現在GOPATH = $ HOME / gocodeを使用している場合は、ここで高く評価してください

@golangでTwitterの投票を行う必要がありますか？

@campoy 、いいですね。 おそらく、このバグに全員を招待するよりも良いでしょう。

$ HOME / go（私が使っているもの）はどうですか。

参照： http ：

$ HOME：8.9％
$ HOME / go：50.6％
その他：40.5％

私は本当にこれのためにもっと多くのオプションを分割したかったのに。

投票開始： https ：

水、2016年9月28日には、10：51 AMエドワード・ミュラー[email protected]
書きました：

$ 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ソースコード（go.googlesource.com/go）が頻繁にチェックアウトされています。 コミュニティがこの場所をGOPATHのデフォルトとして祝福したのは悪いことです:(誰かがGOPATHの設定を忘れて、goツールを実行すると、現在の開発ディレクトリが台無しになるのではないかと心配しています。

@rakyllはそれぞれに、私や他の多くの人が何を使っているかを示したかっただけです。 go.googlesource.com/goは、私のシステムの/usr/local/go.gitでチェックアウトされています。

すでにGOPATH = $ HOME / gocodeを使用している人は何人いますか？ 私には多くはないようです。 これは、デフォルトが間違っていることを示しています。

記録のために私はGOPATH=$HOMEを使用しますが、これはあまりにも論争的であり、新しいユーザーのエクスペリエンスを改善するというこの提案の目標を損なうと感じました。

@ freeformz 、$ HOMEの外にある既存の正規パスを気にする必要はないと思います。 GOPATHのデフォルトは$ HOMEのどこかにあり、最小要件は、重要な既存のパスと競合しないことです。

$ HOME / gocodeは私には異質に聞こえますが、それは非常に良い選択かもしれません。

重要なのは、デフォルトが何であるかは重要ではなく、1つあるということだけです。

デフォルトが何であるかは重要です。このデフォルトを設定すると、基本的に、Goを初めて使用するすべての人が数年後にどのように機能するかが決まります。

goコマンドは、GOPATH = $ GOROOTを明示的に指定したときに、混乱しないように邪魔になりません。 暗黙の設定にも同じロジックを適用できると確信しています。 だから私は$ HOME / goを誤って壊してしまう心配はあまりありません。

固定のデフォルトではなく、現在のディレクトリの親を自動スニッフィングして、GOPATHがどこにあるかを把握する必要があるのではないかと思います。 これは、最近多くのソースツール（たとえば、すべてのバージョン管理システム）が行っていることであるため、人々が理解する概念です。 また、1つのディレクトリ名を使用したり、GOPATHワークスペースを1つだけ使用したりする必要はありません。 しかし、元の問題についてその議論をしたほうがよいでしょう。

@rscデフォルトがGOPATH=$HOMEですが、これは$GOPATH/binがパスに含まれることを意味します（少なくともほとんどのLinuxディストリビューションでは、ダーウィンについてはわかりません）。

$GOPATH=$HOME/goも良い選択であり、コンパイラのソースをチェックアウトしている人はすでにGOPATH=something elseので、競合する可能性はありません。

明確にするために、私が言ったとき、私は軽蔑しようとしていませんでした

重要なのは、デフォルトが何であるかは重要ではなく、1つあるということだけです。

この提案の目的を強調しようとするのは、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を明示的に指定したときに、混乱しないように邪魔になりません。 暗黙の設定にも同じロジックを適用できると確信しています。

いいね。

ダーウィンについてよくわからない

ダーウィンではありません。

これが初心者向けの場合は、ホームディレクトリに1つだけではなく、3つのディレクトリが作成されるため、 GOPATH=$HOMEを使用しないことをお勧めします。 私は、自宅のディレクトリを必要以上に汚染するソフトウェアには熱心ではありません。

@mvdan私は理解しています、そしてあなたの反応は私がGOPATH=$HOME提案しなかった理由

_I_が個人的にGOPATHを$HOMEに設定したい場合、そのオプションは引き続き使用でき、この提案がGo 1.8で受け入れられた場合、変更を加える必要はありません。

@davecheney

デフォルトの値はGOPATH = $ HOME / gocode

WindowsにはデフォルトのHOME変数はありません。 Windowsで何をすることを提案しますか？

$ GOPATH / binがパスに含まれることを意味するため、デフォルトをGOPATH = $ HOMEにしたいと思います。

PATHに$ GOPATH / binが含まれていることを常に心配しています。 go getは、他の人のプログラムをそこにインストールします。 新しいGoユーザーがPATHのどこかにインターネットからランダムなプログラムをインストールすることを本当に望んでいますか？

アレックス

私は経験豊富なWindowsユーザーではありませんが、ドキュメントと設定が保存されるベースパスの概念があると思います。 この議論の目的のために、私がWindowsユーザーのコンテキストでそのパスについて話していると仮定します。

そのようなパスが存在しない場合は、C：/ gocodeを想定してください。

GOPATH = $ HOMEについての私のコメントでは、これは私の個人的な好みであり、今後もそうですが、これはデフォルト値の論争の的となるオプションであり、提案された値として提案されなかったことを認識しています。

自動検出には危険が伴います。 私はしばらく前にこれのプロトタイピングを開始しましたが、goツールとユーザーエクスペリエンスの両方にかなりの複雑さが加わりました。

私はパッケージ管理ワーキンググループで起こっていることのループに入っていませんが、GOPATHが完全に排除されるそれほど遠くない未来を想像することができます。

とはいえ、GOPATHが近い将来消えたとしても、デフォルトを設定することには価値があるかもしれません。 GOPATHが消える可能性が高いと思われる場合は、何に設定してもかまいません。

私が上で読んだことから、いくつかのコンセンサスがあります：

1. デフォルトでは、 GOPATH=$HOMEは侵襲的すぎます。
2. デフォルトでは、文字列goどこかに（プレフィックスとして）含める必要があります。

GOPATHがメインのgoリポジトリのクローンであるかどうかについては心配していません（つまり、GOPATH == GOROOT）。 goリポジトリをチェックアウトする人は、GOPATHが設定されている可能性があります。 goツールは、今日のように、とにかく競合を検出します。

それを念頭に置いて、最も簡潔なデフォルトは$HOME/goであり、これは非常に合理的だと思います。

ドキュメントと設定が保存されるベースパスの概念があると思います。

そんなことは知らない。 おそらく他のWindowsユーザーがここにコメントするでしょう。

そのようなパスが存在しない場合は、C：/ gocodeを想定してください。

代わりにC：gocodeが必要です。
C：\のルートに物事を置くことは、私には正しく聞こえません。 LinuxでGOPATHを/ gocodeに設定することをお勧めしますか？
ただし、Windowsインストーラーが既にGo into C：goをインストールしていることを考えると、GOPATHのC：gocodeは少なくとも一貫性があります。

アレックス

ただし、Windowsインストーラーが既にGo into C：goをインストールしていることを考えると、GOPATHのC：gocodeは少なくとも一貫性があります。

GOPATHを各ユーザーに提供するべきではありませんか？ UNIXと同じように、 %USERPROFILE%\gocodeだと思います。

https://goo.gl/xAsgEjでのGo +投票

$ HOME / go-programsのようなものを長い間使用した後、GOPATHを$ HOMEに切り替えました。 だから、今私は次の構造を持っています：

$ HOME / bin
$ HOME / pkg
$ HOME / src /
$ HOME / src / github.com / user / some_github_project
$ HOME / src / some_project

この構造はより一般的であり、他の言語やプロジェクト、およびgithubで使用するためにも使用できます。 たとえば、$ HOME / src / talks（マークダウンファイルについてはhome / sources / talksを読んでください）またはいくつかの言語の他のプロジェクト（$ HOME / src / github.com / user / htmlなど）がありますが、ソースもあります。 github対応の有無にかかわらず、多くのプロジェクトソースの場所。

binまたはpkgは厄介と見なすことができますが、それほど迷惑ではないと思います。 複数の言語を使用する人々のために多くのソースフォルダを用意するのはもっと面倒です。

したがって、私の観点からすると、GOPATHの最適な場所は$ HOMEです。

GOPATHとして$ HOME / gocodeを使用しています。
ルート権限がなく、ホームディレクトリの下にGoをインストールする必要がある場合があるため、$ HOME / goには反対です。 そのような場合、GOROOTには$ HOME / goが最適だと思います。
したがって、GOPATHとして$ HOME / goとは異なるものを使用する必要があります。

@hnakamur Goを手動でインストールしたとき（現在はUbuntu Makeを使用）、$ HOME / bin / go- $ {go_version}に配置しました（$ HOME / bin / goから$ HOME / bin / go- $へのシンボリックリンクを使用） {バージョン} / bin / goなので、$ PATHを編集する必要はありませんでした）

@tbroyerそれはニッチです。 ほとんどのユーザーは、追加の構成や設定を望んでいないと思います。 私の意見では、〜/ binはすでに（私のように）独自のスクリプトまたはバイナリを配置するために使用されています。 そして、〜/ bin（〜/ src、〜/ pkg）を使用すると、goバイナリを削除するのが難しくなると思います。

GOPATHに$ HOMEを使用しています。
なぜGOPATHを自動設定するのか、GOPATHが存在しない場合に設定する方法について、適切な情報とともに警告を表示しないのはなぜですか？

なぜGOPATHを自動設定するのか、GOPATHが存在しない場合に設定する方法について、適切な情報とともに警告を表示しないのはなぜですか？

問題は、人々が環境変数を設定する方法を知らないということではありません（ほとんどの場合）、それはあなたが行ったとしても、Goを使い始めるためにフープを飛び越えなければならないのは気分が悪いということです。 インストール後すぐに正常なデフォルトでGoを使用できるようになると、エクスペリエンスが可能な限りシームレスになり、障害にぶつかったり勢いを失ったりする代わりに、ダウンロード後に実際にGoを試す人が増える可能性があります。それをいじる価値がないと判断する。

私はクリスとアンドリューに同意する傾向があります。デフォルトのGOPATHがある場合は、gopathやgocodeではなく、$ HOME / goだけにする必要があります。 _ほとんどの_ユーザーはGoディストリビューションをチェックアウトしていません（そして今日チェックアウトしているすべてのユーザーはすでにGOPATHを設定しているので、これは彼らを悩ませることはありません）。 デフォルトは、上級ユーザーではなく、新しいユーザーにとって意味がある必要があり、ほとんどのユーザーにとって、$ HOME / goは非常に意味があります。

Jaanaは、$ HOME / goがたまたまGoディストリビューションである場合、goコマンドが混乱することについて懸念を表明しましたが、goコマンドはすでに偶発的なGOPATH = $ GOROOTをチェックしています。 GOPATHが暗黙的に設定されている場合も、それが当てはまるかどうかを簡単に確認できます。 実際、GOROOT！= $ HOME / goであるが、$ HOME / goが行う場合でも混乱を避けるために、たとえば$ HOME / go / src / cmd / go /alldocs.goを探すためにチェックを拡張することも簡単です。 Goディストリビューションが含まれています。

$ HOME / goはGOPATHに適したオプションではありません。 動作の簡単な演習を行いましょう...新しいユーザーは、ベストプラクティスのようにデフォルトを簡単に検討できます。 私が新しいユーザーだとしましょう、なぜデフォルトを悪いことと見なす必要がありますか？ それ以上に、golangをインストールする最も簡単な（そして最良の？）方法は、$ HOMEで解凍することです。この方法では、コンパイラーは常に最新バージョンであり、root権限を必要としないため、多くのユーザーがgoコンパイラーを使用していると簡単に推測できます。 $ HOME / goにあります。 単純に移動できなかったのに、コンパイラを/ usr / localに移動する必要があるのはなぜですか？
それ以上に、彼らはプロジェクトを作成し、このフォルダーにプロジェクトを複製することができます。 そのため、フォルダが乱雑になり、少し不注意で、新しいgolangの再インストールでプロジェクトフォルダを簡単に削除できます。
また、Windowsユーザーにはデフォルトでc：goがあります。

$ HOME / gopathが好きです。 それが何であるかを言います。
「gopath」のGoogleでの最初の結果は、正しいページです。

デフォルトが採用されている場合、 func GOPATH() string関数をruntime追加できますか？ 現在、 os.Getenv()使用できますが、デフォルトではそれほど単純ではありません。

@ btracey 、GOPATHはリストであり、単一の値ではありません。 filepath.SplitListます。 また、GOPATHはランタイムの機能ではありません。 cmd/goのみに関係します。

下位互換性のために、おそらくプロセスでGOPATHを設定する必要があります。
何も設定されていない場合は環境。

8時10分に2016年9月30日には、ブレンダン・トレイシー[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
。

あなたは正しい@bradfitzです。 @adgによって提案されたソリューションは、私のすべての用途に適合します。

これは面白いしわです。 私はこれが現在失敗しているのを見ることができます
GOPATHが設定されますが、GOPATHに複数の値が含まれている場合も、
アプリケーションが1台のマシン上に構築され、
別。

私はGOPATHのこの使用法を却下したくありません、私はの痛みを理解しています
アプリケーションのサポートファイルを見つけることができますが、
この使用法がどれほど普及しているか、そして現在どのようになっているのかを理解する
実装は、上記で強調した問題に対処します。

金、2016年9月30日には、午前8時35分ブレンダン・トレイシーの[email protected]は書きました：

そうです@bradfitzhttps ：//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のこの使用法を理解したかっただけです
私が強調した制約。

金、2016年9月30日には、午前9時09分ブレンダン・トレイシーの[email protected]は書きました：

私の使い方は普通ではありません。 私は科学的研究をしています、そして私は見つけました
gopath / srcとgopath / binだけでなく、
gopath / dataおよびgopath / results。 これにより、ソースを簡単にコピーできます
（ギガバイトの）をコピーすることなく、新しいシステムにファイルを転送します
結果ファイル。 新しいシステム（クラスターなど）は、新しい結果ファイルを生成します。
そして、それらの結果を中央の場所にコピーできます。 本当に簡単です
次に、gopath = os.Getenv（ "GOPATH"）と言い、ファイルをfilepath.Join（gopath、
「results」、「projectname」、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 、＃12773は、この問題を直接回避するよりも使いにくいです。 ファイルを必要とする（またはファイルを保存する）特定のコードは多くの場所を移動する可能性があり、リファクタリングとは独立して（そしてリファクタリングとは別に）入力/出力を配置するための固定された場所が必要です。

この問題は、GOPATHの可能なデフォルト値に関するものです。 GOPATHの代替使用については_ありません_。

この変更の対象ユーザーが、
Goで書かれた新しいプログラムをインストールしますが、実際にインストールしたいプログラムはインストールしません
Goと書いて、ユーザーごとのディレクトリにクローンを作成します。
$ TMPDIR、および$ GOPATHが設定されていない場合は、バイナリを$ PWDのままにしますか？ （明らかに
これは、go get import.path / for / a / commandがない場合にのみ、意味があります。
コマンド、go getは、$ GOPATHが設定されていないと失敗するはずです）

部外者にとって、これはファイルをwgetするのと同じように非常に理にかなっています。

ユーザーがGoコードの記述を開始したい場合は、設定方法を学ぶ必要があります
GOPATHを正しく。

ルート権限がなく、ホームディレクトリの下にGoをインストールする必要がある場合があるため、$ HOME / goには反対です。 そのような場合、GOROOTには$ HOME / goが最適だと思います。

Linuxシステムを使用している場合、$ HOME / .localの目的の解釈方法によっては、$ GOROOTの最適な場所は$ HOME / goではなく$ HOME / .local / opt / goである可能性があると私は主張します。 、$ HOME / .local / share（ミラー/ usr / local / shareに表示される）のみがXDGベースディレクトリ仕様で定義されているため： https ：

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/またはPRをレビューする人にとって合理的と思われるものを選ぶことができ、状況はおそらくかなり大丈夫です。

権限の問題があるため、システム全体のGOPATHは初心者ではないと思います。

。

システム全体のパスは、良くも悪くも、ディストリビューションを行うGOROOTです。
debianが「システム全体」のパッケージをインストールするために使用しているように、
悪い。

システム全体のGOPATHは、この提案の範囲外です。この提案
ログインしたユーザーの値から派生したパスを推奨します。

火、2016年10月4日には、午前8時52アンドリュー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のデフォルトとして問題にならないという別の理由を指摘することでした。とにかく、Go（別名GOROOT）のローカルユーザーインストールにとって最も「慣用的なLinux」パスではないからです。

それ以外は、デフォルトのGOPATHにXDG_CACHE_HOMEを使用することが以前に議論されたと思います。そのため、XDG_DATA_HOMEについて言及しました。ただし、リンクされたドキュメントの作成者がどの役割を果たしているか、またはそれがどの程度「公式」であるかはわかりません。 。

$ HOME / work......。

@adg @quentinmit @rscこの提案の次のステップは何ですか？

ここで何かが起こるのを本当に見たいです。 それは私のクラスで頻繁に問題になるポイントです。 デフォルト（私が同意しない$ home / goでさえ:)）は、なしよりも優れています。

$ HOME / goになります。 単一の最良の答えはありませんが、これは短くて甘いものです。$ HOME / goがすでに存在する場合にのみ、その名前を選択することが問題になる可能性があります。これは、すでにインストール済みでGOPATHを理解している専門家にのみ役立ちます。

誰がその仕事をしたいですか？

私はこれに取り組むことを間違いなく嬉しく思います。

@campoy 、あなたはそれをすることができます<=

そうだと思います、はい@bradfitz 。 大量のコードを実行する必要はないようです。
明日から始められます。

更新：私はこれをざっと見て、すでにいくつかのコードを書きました、いくつかのテストを追加し、今日の後半に変更を送信します

これは素晴らしい人です！ 👍

@ robpike ＃17271の私の代替案も検討しましたか？ この提案がより良いと見なされた理由を理解したい

Goインストールディレクトリとワークスペースディレクトリの名前を同じにすることはお勧めできません。つまり、 goです。理由は次のとおりです。

1）ユーザーがホームディレクトリでtar -xzf go$VERSION.$OS-$ARCH.tar.gzを実行すると、ナイーブなユーザーがワークスペースを破損/汚染するのは非常に簡単です。

2） /usr/localインストールしない場合（rootとしてインストールしたくない場合）の新しいユーザーのデフォルトのエクスペリエンスは、次のフローになるためスムーズではありません。
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場合、 GOROOTとGOPATHを同じにすることはできないため、このデフォルトは発生しないか、 goエラーが発生することを理解しています。 このような場合、前述のように、ユーザーは独自のGOPATHを設定するのに十分な能力があることが期待されます。

@mvdan正解です。インストールにroot権限を使用したくない（したがって、Goを〜/ goにインストールする可能性が高い）新規ユーザーの場合、明示的に実行する必要があるため、簡単に起動して実行することはできません。 GOPATHを別の値に設定します。 デフォルトのGOPATHが〜/ gopathまたは〜/ gocodeの場合、これは簡単に修正できます。

ルート以外のインストールの場合、新しいユーザーがデフォルトのGOPATH =〜/ goを利用する必要がある場合は、インストールしないようにユーザーにtar -Cオプションを使用するように明示的に要求することにより、インストールドキュメントを少し複雑にする必要があります。 ~/go

@ rasky ＃17271とこの提案は直交していると思います。 この提案の解決は、私たちを特定の方向に押しやることのない簡単な勝利です。 その問題についてさらに詳しく説明します。

@krishnasrinivasに同意します。 ルート権限がなかったので、$ HOME / goに移動しました。 $ GOPATH = $ HOME / goworkも設定しました。

@ krishnasrinivas @ joegrasse完璧な解決策はありません。 GOPATH自分で設定するのは簡単で、ほとんどの人がそうすることを期待しています。 ここでの問題は、Goを初めて使用する人々のために何をすべきかということです。 これらは一般に、カスタムの場所に独自のGoディストリビューションをインストールしている人ではありません。 Goをカスタムの場所にインストールする方法を理解できる人は、 GOPATHを設定する方法を理解できます。

プリインストールされたGoディストリビューションを使用している新しいプログラマーのクラスの代わりに考えてください。 Goコードの記述を開始できるようにしたいと考えています。 最初のステップを「これが環境変数です。これが設定方法です。次にGOPATHをこれに設定します」ということは望ましくありません。 これらの手順は、Go自体とは何の関係もありません。

繰り返しますが、完璧な解決策はありませんが、何かを選ぶのが賢明なようです。

@ianlancetaylor私は何かを選ぶべきであることに完全に同意します。 ./goにアンタールすることで、デフォルトで$ HOME / goに設定するのは、最善の選択ではないかもしれないと私は信じています。

前述の理由により、 @ ianlancetaylor GOPATH = $ HOME / gopathはGOPATH = $ HOME / goよりも適切なデフォルトです。

現在の名前は問題ではないと思います。ホームディレクトリの下にあるカスタムのgo / binの場所にPATHを設定する方法を知っている場合は、GOPATHを設定する方法を知っています。

@ joegrasse @ krishnasrinivas 「カスタムの場所へのインストール」をご覧ください。

権限などの理由で/usr/local/go以外の場所に解凍する場合は、GOROOTも設定するか、ソースからコンパイルする必要があります。

それが事実である限り、提案された$ HOME / goよりも$ HOME / gopathなどを使用することに利点はありません。

新しいユーザーはtar.gzからインストールすることを好むと想定しています。 私は引用できません
数字ですが、あなたが答えるのはLinuxのインストールに基づいていると信じています。
goの3番目に人気のあるインストールターゲットです。

2016年10月25日火曜日、20：28クリシュナスリニバス[email protected]
書きました：

@mvdan https://github.com/mvdan正解、したくないユーザー向け
インストールにroot権限を使用する（したがって、インストールする可能性が高い）
Go in〜 / go）私たちは物事を簡単に立ち上げて実行できるようにしているわけではありません
GOPATHを他の何かに明示的に設定する必要があります。 これは可能性があります
GOPATHが〜/ gopathまたは〜/ gocodeの場合、簡単に修正できます

ルート以外のインストールの場合、新しいユーザーがデフォルトを利用する必要がある場合
GOPATH =〜/ go次に、ドキュメントをもう少し複雑にする必要があります
でインストールしないようにtar-Cオプションを使用するようにユーザーに明示的に要求する
〜/ go

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -255984498、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
。

ドキュメントもすべて更新する必要があります。 それはおそらく仕事の大部分です。

午前10時14分に2016年10月25日、フランチェスクCampoy [email protected]
書きました：

そうだと思います、はい。 大量のコードを実行する必要はないようです。
明日から始められます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -255892314、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
。

そうだと思います、はい。 大量のコードを実行する必要はないようです。
明日から始められます。

2016年10月24日月曜日午後4時5分ブラッドフィッツパトリック[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では同等のもの）置き換えることができますか？

PATHに$HOME/go/binを追加したので（またはGOPATHが設定されている場合は$GOPATH/bin ）...

おそらく、ある時点で、ドキュメントは、個人がPATH環境変数を設定するだけでなく、GOPATHを$ HOME / goに設定することを期待する可能性があります。 冗長ではありますが、後でGOPATHを参照できるようにユーザーを準備します。

初期のドキュメントではデフォルトを想定しており、環境変数についてはまったく触れていません。

新しいユーザーはtar.gzからインストールすることを好むと想定しています。 私は引用できません
数字ですが、あなたが答えるのはLinuxのインストールに基づいていると信じています。
goの3番目に人気のあるインストールターゲットです。

そうです、私の意見はLinuxのインストールに偏っています。 goを/ usr / localにインストールする新規ユーザーの場合、〜/ goは〜/ gopathよりも認識しやすいディレクトリ名である可能性があります。

初期のドキュメントはデフォルトを想定しており、言及されていない可能性があります
環境変数はまったく？

うん、うまくいけば、GOPATHの設定に関するすべての気が散る議論を動かすことができます
インストールドキュメントの付録に、GOROOTの場合と同じように
現在。

水、2016年10月26日には、午前6時01ネイサンヤングマンの[email protected]は書きました：

たぶん$ HOME / go / ...を代わりに置き換えることができます（または同等のもの
ウィンドウズ）？

PATHに$ HOME / go / 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ユーザーには次の2つのタイプがあります。

• 行くだけのユーザー-既存のパッケージを入手する
• Go開発者であるユーザー

デフォルトのGOPATHは、最初のグループのケースを修正しています。 開発者向けのドキュメントについては、GOPATH関連の手順を引き続き使用できます。 インストールでは、GOPATHの設定について言及する必要はもうありません。そうでない場合は、 @ davecheneyが言及しているように付録を

Goのために〜/ bin / goの名前を変更しなければならなかった人として、デフォルトが何であれ、それがすでに存在する場合は、それが本当にGoの〜/ goであることを示すために.dotfileを含める必要があることを提案したいと思います。 〜/ goが存在しない場合、goはそれを作成し、.dotfileを作成し、将来の実行でそれを見つけることができます。 GOPATHを明示的に〜/ goに設定した場合、デフォルト値が使用されていないため、.dotfileは必要ありません。

dotfileが存在します。 これは、$ HOME / go内のsrc /ディレクトリです。

水では、2016年10月26日は、7時59分RalphCorderoy [email protected]書きました：

Goのために〜/ bin / goの名前を変更しなければならなかった人として、私は提案したい
デフォルトが何であれ、それがすでに存在する場合は、
その中の.dotfileは、それが本当にGoの〜/ 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
。

CLhttps ： //golang.org/cl/32019はこの問題について言及しています。

一部のプログラマーは環境変数を認識していなくても、
少なくとも_variables_に精通している必要があります。 必要になると思います
ドキュメント内のワークスペースの場所を説明するために何かを使用する、および
文字列$GOPATHそうかもしれません。

6時24分に2016年10月26日、Jaana Burcuドーガン[email protected]
書きました：

初期のドキュメントはデフォルトを想定しており、環境については言及していません
変数はまったくありません。

SGTM

Goユーザーには次の2つのタイプがあります。

• 行くだけのユーザー-既存のパッケージを入手する
• Go開発者であるユーザー

デフォルトのGOPATHは、最初のグループのケースを修正しています。 私たちはまだ保つことができます
開発者向けのドキュメント向けのGOPATH関連の手順。 NS
インストールでは、GOPATHの設定について言及する必要はもうありません。
@davecheneyhttps ：//github.com/davecheneyとして付録を持つことができ
言及します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -256149104、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
。

おかげさまで意図しておりますので、元の提案をご覧ください。

事実上、「gogetはソースをフォルダにダウンロードします」と言うことができます
呼び出されました。ホームディレクトリ内のgo / src / github.com / Foo / Bar」

水、2016年10月26日には、午前6時01ネイサンヤングマンの[email protected]は書きました：

たぶん$ HOME / go / ...を代わりに置き換えることができます（または同等のもの
ウィンドウズ）？

PATHに$ HOME / go / binを追加したので（GOPATHが
設定）...

おそらくある時点で、ドキュメントは個人がそうしないことを期待する可能性があります
PATH環境変数を設定するだけでなく、GOPATHを$ HOME / goに設定します。
冗長ではありますが、後のドキュメントが明確になります。

初期のドキュメントはデフォルトを想定しており、環境については言及していません
変数はまったく？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -256142424、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
。

これはHacktoberfestの最後の週にとって大きな問題になるでしょう

dotfileが存在します。 これは、$ HOME / go内のsrc /ディレクトリです。

「src」は、「これはGoによってデフォルトのGOPATHとして作成された」ドットファイルであることが一般的な方法です。

あなたが防ごうとしていることは何ですか？

9:20の水、2016年10月26日には、RalphCorderoy [email protected]
書きました：

dotfileが存在します。 これは、$ HOME / go内のsrc /ディレクトリです。

「src」は、「これはデフォルトのGOPATHとして作成された」であることが一般的な方法です。
ゴー」ドットファイル。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -256194536、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
。

$ HOME / goになります。

Windowsユーザーにとってはどうなるでしょうか？

アレックス

Windowsユーザーは、Dockerがここで使用するのと同じように、 %USERPROFILE%\goを使用します。

@ davecheney 、2時間前に言ったことを防ごうとしています： //github.com/golang/go/issues/17262#issuecomment -256173981

囲碁は一般的な言葉です。 〜/ bin / goがありました。 人々は囲碁をプレイし、囲碁のプレイに関係するソースコードを持っています。 srcが含まれているという理由だけですでに存在している場合、デフォルトで〜/ goをナブするのは失礼です。 〜/ goが存在しない場合、Goは名前を取得し、ディレクトリを作成し、golang.orgドメイン名などに基づいて、重要なドットファイルをgolangとしてスタンプします。

それが問題であり、とにかく可能な解決策です。 解決策が正しくない場合でも、問題が存在しないという意味ではありません。

私は$ HOME /グループに投票します

ありがとう。

GOPATHのデフォルトを~/.gosrcとして使用できますか？

GOPATHのデフォルトを~/.gosrcとして使用できますか？

これは、LinuxおよびOS Xではデフォルトで非表示になり、Windowsでは表示されます。 GOPATHを隠す動機は何でしょうか？

デフォルトの値に関する議論は1か月前に行われました。 $HOME/goの決定は行われ、すでに実装されています。 そのトピックに戻ると、スレッドが耐えられないほど長くなるだけです。

人々は囲碁をプレイし、囲碁のプレイに関係するソースコードを持っています。

私は実際にはあなたをフォローしていませんが、GOPATHをに設定していることを考えると
すでに何か他のものがあれば、あなたに影響はありません。

9:43の水、2016年10月26日には、RalphCorderoy [email protected]
書きました：

@davecheney https://github.com/davecheney 、私は私が何を防ごうとしている
2時間前に言った：＃17262（コメント）
https://github.com/golang/go/issues/17262#issuecomment -256173981

囲碁は一般的な言葉です。 〜/ bin / goがありました。 人々はGoをプレイし、ソースコードを持っています
囲碁をすることと関係があります。 すでに存在する場合は、デフォルトで〜/ goをナブします。
たまたまsrcが含まれているので失礼です。 〜/ goが存在しない場合は、Go
名前を取得し、ディレクトリを作成し、golangとしてスタンプします。
重要なドットファイル。たとえば、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を理解している専門家にのみ満足します」。 長い間golangに包まれていると、「go」という言葉がどれほど一般的であるか、ボードゲームのような他の意味を持っているかをまとめて忘れていると思います。

この変更は、Goの初心者を対象としており、一部のユーザーは、Go以外で使用するためにすでに〜/ goを使用している可能性があります。 goが実行され、GOPATHが設定されておらず、〜/ goが存在しない場合は、名前を取得して作成する可能性があります。 ただし、〜/ goが存在する場合は、以前のGOPATHなしの呼び出しで作成されたことがわかる場合にのみ使用する必要があります。 このフラグとしてドットファイルを作成することを提案しました。 〜/ go / srcがそのフラグとして機能するとおっしゃいました。 私の異議は、src自体はプログラマー、つまりGoをインストールする可能性のあるプログラマーの間では珍しいことではないということです。 〜/ go / .default-gopathなどの異常なドットファイルは、この潜在的な衝突を回避します。

手動で〜/ go for Goを作成し、GOPATHなしでgoを実行した場合、ドットファイルがないため、〜/ goは使用されません。 Goインストールのセットアップを開始することで、GOPATHを設定し続ける必要があるため、これは問題ないと思います。 これらは、対象となる単純な「パッケージのインストール、go（1）の実行」のケースではありません。

これのどれも問題と見なされない場合、それは問題ありません。 しかし、あなたが私の主張を理解していないと不平を言う限り、私はそれを説明しようとし続ける運命にあります。

そのため、私は当初、別の方法を提案しましたが、Robの提案により、正式には手に負えなくなりました。

そうは言っても、演習のポイントとして_a_パスが選択されたことをうれしく思います。

あなたの懸念については、 https： //go-review.googlesource.com/#/c/32019/をフォローすることをお勧めします

@RalphCorderoy 、あなたの懸念はボードゲームハッキングのための〜/ goディレクトリを持っている囲碁ゲームプログラマーですか？

ロブとラスは非常に反ドットファイルです。 答えにドットファイル（またはシンボリックリンク）が含まれている場合は、答えを述べるよりも問題を述べる方がよいでしょう。

@bradfitz 、はい、〜/ goは

adgの要約ロジックhttps://go-review.googlesource.com/c/32019/#message-09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5cは問題ないようです。存在しない場合は〜/ goを作成することに賛成ですが、 test -d ~/go/srcは、GOPATHがない場合に〜/ goを使用するための不安定なテストです。

〜/ goではなく、Daveの最初の提案のように、もっと変わったものであれば、それは問題ではありません。 有権者が問題やソーシャルメディアをフォローすることに十分熱心なGoプログラマーである場合、〜/ goが非常に人気があることを示した、現在使用されているものの調査はあまり役に立ちません。

@RalphCorderoy CL 32019に組み込まれているケアとダブルパンツの量は、バージョン1.8より前の囲碁を使用しておらず設定していない少数の囲碁プログラマーにとって潜在的な不便を十分に満たすと思います。 GOPATH_and_も言語である囲碁を学び始めています。

goツールは、出くわしたgo以外のコードを削除したり破損したりすることはありません。ごくわずかな状況では、少し紛らわしいメッセージが表示されるだけです。 これを説明するために、goツールは$GOPATH/srcの先頭にGoソースをビルドしません。これは、そのコードがインポート可能なパッケージ内にないためです。 さらに、この変更のもう1つの目標は、ソースをダウンロードするデフォルトの場所を提供することで、コードのgo get簡単にすることです。したがって、 ~/go/src囲碁のソースコードがありました。

あなたが懸念している状況は非常にありそうもないと思います、そして上記の説明によってさらに緩和されます。

（ GOPATH=$HOMEに対しておそらく有効な議論です）： goimportsのパフォーマンスは対処されていますか？ .goimport_ignoreファイルについて何か覚えています。 そうしないと、人気のある編集者のパフォーマンスが低下する可能性があります。

したがって、 GOPATH!=$HOMEは衝突のない/汚染されていないオプションである可能性が高く、パフォーマンスが高いはずです。

@davecheney go get後、私は〜/ go / {bin、src、pkg}をクリアするのが面倒で、インターネットで見つけた行を貼り付けたGoの良い紹介にはなりません。

@RalphCorderoyこの変更の目的は、新しいGoユーザーが簡単に利用できるようにすることです（これはあなたではありません）。1.1以降のGoのすべてのバージョンで、すでに$ GOPATHが設定されているためです。 囲碁ユーザーと_潜在的な_囲碁言語ユーザーの間の重複は非常に小さいです。 問題はないと思います。

@RalphCorderoyあなたが説明している状況はまれであり、ランダムなWebサイトからシェルコマンドを実行している人は、ディスクがワイプされないことを期待するべきではありません。 （編集：Wineがユーザーのホームディレクトリで.wineを自動作成および変更することを検討してください。ユーザーが他に何かを持っている場合はどうなりますか？結局のところ、「wine」は特定の飲料に使用する用語です。）

言語の「囲碁」とボードゲームの「囲碁」の命名の衝突は確かに理解されており、よく知られています。 ファイルシステムは共有リソースであり、衝突が発生し、避けられません。

@davecheney 、私は新しいGoユーザーではないので、この変更は私を助けることを目的としていないと言ってはいけません。 あなたがそれを指摘し始める前から、私はいつもそれを知っていました。 また、あなたの位置がlen（intersect（existing-〜 / go、GOPATH-less））が小さすぎて心配できないことも理解しています。

go-get spew in〜 / goをクリーンアップした後、通常はそこに何がないかを知っていたので、さらに多くの場合に備えて、コマンドが$ HOMEの下で他に何をしたかを調べる必要がありました。クリーンアップが必要でした。

退会

ご迷惑をおかけして申し訳ございません。 私はもう対応したくない
この問題についてあなたと一緒に。 ありがとうございました。

3：28 AMで金、2016年10月28日には、RalphCorderoy [email protected]
書きました：

@davecheney https://github.com/davecheney 、これを言うのをやめてください
私は新しいGoユーザーではないので、変更は私を助けることを目的としていません。 私が持っています
あなたがそれを指摘し始める前でさえ、常にそれを知っていました。 私も
あなたの位置がlen（intersect（existing-〜 / go、GOPATH-less））であることを理解してください
小さすぎて気になりません。

goをクリーンアップした後-彼は何を知っているので〜/ goで吐き出します
通常はそこにいなかったので、彼は他に何があるかを調べるために調査する必要がありました
さらにクリーンアップが必要な場合に備えて、コマンドは$ HOMEの下で実行された可能性があります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/17262#issuecomment -256697043、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
。

davecheney、いいえ、違反ではありません。 同じ地面をカバーし続ける意味はありません。

疑問に思っています– $HOMEが設定されていない場合、予想される動作は何ですか？

私はそのようなシステムで作業したことはありませんが、誰かが何らかの理由でデフォルトのenv変数を変更した可能性があり、このエッジケースは一貫して処理する必要があります。

現在、 $GOPATH=''評価していると思います。 これは、現在の作業ディレクトリを使用することを意味しますか？

現在の作業ディレクトリを使用する

これは、GOPATHを設定していない新しいGoユーザーにとって最も役立つかもしれないと思いました。 go getは、現在のディレクトリを埋めるwgetなどに似ています。 彼らは現時点ではGOPATHのパスの側面に興味がなく、自分たちで作った新しい一時的なディレクトリが彼らに与えるので、おそらく彼らのすべての冒険が異なるオンラインのもので遊んでいることを区別したいと思っています。 参照されているさまざまなリポジトリを取得、実行、および簡単に削除できます。

• GOPATHが設定されていない場合：
  
  
  
  • 〜/ {bin、pkg、src}のすべてではなく1つまたは2つだけが存在する場合：
  
  
  • 彼らはGOPATHを設定する必要があります、pkgは珍しいものです
  
  
  • それ以外の場合は、すべてまたはまったく存在しません。
  
  
  • それらがすべて存在することを確認します
  
  
  • GOPATH = $（pwd）
  
  

私はこれについてさまざまな感情を抱いていますが、（ $GOPATHを設定した人としての）私の一般的な感情は、 go get動作は「決定論的」であり、常に$GOPATH下にインストールする必要があるというものです–一貫性があり、十分に文書化された宛先。

この変更の影響を受けませんが、コマンドが発行されたときの作業ディレクトリに応じて、 go getがさまざまな場所にダウンロードするのは奇妙に感じます。 これがwget 、 npm install 、およびその他のツールの機能であることは承知していますが、一貫した$GOPATH値の概念からの逸脱のように感じます（これが私のやり方です）この変更の精神を解釈しました）。

これがこの問題の範囲を超えている場合、 $HOMEが実際に設定されていない場合

私は第三世界の国のJavaの世界から来た5人の新しいプログラマーを教えました..彼らは皆GOPATHについて確かに混乱していました。 Go 1がリリースされる前に戻ったとき、私もそうだった。 私は個人的に「$ HOME / gopath」を使用していますが、「go get」コマンドを使用して、オペレーティングシステムのgoパスを作成する方法について明確なgoブログを紹介することをお勧めします。 必要なのはそれだけです。 仕様ではない「goget」コマンドによるガイダンスがいくつかあります。しかし、非常に単純なブログ投稿です。

明らかに、GOPATHが設定されていない場合を意味します。 現在表示されているエラーメッセージを更新するだけです。 採用率はすでにあります。新規参入者が行っている現在のグーグルイットアップ方法の代わりに、ちょっとした助けが必要です。

@einthusan https://golang.org/doc/code.html#GOPATHでかなりよく文書化されているように感じ

スパムでごめんなさい..グーグルをした後..「goget」は、「GOPATHが設定されていません...現在の作業ディレクトリを一時的なGOPATHとして使用しますか？」とユーザーにプロンプ​​トを表示するだけでよいと思います。 （はい・いいえ）

@ einthusan 、cmd / goがインタラクティブなプロンプトを実行する前例はありません。

新しいデフォルトのGOPATHが$ HOME / goの場合。 人々はこのhttps://hub.docker.com/_/golang/が同じ動作を採用することを期待しませんか？

@cescoferraroそれはそのイメージのメンテナへの質問です。 「公式」と表示されているにもかかわらず、そのプロジェクトはGoと提携していません。

未設定の$HOMEに関する私自身の質問への回答/回答：

現在の実装（CLは上記にリンクされています）では、 $HOMEが設定されていない場合、 $GOPATHデフォルトで""ます： //go-review.googlesource.com/#/ c / 32019/11 / src / go / build /build.goこれは現在の動作と一致していると思います。

$HOMEは常に通常のログインセッションで設定されるため、このエッジケースはほとんどありそうにないと思います。これはほとんどのGoプログラマーに当てはまる可能性があります。 個人的には動作を明確にしたいと思いますが、「副作用」（作業ディレクトリにインストールするなど）はないようです。 私が間違っている場合は私を訂正してください。 :)

これがGoを初めて使用する人にとって簡単にするためである場合は、現在のパスのようなものにします。

GOPATH=$(pwd)

export GOPATH=$(pwd)を設定すると、プロジェクトを簡単に切り替えることができます

この変更に対して提案された動作：

環境変数

• GOPATHが設定されている場合、ツールはいつものように動作します
• それ以外の場合は、 HOME （plan9の場合USERPROFILE home 、Windowsの場合はUSERPROFILE ）環境変数を確認します。
  
  
  
  • その環境変数が設定されていない場合、 GOPATHも設定されません。これは、「goget」が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として真剣に使用しているのか知りたいですか？ Pythonの作業ディレクトリで仮想環境を開始するのと同じようにGOPATHを設定するgoコマンドがあるべきだとさえ考えていました。

私は複数のプロジェクトに取り組んでいるので、通常は次のようなことをします。

$ 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は「goget」中にのみ作成されることがわかったので、「go get -v」の残りの動作と一致して、-vフラグが指定されている場合にのみメッセージを出力しましょう。
2. ディレクトリが作成された場合、メッセージは最大で

＃作成されたGOPATH = / users / campoy / go; 「gohelpgopath」を参照してください

警告ではありません。警告は悪いです。 一方、作成が失敗した場合は、印刷することをお勧めします

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

GOPATHが推測されているか明示的に設定されているかに関係なく、これらのメッセージは両方とも出力できます。

1. 空のディレクトリとsrcサブディレクトリを持つことに関するヒューリスティックは複雑すぎます。 さらに悪いことに、それらは仮想的な問題に取り組んでおり、仮想的なものを設計することは非常に困難です。 より単純で、より予測可能な動作をする方がよいでしょう。 まず、実際の問題の具体例が出るまでは、ルールを設けないのが理にかなっていると思います。 ベータ期間中に問題を報告し、候補版をリリースする時間があるでしょう。 GOPATH = $ HOME / goを設定しましょう（$ HOMEが設定されている場合）。

編集：Githubマークダウンがこれを完全に台無しにしていないふりをします。

@campoy src/ディレクトリに関して、GOPATHが設定されているが、srcディレクトリが存在しない場合のgo getの現在の動作は何ですか？ それも作成しない正当な理由はありますか？

$ HOME / go / srcが最初のgoget（またはその環境変数が設定されている場合は$ GOPATH / src）で作成されるかどうかを説明する方が簡単なようです。

現在、GOPATHを設定すると、必要に応じて無条件に必要なディレクトリが作成されます。

CLhttps ： //golang.org/cl/33356はこの問題について言及しています。

CLhttps ： //golang.org/cl/33730はこの問題について言及しています。