Go Modules - Qiita
普段あまり Go を使わない人が仕事で使ってるソースが突然 Go Modules になって困って調べたメモ。 問題の背景 Go では GOPATH という特殊な概念があって、Go のコードはライブラリも含めてすべて $GOPATH/src 以下に置くという約束になっている。そうするとプロジェクトごとにライブラリのバージョンを変えたい場合に困るので、プロジェクト固有のライブラリは $GOPATH/src/プロジェクト/vendor の下に入れても良いことになっている。そうすると go コマンドは vendor 以下を優先して見てくれる。面白い事に、vendor ディレクトリの管理は govendor 等色々なサードパーティツールを使う。 将来の Go 1.12 からこのやり方を改め、$GOPATH/src や vendor は廃止となり Go Modules という物を採用する事になった。現
最近のGo Modulesプラクティス ~ ghqユーザーの場合も添えて | おそらくはそれさえも平凡な日々
最近Go Modulesを使っていて、だいたいプラクティスが定まってきたのでまとめてみる。 個人的な結論 Go Modulesは積極的に使っていけばいい 幾つか課題はある $GOPATH から出る必要もない $GO111MODULE を適宜設定すればよい どうせ次のGo 1.13からはどこに置こうが関係なくなる 2つのモード $GOPATH/src にプロジェクトを置いていると、今(Go 1.12)の標準動作はGOPATHモードになる。これは、$GOPATH/src 以下からサードパーティパッケージを読み込むこれまでのGoと同様の動作になるということ。 それ以外の場所では go mod コマンドを使ってGo Modulesを利用することができる。これをmodule-awareモードという。go.mod と go.sum を使って依存ライブラリを管理する方式になる。これらのファイルはgo m
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
