はじめに
Go1.12からModulesが標準でサポートされ、
いよいよ言語標準機能で依存関係管理とバージョニングが可能となりました。
これにより、
- GOPATH配下にソースレポジトリがなくても良くなった
- vendoringしなくても良くなった
という利点が生まれます。
というわけで、depで依存管理していたレポジトリを、Modulesによる依存管理に移行してみました。
手順
今回は、github.com/n-someya/lambda-gittrendというレポジトリを脱depさせ、Modules対応させてみました。
lambda-gittrendの直下には、Gopkg.lockがある状態です
1. GOPATHからの脱出
まずは、$GOPATH以外のパスにレポジトリを移動します。
cd $GOPATH
cp -r src/github.com/n-someya/lambda-gittrend ~/lambda-gittrend
2. Modulesへの移行
cd ~/lambda-gittrend
go mod init
以下のような出力がされて、コマンドが完了します。
go: creating new go.mod: module github.com/n-someya/lambda-gittrend
go: copying requirements from Gopkg.lock
え、これだけ？と思いましたが、dep対応のレポジトリならGopkg.lockを読みこんで勝手に移行してくれます。
コマンドが完了すると、go.modというファイルができています。
ちなみに、1からレポジトリ作る時は、
go mod initの後にレポジトリパスを書きます。 go mod init github.com/n-someya/fooみたいな感じです。
3. dep関連ファイルとディレクトリの削除
今までありがとう、、、
rm Gopkg.lock Gopkg.toml
rm -r vendor
これだけで go build 出来るようになりました。
Gitのレポジトリから、大量のvendorディレクトリも消えて満足です！
Modulesのコマンド達
移行終了時にはビルド出来る状態になっていると思いますが、
実際のリリース時には以下のようなコマンドで、レポジトリの状態をチェックするのが良いみたいです。
依存関係の整理
依存モジュールを整理し、不必要なものはpruneされます。
また、全てのビルドタグ、OSの組み合わせでビルド可能か？などが精査されます。
go mod tidy
依存パッケージを含んだ全てのテスト
タイトルの通りです。
依存パッケージ含めて、全てのテストをします。
go test all
※私のレポジトリでは残念なことに通らず。。。aws lambdaのSDKとかテストこけてるんだがどういうこと
依存パッケージのVerify
ダウンロードされている依存パッケージが、本当に正しいかを検証します。
go mod verify
終わりに
思ったより簡単でした。
なお、ビルド環境とかで、どうしてもGOPATH配下でModulesを使わなければいけない場合は
GO111MODULE環境変数をonに設定しておくとModulesが使えるはずです。