runtime/debug: BuildInfo lacks information about “the main module”

[bcmills]

What version of Go are you using (go version)?

~/go/src$ go version
go version devel +d56a86e01f Thu Aug 29 12:51:31 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

~/go/src$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/bcmills/.cache/go-build"
GOENV="/usr/local/google/home/bcmills/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/google/home/bcmills"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/google/home/bcmills/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64"
GCCGO="/usr/local/google/home/bcmills/bin/gccgo"
AR="ar"
CC="gcc"
CXX="c++"
CGO_ENABLED="1"
GOMOD="/usr/local/google/home/bcmills/go/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build430797677=/tmp/go-build -gno-record-gcc-switches"

What did you do?

From within module y, build a binary from module x than examines the Main field of runtime/debug.BuildInfo:
https://go-review.googlesource.com/c/go/+/192558/1/src/cmd/go/testdata/script/mod_modinfo.txt

What did you expect to see?

Since the field's documentation says it is (emphasis mine) “The main module information”, I expect it to contain information about “the main module” in the sense of https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list.

For this example, I expected the information reported by the binary to look like

mod y (devel)
dep x v0.0.0-00010101000000-000000000000
dep golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c h1:pvCbr/wm8HzDD3fVywevekufpn6tCGPY3spdHeZJEsw=
dep rsc.io/quote v1.5.2 h1:3fEykkD9k7lYzXqCYrwGAf7iNhbk4yCjHmKBN9td4L0=
dep rsc.io/sampler v1.3.0 h1:HLGR/BgEtI3r0uymSP/nl2uPLsUnNJX8toRyhfpBTII=

What did you see instead?

Instead, the Main field contains information about the module containing package main:

mod x v0.0.0-00010101000000-000000000000
dep golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c h1:pvCbr/wm8HzDD3fVywevekufpn6tCGPY3spdHeZJEsw=
dep rsc.io/quote v1.5.2 h1:3fEykkD9k7lYzXqCYrwGAf7iNhbk4yCjHmKBN9td4L0=
dep rsc.io/sampler v1.3.0 h1:HLGR/BgEtI3r0uymSP/nl2uPLsUnNJX8toRyhfpBTII=

with no information about the main module (y) at all, not even as a dep.

As far as I can tell, it has been that way since module support was first implemented.

---

CC @jayconrod @rsc @thepudds @hyangah

[bcmills]

Given the current behavior of the BuildInfo.Main field, I think we should probably leave its content as-is, and update its documentation to clarify the meaning.

However, we should also add the actual “main module”, probably as a new field in the BuildInfo struct.

[hyangah]

Leaning towards documentation change. "mod" line should be the version info of the module that contained the main package.

I don't know what value mod y (devel) provides users. Especially, if a user builds and installs the binary from an empty or temporary directory (for clean build), there will be no version or remote vcs associated with it and the main module name will be an arbitrary temporary directory name. Maybe whether the workspace was a clean build or not may be useful.

[bcmills]

I don't know what value mod y (devel) provides users.

Mostly it would be a clear indication that the user was not working within any version of the x module when they built the binary. That information would be useful to a developer of x, because it would give them a clue as to how the user got into the final configuration in the first place.

(For example, it might give them someplace to start sending PRs to get their users out of a known-buggy configuration.)

[mholt]

Given the current behavior of the BuildInfo.Main field, I think we should probably leave its content as-is

If possible at this stage of modules, I would like to see the behavior improved/corrected, since there's already enough "gotchas" related to dealing with modules, it would be great to reduce those as much as possible.

[hyangah]

@bcmills The 'y' is arbitrary (temporary module name), and '(devel)' is arbitrary in the example. If we add any other field or repurpose the Main field and they should be meaningful, I think this should include more info than those short string.

[bcmills]

The y in the example is arbitrary, but in general the name of the main module is not: for example, if the binary is a dependency defined through a +build tools source file, the main module may be a long-lived, maintained module and its version may even be significant.

[thepudds]

Leaning towards documentation change.

I think I am not fully following the alternatives, but is it still under consideration to use VCS information to properly populate the version for the "main module” (not the package containing main) in at least some circumstances?

For example, from the currently open #29814:

When a binary is build from within a module's source tree, the output from runtime/debug.ReadBuildInfo currently reports that module as having version (devel).

If the source tree is a pristine checkout from a version-control system — or is within the (read-only) module cache — we could instead interrogate the version-control system to find the corresponding version or pseudo-version to embed.

[bcmills]

is it still under consideration to use VCS information to properly populate the version

Yes, but that is (mostly) orthogonal to this issue.

This issue is: “should we include the main module at all if it doesn't contribute any packages to the build, and if so, where?”

#29814 is, “if the main module appears in BuildInfo, which version should we report for it?”

[rsc]

BuildInfo.Main is the module with the main package, not the main module (where those differ).
The docs should reflect that.