Open bcmills opened 4 years ago
I will work on it!
@bcmills We came across a similar error message in Kubernetes, though I'm not too sure if it's due to the same reason as mentioned in the issue body.
Running the following command at the root of https://github.com/kubernetes/kubernetes worked in go 1.13 but fails in go 1.14. https://github.com/kubernetes/test-infra/pull/18200 has more details.
The k8s.io/publishing-bot
repo is at https://github.com/kubernetes/publishing-bot.
With go 1.14.4:
$ go run k8s.io/publishing-bot/cmd/validate-rules ./staging/publishing/rules.yaml
package k8s.io/publishing-bot/cmd/validate-rules: cannot find package "." in:
/home/nikhita/go/src/k8s.io/kubernetes/vendor/k8s.io/publishing-bot/cmd/validate-rules
With go 1.13.12:
$ go run k8s.io/publishing-bot/cmd/validate-rules ./staging/publishing/rules.yaml
go: finding k8s.io/publishing-bot latest
I0708 03:03:16.384590 14888 rules.go:89] loading rules file : ./staging/publishing/rules.yaml
I0708 03:03:16.395696 14888 rules.go:125] validating repository order
I0708 03:03:16.395848 14888 main.go:37] validation successful
cc @dims @liggitt
@nikhita Can confirm, that issue is closely related.
go mod vendor
copies into the vendor directory packages needed to build packages in the main module and their tests. Since k8s.io/publishing-bot/cmd/validate-rules
is not imported by any package in the main module, it won't be vendored.
This error is shown when vendor mode is enabled and a package that's not present in the vendor directory is needed. In Go 1.14, vendor mode is enabled when vendor/modules.txt
is in sync with go.mod
and go.mod
has go 1.14
or higher.
As a work around, you can import k8s.io/publishing-bot/cmd/validate-rules
from a "tools" package that is never built, then run go mod vendor
again. It looks like hack/tools/tools.go
and build/tools.go
are already used to track a few tools like this. You can also use the -mod=mod
flag to build without the vendor
directory.
Is this fixed?
$ /opt/homebrew/bin/go version
go version go1.21.1 darwin/arm64
$ /opt/homebrew/bin/go build foo/
package foo is not in std (/opt/homebrew/Cellar/go/1.21.1/libexec/src/foo)
$ /opt/homebrew/bin/go build -mod=vendor foo/
package foo is not in std (/opt/homebrew/Cellar/go/1.21.1/libexec/src/foo)
When
foo
is a relative subdirectory, the error message fromgo build foo/
seems a lot worse when-mod=vendor
is set than when it is unset:The error message from the first
go build foo/
seems reasonable to me: it clearly indicates thatfoo
was interpreted as a package path, where we expected to find that package, and why we failed to do so.The error message from
go build -mod=vendor foo/
is much worse: it mentions apackage "."
, which has nothing to do with what the user passed in, fails to mentionGOROOT
(which is where a package namedfoo
generally ought to be) at all, and buries thevendor
part in the middle of the file path.CC @jayconrod @matloob