Why should we manage versions of tools? ⬇ Behaviors of tools may change when developers install them via `go get` (e.g. an output file format of code generator)
Mock implementation that I wanna create Mocks that updated unexpectedly Because I use [email protected] but they are generated by [email protected] If you do not manage tool dependencies ...
How about existing package managers? (e.g. dep ,go mod) `go build` is the out of scope of their responsibility dep document says* if you need the tool to be installed you still run the following (manually or from a `Makefile`) after each `dep ensure` ``` cd vendor/pkg/to/install go install . ``` * https://golang.github.io/dep/docs/Gopkg.toml.html#required
cmd/go: clarify best practice for tool dependencies #25922 · golang/go Other 3rd-party tools (e.g. virtualgo, retool, ...) need to introduce new management mechanisms "tools.go" method can use existing dependency management mechanisms (e.g. dep, go mod)
cmd/go: clarify best practice for tool dependencies #25922 · golang/go // tools.go // +build tools package tools import ( _ "golang.org/x/tools/cmd/stringer" ) // go.mod module example.com/hello require golang.org/x/tools v0.0.0-20180813205110-a434f64ace81 // indirect go get export GOBIN=$(pwd)/bin go install golang.org/x/tools/cmd/stringer We want to also automate this step!
gex: manage tools with `tools.go` github.com/izumin5210/gex Does not introduce new mechanism to manage tool deps. - `gex` is very thin wrapper command of `dep` or `go mod` - For example, if `go mod` was to support to manage tools officially, we would be able to move from `gex` easily Only 2 commands that you use: `--add` and `--build` (I believe) tools management mechanism will be introduced into `golang/go` officially - When the time coms, we graduate from`gex`