数年前に、Golang の勉強も兼ねて簡単な認証・認可 api を作りました。
※テスト用なので色々ツッコミどころはありますがそこは一旦無視してください。

今回は作成した当時のパッケージ管理についてと、今めっちゃ便利になっているねってことを書きます。

以前のパッケージ管理

リポジトリ作成当時、パッケージ管理には dep を使っていたんですが、これが一癖あってなかなか面倒だったんですよね。
当時は Go のバージョンも 1.10 に満たなかったと思いますが、とにかく GOPATH に縛られた開発スタイルが辛かった記憶があります。
上記 dep も「実行場所が GOPATH 以下である必要がある」というのがネックで、開発リポジトリの置き場所が GOPATH 依存になっていたんですよね。
とはいえ「パッケージ管理ができるようになる」というだけでも、当時かなり嬉しかったんですが。

Go Modules への移行

そして先日、Go Modules の存在を知りました。

Go については最新情報をあまり追えていなかったこともあり、これを機に上記リポジトリへ設定してみました。
と言っても、dep のように個別セットアップ手順も無いため、実際は最新バージョンの Go を使い以下コマンドを実行しただけです。 

$ go mod init

上記コマンドで go.mod / go.sum が生成されます。
前者がアプリケーションが直接依存しているライブラリを定義したもので、後者が各ライブラリの詳細なバージョンを定義する lock ファイルです。

驚きだったのが、dep が作成した Gopkg.lock を元に依存関係を解決してくれたことです。
The Go Blog でも触れられてはいたものの、移行が考慮されているのはありがたいですね。

ライブラリ追加・整理

Go 開発時にはおなじみの go get で、go.mod / go.sum が書き換わります。 

$ go get {module_name}

ソースコードを修正していくうち使わなくなったライブラリがある場合は以下で go.mod / go.sum をキレイにできます。 

$ go mod tidy

すでに定義されたものをダウンロード

Docker や複数人開発などで、すでに定義された go.mod を利用する場合は以下でライブラリをダウンロードできます。 

$ go mod download

まとめ

パッケージ管理がろくに無かった時代から Go を触っていたこともあり、標準でパッケージ管理ができるようになったことは一種の感動に近いものがありました。
単一バイナリ・クロスコンパイルのようなメリットもありますし、知識のアップデートも兼ねて久々に Go で何か作ってみようかなと思います。