Go Wiki: GOPATH

GOPATH変数

標準ライブラリ以外の依存関係を使用するGo開発は、Goモジュールを使用して行われます。Goモジュールを使用する場合、GOPATH変数（デフォルトはUnixでは$HOME/go、Windowsでは%USERPROFILE%\go）は、以下の目的で使用されます。

• go installコマンドは、バイナリを$GOBINにインストールします。これはデフォルトで$GOPATH/binです。
• go getコマンドは、ダウンロードしたモジュールを$GOMODCACHEにキャッシュします。これはデフォルトで$GOPATH/pkg/modです。
• go getコマンドは、ダウンロードしたチェックサムデータベースの状態を$GOPATH/pkg/sumdbにキャッシュします。

GOPATH変数の詳細については、goコマンドドキュメントを参照してください。このページの残りの部分では、現在非推奨となっているGOPATH開発モードについて説明します。

GOPATH開発モード

Goモジュール以前は、依存関係を使用するGo開発は、短く「GOPATHモード」とも呼ばれる「GOPATH開発モード」を使用していました。GOPATHモードでは、goコマンドはGOPATH変数を次の目的で使用しました。

• go installコマンドは、バイナリを$GOBINにインストールしました。これはデフォルトで$GOPATH/binです。
• go installコマンドは、import "example.com/y/z"のコンパイル済みパッケージファイルを$GOPATH/pkg/example.com/y/z.aにインストールしました。
• go getコマンドは、import "example.com/y/z"を満たすソースコードを$GOPATH/src/example.com/y/zにダウンロードしました。

GOPATH開発モードの非推奨化と削除

Goモジュールは、Goエコシステム全体にパッケージバージョンの概念を追加するためのGOPATH開発モードの代替です。

GOPATH開発モードからGoモジュールへの移行は、多くのGoリリースにまたがり、段階的に行われてきました。

• Go 1.11 (2018年8月) では、GO111MODULE変数が導入され、デフォルトはautoでした。GO111MODULE=offの場合、goコマンドは常にGOPATHモードを使用しました。GO111MODULE=onの場合、goコマンドは常にモジュールモードを使用しました。GO111MODULE=auto（またはGO111MODULEを設定しないまま）の場合、goコマンドは現在のディレクトリに基づいてモードを決定しました。現在のディレクトリが$GOPATH/srcの外であり、ルートにgo.modファイルがあるソースツリー内にある場合、goコマンドはGoモジュールモードを使用しました。それ以外の場合、goコマンドはGOPATHモードを使用しました。このルールにより、$GOPATH/srcで実行されるすべてのコマンドがautoモードで影響を受けないようにし、ユーザーが他のディレクトリでモジュールを試せるようにしました。

• Go 1.13 (2019年8月) では、GO111MODULE=autoモードが調整され、$GOPATH/srcの制限が解除されました。$GOPATH/src内のディレクトリにgo.modファイルがある場合、そのディレクトリまたはその下のディレクトリで実行されるコマンドはモジュールモードを使用するようになりました。これにより、ユーザーはインポートベースの階層でチェックアウトされたコードを整理し続けることができますが、個々のチェックアウトにはモジュールを使用できます。

• Go 1.16 (2021年2月) では、デフォルトがGO111MODULE=onに変更され、常にモジュールモードが使用されます。つまり、GOPATHモードはデフォルトで完全に無効になります。もう1つのリリースでGOPATHモードを使用する必要があるユーザーは、GO111MODULE=autoまたはGO111MODULE=offを明示的に設定できます。

• Go 1.NN (???) では、GO111MODULE設定とGOPATHモードが完全に削除され、常にモジュールモードが使用されます。

GOPATH開発モードの削除は、GOPATH変数の削除を意味するわけではないことに注意してください。これは、このページの上部に記載されている目的のために引き続き使用されます。

FAQ

GOPATH変数は削除されるのですか？

いいえ。GOPATH変数（環境内またはgo env -wで設定）は削除されません。このページの上部に記載されているように、デフォルトのバイナリインストール場所、モジュールキャッシュ場所、およびチェックサムデータベースキャッシュ場所を決定するために引き続き使用されます。

GOPATH/src/import/pathでコードを記述できますか？

はい。多くのGo開発者は、この規約が提供する構造を高く評価しており、モジュールリポジトリをチェックアウトしています。モジュールを開始するために必要なコードは、go.modファイルだけです。go mod initを参照してください。

別のリポジトリで行われた変更に対して、GOPATH/srcの1つのリポジトリをコンパイルするにはどうすればよいですか？

別のモジュールをビルドするときに、公開されていないあるモジュールの変更を使用する場合は、他のモジュールのgo.modにreplace行を追加できます。

たとえば、golang.org/x/websiteとgolang.org/x/toolsを$GOPATH/src/golang.org/x/websiteと$GOPATH/src/golang.org/x/toolsにチェックアウトした場合、websiteのローカルビルドでtoolsの変更を自動的に使用するようにするには、$GOPATH/src/golang.org/x/website/go.modにこれを追加します。

replace golang.org/x/tools => ../tools

もちろん、replaceディレクティブは$GOPATHについて何も知りません。同じ行は、2つを$HOME/mycode/websiteと$HOME/mycode/toolsにチェックアウトした場合でも正常に機能します。

なぜGOPATH開発モードは削除されるのですか？

その核心において、GOPATH開発モードは基本的に、これらの種類のreplace行をすべて自動的に提供するため、依存関係のためにビルドするコードは、コンピュータにチェックアウトしたコードです。つまり、ビルドは、忘れてしまった可能性のある古いチェックアウトの影響を受けます。つまり、同じトップレベルリポジトリの同じバージョンから開始した場合でも、あるマシンで取得するビルドは別のマシンとは異なる可能性があります。そして、取得するビルドは、同じプロジェクトの別の開発者が取得するビルドとは異なる可能性があります。Goモジュールは、これらの再現性の問題をすべて解決します。これらの問題の根本的な原因は、GOPATHモードにはパッケージのバージョンの概念がないことです。

再現性に加えて、Goモジュールはプロキシと安全なダウンロードを処理するための明確な方法を提供します。プロジェクトをgit cloneして依存関係を取得すると、それらの依存関係は、元の開発者が使用したのと同じビットであることを確認するために（go.sumファイルを使用して）暗号的にチェックされます。信頼できる部分は、トップレベルのgit cloneだけです。ここでも、これはGoモジュールがGOPATHモードとは対照的に、パッケージバージョンの概念を持っている場合にのみ可能です。

そして、Go自体の将来の進化のために、モジュールは、特定のファイルツリーが記述されているGo言語のバージョンを明確にマークします。これにより、問題のある機能（たとえば、多くの人が"1"を生成すると考えているが、実際には"\x01"（Ctrl-A）を生成するstring(1)など）を、古いプログラムのビルドを維持しながら（古いバージョンのGo用に書かれたとして明示的にマークされているため）Goの後のバージョンで無効にすることができます。

このような例は他にもあります。

これらはすべて、今日のGOPATH開発モードでは不可能です。エコシステムを前進させ、GOPATHモードを廃止することなく、Goモジュールのこれらの重要な特性に本当に依存し始めることはできません。

（次のような質問もあるかもしれません。なぜこれらのことをGOPATHモードに追加しないのですか？答えは、実行した結果がGoモジュールであるということです。）

GOPATH開発モードを非推奨にすることが決定されたのはいつですか？

当初の計画では、Go 1.13でGOPATHモードを非推奨にすることでしたが、できるだけ多くのGoユーザーにとってモジュールをさらに堅牢にするために時間をかける必要があったため、非推奨はそのリリースから延期されました。issue #41330とgolang-toolsグループでの議論では、GOPATHを非推奨にするための残りのブロッカーは特定されなかったため、上記のタイムラインに記載されているように、Go 1.16でスケジュールされ、将来のリリースで削除される予定です。

GOPATH開発モードからGoモジュールへの移行についてさらに質問がある場合はどうすればよいですか？

リソースのリストについては、golang.org/helpを参照してください。それらが適切でない場合は、ここに問題を提出してください。私たちは皆がGoモジュールを採用することに成功することを望んでいます。

このコンテンツは、Go Wikiの一部です。