最近の go work

"go work" は比較的最近使えるようになった。
というと使いこなしているように見えてしまうが、実は初めて使う。。。

Tutorial: Getting started with multi-module workspaces
https://go.dev/doc/tutorial/workspaces

"go work" の "work" は workspace の work だろう。

このチュートリアルを最後まで行うと、workspace/ の中はこうなっている。赤枠がチュートリアルで作成した部分、それ以外は git clone で持ってきた部分だ。

 

hello.go で "fmt.Println(reverse.String("Hello"), reverse.Int(24601))

の reverse.Int(24601) はオリジナルの "golang.org/x/example/hello/reverse" にはなく、今回追加した int.go で実装されている。従来、こういう場合は go.mod の require にある "golang.org/x/example/hello/reverse" を replace で相対フォルダ指定して「実はこっち使ってます」宣言するのだが、"go work" のしくみを使うとそれが不要になっているというのがポイントだと思っている。

同じような使い方をするなら、誰かのリポジトリを GitHub fork して自前でちょっと変更したバージョンを使いたいとかだろうか。ただ fork すると別リポジトリとして扱いたいので git submodule で "go work" の中に配置するとかがよいのかな？

あるいは、単純に同じリポジトリの中に go.mod を複数持って相手を参照するような場合でも良いのか。gRPCサーバのアプリを作ったとき、protobuf の定義ファイルも同じリポジトリにおいたのだが、proto定義は変わらないのにサーバの更新だけ進むのでなんだかなー、という気持ちになっていた。
そういう場合にうまいこと使えないだろうかと考えたが、クライアントアプリも同じリポジトリで運用するならよさそうな気がする。気がするが、それは単に replace を書かなくていいのが便利なだけで gRPC の件とは何の関係もないな。

サーバのリポジトリの中に proto があると、クライアントアプリを作りたいだけなのに go.mod にサーバのパッケージを書くのでいらないものまでダウンロードすることになるというのがなんか嫌でね。どうせサーバもクライアントも同じPCで開発するだろうからいいやん、と言われればそれまでなのだが。

 

"workspace" という名前の通り、同じワークスペースにある go.mod はネットワーク参照ではなくローカル参照してくれるのが便利、という考え方で良いのかな。試作している間、repalce でローカルを読むように変更する手間が面倒だったので、workspace 自体は git 管理せずに作業中だけ使うというやり方でよいかもしれん。