学習者として、同じ学習者に向けた注意喚起として書く。
golang/dep は使わないこと
golang package dependencies と検索すると、 golang/dep というツールのレポジトリがヒットすると思う。筆者の環境で、執筆日の時点ではトップに表示された。
golang/dep (https://github.com/golang/dep)
見てのとおり golang のレポジトリなのでいかにも公式感がある。またレポジトリにあるアナウンスでも、
as of Go 1.11, the Go project has officially adopted a different approach, based on the concept of Modules 1
（拙訳） Go 1.11 より Go プロジェクトは、モジュールのコンセプトに基づいた異なるアプローチを正式に採用しました
とある。 deprecated と明言しないのは玉虫色に聞こえてかえってよくない。事実、 golang が推奨するものが他にあるのであれば、 dep は非推奨であると受け取るべきだ。
繰り返すが、 golang/dep を今から使うのはやめておいた方がいい。
Go Modules でモジュールの依存関係を管理する
Go Modules とは、 go mod コマンドと、二つの静的ファイル go.mod と go.sum によりモジュールのバージョンと依存関係を管理する仕組みである。
go mod コマンドについては公式ドキュメント2を読んでもらう方が網羅的であるためそちらに譲るとして、後者のファイルについて簡単に説明する。
go.mod: 依存モジュールを記述する
go.mod は依存するモジュールの名前とバージョンを記述したファイルであり、 JavaScript でいうところの package.json や Ruby でいうところの Gemfile に相当するものと考えて差し支えない。
ただし Go Modules の仕組みの下では、 Go 言語で記述されたスクリプトをコンパイルする際に、記述されるべき依存はソースファイルの import 文から抽出され、自動で go.mod に追記される。つまりわざわざ go get と叩かなくても、ソースに import 文を記述して go build すればいいわけである。
逆に、当該のスクリプトから import 文を削除しても、 go.mod が自動的に依存の記述を削除してくれることはない。その時は go mod tidy コマンドでソースコードから依存関係を抽出して go.mod を更新するように明示的に指示することができる。
go.sum: 依存モジュールの正統性を担保する
go.sum は依存する各モジュールと、そのソースの暗号学的ハッシュの対応関係が書かれている。これは意図したモジュールのソースコードが改竄されていないかを簡潔にチェックする機構となる。再びアナロジーを用いると yarn.lock なり Gemfile.lock に相当するファイルとなる。
こちらも go.mod と同様に自動生成されるファイルであり、日々の仕事で特に強く意識する必要はない。ただしバージョン管理システムには必ずチェックインすべきファイルである。3