Proposal Details
Summary
go tool set environment variable(s) that allows a tool to identify being run from go tool.
Proposal
When go tool executes a tool, set the following variables:
As a tool being called by go tool might itself call another tool via go tool, all go tool specific environment variables of a parent tool execution must be overwritten or deleted.
Rationale
Tools can currently run in two modes:
- stand-alone: when installed with
go install <tool>@<version> and executed as normal commands from the shell
- module tool: when declared in go.mod and executed through
go tool <tool>
To improve integration of tools with the Go toolchain, I think that tools should be able to distinguish in which mode they are being executed: when running stand-alone, they should be able to detect if they are working in a Go module which has declared them, and then work just as a shim that delegate to go tool to the specific version selected for the project is executed.
The purpose of this proposal is to help the tool to distinguish if it is being executed via go tool (stand-alone vs module tool as defined above).
For example golang.org/x/tools/cmd/stringer installed with go install should be able to detect that it is executed from a Go module that has golang.org/x/tools/cmd/stringer declared (and so locked to a specific version), and then forward its arguments to go tool golang.org/x/tools/cmd/stringer. But to avoid infinite recursion, stringer should be able to discover if it is already running via go tool.
Update 2026-05-18: fixed Markdown for specification of environment variable values as <bla bla> was hidden
Proposal Details
Summary
go toolset environment variable(s) that allows a tool to identify being run fromgo tool.Proposal
When
go toolexecutes a tool, set the following variables:GOTOOL=<tool import path>GOTOOLMOD=<go.mod used by "go tool -modfile">to allow recursive call togo toolwith another tool from the same go.mod (details in proposal: cmd/go: "go tool" propagate-modfilevia envGOTOOLMOD#79449 )GOTOOLVERSION=<module version of the tool>if not the main module (see also cmd/go: "run" and "tool" do not stamp binaries with the main module's version information #75033 which is aboutruntime/debug.BuildInfofor tools)As a tool being called by
go toolmight itself call another tool viago tool, allgo toolspecific environment variables of a parent tool execution must be overwritten or deleted.Rationale
Tools can currently run in two modes:
go install <tool>@<version>and executed as normal commands from the shellgo tool <tool>To improve integration of tools with the Go toolchain, I think that tools should be able to distinguish in which mode they are being executed: when running stand-alone, they should be able to detect if they are working in a Go module which has declared them, and then work just as a shim that delegate to
go toolto the specific version selected for the project is executed.The purpose of this proposal is to help the tool to distinguish if it is being executed via
go tool(stand-alone vs module tool as defined above).For example
golang.org/x/tools/cmd/stringerinstalled withgo installshould be able to detect that it is executed from a Go module that hasgolang.org/x/tools/cmd/stringerdeclared (and so locked to a specific version), and then forward its arguments togo tool golang.org/x/tools/cmd/stringer. But to avoid infinite recursion,stringershould be able to discover if it is already running viago tool.Update 2026-05-18: fixed Markdown for specification of environment variable values as
<bla bla>was hidden