Go 1.12に移行する(主にgo mod)

手順

1. 公式Wikiのページを見て予習する
2. go mod tidy で既存プロジェクトから go.mod を作る
3. go build でがんばる

• パッケージの依存関係に不足があれば足す
• 別名にしないとビルドできないものは replaceでがんばる
• テストがあるなら通るまで直す

4. おしまい

がんばらないといけないところ

depを最初に入れた時に通る道だと思うんですが、半端にバージョンタグがついてるプロジェクトでとても古いコードを参照した結果、masterブランチのコードを参照し直すことになるかと思います。
その場合は、プロジェクトページで動きそうなコミットハッシュを取ってきてこんな風に go get します:

go get ${パッケージ名}@${コミットハッシュ}

replace でがんばらないといけないところは、今まではgopkg.inで別名がついているようなものが、GitHubのパッケージ名に戻っていたりでめんどくさかったです。
いったん、 go get で取得して require に書かれたのを replace の方に動かさないといけません。
そして、 require と replace 両方に書いてあると怒られるので、さらにめんどくさいです。

テストに関しては、まあ、エラーがわかるだけありがたいと思うので、過去に感謝しつつ直しましょう。
大体は、 replace がうまく行っていないかバージョンがおかしい程度で済みます。

いいとこ

• $GOPATH からおさらば。無駄に長いパスが不要になって好きなところに諸々が置ける
• 追加のツールが不要になる

よくなかったこと

• CIのキャッシュが巨大になった（そこそこテストコードが大掛かりなおかげで1.7GB）
  • ビルド時間が30秒くらい増えたりで、それほど嬉しくない
  • キャッシュありのほうが早いけど、数百MB超えるのは何か間違ってないか考えてしまいます
  • 今回試したのが $GOPATH/pkg/mod だったので、 vendor の方を試す方がいいのかもしれません
• セマンティックバージョニングは（少なくとも人類には）無理
  • 人類には無理と言っているだけで、Elmはいいぞって言いたいだけです
  • 現実問題として、古いタグが残り続けてるプロジェクトを参照した時のしんどさがめんどくさいです
• dep からの移行するとイマイチ
  • 移行がめんどくさい
  • 結局、最初に dep 入れたときと同じ作業してる
  • ユーザーが定義すべきファイルをガンガン変更かけれるのでエディタの設定次第でつらい
  • 謎の構文ファイルを書かないといけない

雑感

モジュールシステムまで導入する必要はなくて、 $GOPATH まわりがよくなるだけでよかったのかなーと個人的に思いました。
今後、よくなってくのかもしれないんですが、本格的なモジュールシステムは2でよかったのではと感じます。

文句ばっかり言ってますけど、 $GOPATH が楽になればなんでもよかったので、満足は満足です。
パッケージ管理システムはなんやかんや気になるので、細かいところでうじうじ言ってしまいますが、全体的に急な変更の割にそこそこ円滑で逆に驚いています。