cmd/go: "run" and "tool" do not stamp binaries with the main module's version information

[mvdan]

$ go version
go version go1.26-devel_320df537cc 2025-08-13 20:33:56 -0700 linux/amd64

Using https://github.com/cue-lang/cue as an example, where cmd/cue is a main program which reports the main module's version as the first line of its cue version command, the stamping works fine with go install and go build:

$ go install ./cmd/cue && cue version | sed 1q
cue version v0.15.0-0.dev.0.20250815110336-a2eed3278a6c
$ go build -o cue-build ./cmd/cue && ./cue-build version | sed 1q && rm cue-build
cue version v0.15.0-0.dev.0.20250815110336-a2eed3278a6c

With go run it doesn't work by default, which is surprising and a bit inconsistent. We can however enable it explicitly.

$ go run ./cmd/cue version | sed 1q
cue version (devel)
$ go run -buildvcs=true ./cmd/cue version | sed 1q
cue version v0.15.0-0.dev.0.20250815110336-a2eed3278a6c

With go tool it also doesn't work by default, and on top of that, we can't enable it in any way:

$ go tool cue version | sed 1q
cue version (devel)
$ go tool -buidlvcs=true cue version | sed 1q
flag provided but not defined: -buidlvcs

What's weird is that the "auto" mode (the default) seems to be broken with go run:

$ go run -buildvcs=auto ./cmd/cue version | sed 1q
cue version (devel)

The docs say:

By default ("auto"), version control information is stamped into a binary if the main package, the main module containing it, and the current directory are all in the same repository.

It seems pretty clear to me that I'm meeting those requirements with go run ./cmd/cue, so I don't understand why the auto-stamping is not working.

So it seems to me like go run and go tool should apply the -buildvcs=auto default such that version stamping takes place.

It may also be a good idea for go tool to expose the -buildvcs build flag, so that one can explicitly turn it on or off if needed like with the other commands. But I don't feel strongly about it.

[gabyhelp]

Related Issues

• cmd/go: stamp the pseudo-version in builds generated by `go build` #50603 (closed)
• cmd/go: version stamping from VCS no longer works in Go 1.25 when in a nested module and repo root has no go.mod file #74763
• cmd/go: vcs info not stamped when built listing .go files directly #51279

Related Code Changes

• cmd/go: stamp VCS info when building .go files directly
• [release-branch.go1.18] cmd/go: allow '-buildvcs=auto' and treat it as the default

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

[seankhliao]

This was #52338

[mvdan]

If that is the decision for go run, fair enough, but it should be documented in go help run.

And I feel like go tool needs to be considered separately. The whole point of the command is to run common tools and cache the binaries, so the cost of obtaining the VCS information is amortized. And the command should behave closely to go install or go build within reason.

In fact, go run caches binaries nowadays too, so I'd argue the same argument now applies to both. When #52338 was closed, there was no caching of binaries, so the cost of fetching VCS information was a latency issue with every single invocation.

[seankhliao]

I don't think much should change for go run: the most common case is probably still interactive usage for running quick tests rather than repeatedly invoking the same program.

I do see the argument for build info for go tool, however, isn't it quite misleading for it to be stamped with the main module version, rather than the version of the tool being executed?

[mvdan]

isn't it quite misleading for it to be stamped with the main module version, rather than the version of the tool being executed?

In my examples above, the main (current) module and the module containing the tool command are the same. This is the case where the main module version stamping does not happen, because it's VCS-derived.

$ go version -m $(go tool -n cue) | grep '^\s*mod'
	mod	cuelang.org/go	(devel)	

When running a tool from an external module, i.e. a dependency, then the stamping works fine because no VCS is involved for the main module in the build. The main module is a dependency pulled through GOPROXY.

$ go version -m $(go tool -n stringer) | grep '^\s*mod'
	mod	golang.org/x/tools	v0.35.0	h1:mBffYraMEf7aa0sB+NuKnuCy8qI/9Bughn8dC2Gu5r0=

I don't think much should change for go run: the most common case is probably still interactive usage for running quick tests rather than repeatedly invoking the same program.

I don't agree with that conclusion. If that were true, then go run would not cache binaries like go tool does. Given that they both cache binaries, and hence the extra time spent on -buildvcs is amortized, I would find it bizarre if one stamps main module versions and the other does not.

[cagedmantis]

@golang/command-line