Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: list command crashes on testdata packages under vendor #24854
If the Go files in a
However, if the
What version of Go are you using (
added a commit
Apr 14, 2018
changed the title from
"go list" command crash on testdata packages under vendor
cmd/go: list command crashes on testdata packages under vendor
Apr 14, 2018
referenced a pull request that will
Apr 15, 2018
As I just asked on the CL, why do we expect
I think predictable and consistent behavior is important here.
As an example consider a package that declares code under testdata that imports something from the package itself. Go list/build would work there just fine, however if package will be used as a vendor dependency we'll start seeing failures. We've seen a lot of cases when various third party packages depend on code from testdata, this would also succeed in case if packages are available in the gopath but would fail if they are located in the vendor folder.
This causes issues when we are trying to build code and list packages filtering files based on build constraints.
It would be a bit unpractical for us to attempt changing all third party packages that impose this pattern so I would prefer landing a fix in the go compiler itself.
Do you have any concerns regarding implementation that we can address?
There is a lot of tests in go_test.go that still relies on code in testdata to work. The go/build package doesn't ignore all testdata package either. In fact, it only ignores testdata package in local imports and vendor directory. In the latter case, testdata is only ignored when it is in the middle of the path. This looks inconsistent, as I don't see the reason why testdata matters only in these two cases. When testdata gets ignored, rather than explicitly returning an error, go/build returns an incomplete package information without any error, leaving its caller to guess how to deal with such incompleteness. In such case, unfortunately, it only errors out two hops down the import graph when the testdata imports a vendor package which in turn imports something else, making the error message sound meaningless.
Like @VitalyArbuzov said, it's unpredictable and inconsistent. That allows most package developers to write and use code in testdata without problems, which only occur in some non-obvious cases.
A lot of the tests run code in testdata directory. After removing
Because "cmd/go/testdata/src/run" resides in GOROOT, without checking it is in testdata, it will be treated as a Go standard library and be disallowed from importing non-standard library run/internal in GOPATH.
So ignoring testdata in GOROOT still makes sense. That's why I kept isTestdata for GOROOT.
I understand that
As mentiond on the CL, perhaps the bug is that go/build is paying too much attention to testdata packages, somehow.
I'm trying to understand if you suggest being more permissive or restrictive in this case.