Closed
Description
What did you do?
https://play.golang.org/p/0ITNcl4kXGN
$ gotip version
go version devel +8c5de667 Fri Aug 30 08:28:40 2019 +0000 linux/amd64
foo$ gotip mod init foo
go: creating new go.mod: module foo
foo$ cat > foo_test.go
package foo_test
import (
"runtime/debug"
"testing"
)
func TestBuildInfo(t *testing.T) {
info, ok := debug.ReadBuildInfo()
if !ok {
t.Fatal("no debug info")
}
t.Log(info.Main.Version)
}
foo$ go test
What did you expect to see?
=== RUN TestBuildInfo
--- PASS: TestBuildInfo (0.00s)
foo_test.go:13: (devel)
PASS
(https://play.golang.org/p/0ITNcl4kXGN)
What did you see instead?
--- FAIL: TestBuildInfo (0.00s)
foo_test.go:11: no debug info
FAIL
CC @jayconrod @rsc; see also #33975.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
breml commentedon Dec 19, 2019
I ended up on this issue while investigating how to access (non Go) files located in a sub-directory of my Go module. The access should happen from tests located in sub-sub-package.
We have it working with a relative path (e.g.
../../../folder/file
) but it would be beneficial to have a less brittle way of accessing these files (especially for the case of refactoring).So I tried the same as @bcmills is describing in this issue and I wanted to access
info.Main.Path
with the end goal of being able to access my files withinfo.Main.Path + "/folder/file"
.Questions:
info.Main.Path
would contain the basepath for the module, if the buildinfo would be available in test builds?breml commentedon Dec 19, 2019
Just as a note, using
go list
does work to get details about Go modules. E.g.:bcmills commentedon Dec 19, 2019
info.Main.Path
in general contains a module path, not a filesystem path.That is the bug described in this issue.
bcmills commentedon Dec 19, 2019
Note that running
go list
in the working directory of a test will tell you about the module that contains the test itself, not the main module in which the test was built.breml commentedon Dec 19, 2019
OK, understood. So this would not have helped me anyway.
I was under the impression, that the buildinfo has been left out intentionally and not that it is a bug. Good to hear, that it is considered a bug.
breml commentedon Dec 19, 2019
That is not clear to me. Is this not the same in the case of tests? My understanding is, that
go test
builds for every package a test binary and executes it. The guarantee is, that the current working directory is actually the directory that contains the test. So therefore, the module that contains the test and the module the test was built for is the same (or is there something special going on in regards to modules when building tests?).This is why
go test -o test ./...
does not work (error message:cannot use -o flag with multiple packages
).bcmills commentedon Dec 19, 2019
Yes.
The module that contains the test is the module containing the working directory, yes.
However, that directory does not indicate the version of that module, and the versions reported by
go list -m all
will not be accurate: those versions are determined by the “main module” (in the sense of https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list), not “the module containing package main”. (See #33975.)breml commentedon Dec 19, 2019
Thanks for your detailed explanation. This comment made it clear to me with the provided example. For my use case this does not matter, because the "main module" and "the module containing package main" are the same.
39 remaining items