proposal: cmd/go: "go tool" propagate `-modfile` via env `GOTOOLMOD`

[dolmen]

Proposal Details

To help building dev tools which are go tool-aware, especially with a separate go.mod dedicated to manage tools dependencies (ex: go tool -modfile=tools.mod), I propose to extend go tool to propagate its -modfile flag value to the child processes via an environment variable:

• When go tool runs with -modfile, expose the flag value as variable GOTOOLMOD (similar to the existing GOMOD) when running (NOT building) the tool
• When go tool runs without -modfile, use the value of GOTOOLMOD environment variable, if available, as the first fallback value for locating the go.mod to use for resolving (and building) tools binaries. If building a tool is necessary, clear GOTOOLMOD from the environment before calling go build. Keep GOTOOLMOD in the environment when executing the tool.

Use cases

go tool called from a tool

A tool called via go tool might want to call another tool, also via go tool.

A tool called via go tool -modfile=tools.mod might want to call another tool, also via go tool, but with the same go.mod file. For that case, the default value for -modfile for go tool would be set from the GOTOOLMOD value. The first tool would just execute go tool and would not have to specially care about -modfile.

Example: a go generate command that calls a tool local to the module which then calls an external tool.

A tool that manages tools

A tool that manages tools need to be aware that it is called via go tool (see #78673) but also which go.mod to use/tweak. While it could have its own -modfile flag, it would be simpler to make it aware implicitly of the go.mod via an environment variable GOTOOLMOD.

Related proposals

• complementary to proposal: cmd/go: tell tools they are being run via go tool #78673: a wider proposal about exposing some environment variable(s) that allow a tool to be aware of being launched via go tool

[gabyhelp]

Related Issues

• proposal: cmd/go: tell tools they are being run via `go tool` #78673
• cmd/go: track tool dependencies in go.mod #48429 (closed)
• proposal: cmd/go: support `-modfile` for `go mod init` #78503
• proposal: cmd/go: add GOCMD environment variable #28043 (closed)
• proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive #69956 (closed)
• x/tools/go/packages: Config.Env doesn't support -modfile #48482
• cmd/go: 'go list' should set the 'GoMod' field to reflect -modfile #36220 (closed)
• proposal: cmd/go: mark tool dependencies in go.mod #71749
• proposal: project local tools #67346 (closed)
• proposal: cmd/go: tool command should recognize a package pattern and match against declared tools #74732 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mvdan]

When go tool runs with -modfile, expose the flag value as variable GOTOOLMOD (similar to the existing GOMOD) when running (NOT building) the tool

Emphasis mine - did you perhaps mean the opposite? If the current GOMOD gains a GOTOOLMOD sibling, I would expect GOTOOLMOD to point to the modfile used to build the tool, i.e. the go tool -modfile flag, and GOMOD to point to the main module used otherwise, i.e. when running the tool.

When go tool runs without -modfile, use the value of GOTOOLMOD environment variable, if available, as the first fallback value for locating the go.mod to use for resolving (and building) tools binaries.

If I'm reading your proposal correctly, you wouldn't expect users to set GOTOOLMOD themselves; this feature would purely be for tools that manage other tools in separate modfiles. In such a case, isn't passing -modfile flags just as straightforward as setting or forwarding GOTOOLMOD env vars? I don't really see the need for this part of the proposal.