-
Notifications
You must be signed in to change notification settings - Fork 10
add experimental support for go.tools #44
Description
golang/go#25922 gives guidance on the best practice for adding tool dependencies to a module. In short, the tool dependencies get added to the main module via "fake" imports of the main package that is the tool in a build-ignore file, say tools.go.
There are a number of benefits and issues with this approach; see golang/go#25922 for further discussion on that.
As a trial, let's make gobin understand a go.tools file in the same directory as the main module and take tool versions from that. The format would be very simple:
// go.tools
github.com/rogpeppe/[email protected]
myitcv.io/cmd/[email protected]
golang.org/x/tools/cmd/goimports
golang.org/x/tools/cmd/goimports is special be because the version of golang.org/x/tools/cmd/goimports we want does not resolve to a module. This same restriction applies for any tools that resolve to modules that are incomplete, i.e. go.{mod,sum} are not the result of go mod tidy. The lack of version indicates that for the tool in question we drop down to the main module's go.{mod,sum} to resolve dependencies, i.e. the user also needs to follow the approach outlined in golang/go#25922.
Open questions:
- For a tool that is not part of a module, or where that module is incomplete (
go.{mod,sum}not the result ofgo mod tidy), use ofgo.toolsis a strictly worse experience than the approach in cmd/go: clarify best practice for tool dependencies golang/go#25922. Should we be doing anything more here?- The "no version" drop down to the main module seems to work
- Using
go.tools, we lose the ability to use ourgo.sumas a means of verifying any dependencies, tools or otherwise. Instead we end up relying on thego.sum(if there is one) that is distributed with the tool. Perhaps we should capture thesego.sum's somewhere too?- Maintain a
go.tools.sumfile that is the concatenation of thego.sum's of the unique set of$module@$versionfrom the set of tools - If the
gotools starts to understandgo.tools, then this would be unnecessary - We will need
gobin -tidyetc.
- Maintain a