可搬性の高いGoのVendoring環境整備その後、dep編

mk.hatenablog.com

direnvでGOPATHを通し、特にまずvendorフォルダを優先することでgo getにていい感じにVendoringするようにしてました。が、しかし、しばらく離れているうちに様子が変わってしまいましたね。

HOGO(https://github.com/gohugoio/hugo)のソース見たときに、リポジトリのルートで未知のGopkg.lockファイルを見つけ、何だろうと調べたのがdep気づきのきっかけです。

github.com

そのほか、Serverless.comでGo言語版のテンプレートを実行しようとしたらdepを使った構成が推奨されていたりと、何度かdep体験が連続しました。depのリリース履歴を見るとファーストリリースは2017年5月で、その後9月のリリースぐらいからじわっと来てたのかなと見て取れます。既にbrewでぶっこめるようにもなってて素敵ですが、brew info depで見ると2018年1月の0.4.1からの登録でした。まさに普及はこれからですね。

dep環境にするには、まずGOPATHを決める。デフォルトに環境変数で決め打ってOKなのですが私は既存環境のこともあるので大好きdirenvで設定。

# ~/go/.envrc
export GOPATH="`pwd`"

前に行ってたようなvendorフォルダとプロジェクトルートを両方通さなければならないということはなく、どっかにGOPATHをまず通す。上記では~/goフォルダに通した。

$ tree -a -L 3 ./go
./go
├── .envrc
├── bin
├── pkg
│   └── dep
│       └── sources
└── src
    ├── aws-hugo
    │   ├── .gitignore
    │   ├── .idea
    │   ├── Gopkg.lock
    │   ├── Gopkg.toml
    │   ├── Makefile
    │   ├── codebuild
    │   ├── codecommit
    │   ├── generate.go
    │   ├── s3
    │   ├── serverless.yml
    │   └── vendor
    └── renames
        ├── Gopkg.lock
        ├── Gopkg.toml
        ├── renames.go
        ├── renames_test.go
        └── vendor

GOPATHフォルダの下に、srcフォルダを作り、その中にプロジェクトを作ります。プロジェクトルートでmainパッケージを置いてその下にパッケージ名で階層掘ってく。

あとは、Makefileの冒頭や手打ちで、dep ensure を実行するとソースコード中に書かれたimportを解決すべくVendoringをdepが頑張る。たまにアップデートするには、dep ensure -updateやdep prune。

問題は、バージョン固定で外部を持ってきたいときがあるならdepでワークフロー組めない。勝手に解決方式のdepではなく自らの意識で持ってくるgo getをdirenvと組み合わせて使うのが変わらずいいと思う。私は全部depに移行でいいや。便利だし。