-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: implement lazy module loading in workspace mode to avoid ambiguous import
errors
#60126
Comments
That isn't a “hacky workaround”. It's how you fix an ambiguous import.
That sounds like a bug that was supposed to have been fixed in https://go.dev/cl/344572. |
Here is the path leading to the dependency that causes the ambiguous import:
So the root of the bug here seems to be that lazy module loading does not take effect in workspace mode, and the interaction between lazy module loading, workspace mode, and (CC @matloob) |
I'll see what I can do about supporting lazy module loading in workspace mode, but in the interim there is a workaround. When we load the module graph for a workspace, we also apply the So you can run ~/src/go.opentelemetry.io/contrib$ git diff
diff --git i/instrumentation/github.com/astaxie/beego/otelbeego/example/go.mod w/instrumentation/github.com/astaxie/beego/otelbeego/example/go.mod
index bb0b98e2..b13cdfa2 100644
--- i/instrumentation/github.com/astaxie/beego/otelbeego/example/go.mod
+++ w/instrumentation/github.com/astaxie/beego/otelbeego/example/go.mod
@@ -40,3 +40,5 @@ require (
google.golang.org/protobuf v1.30.0 // indirect
gopkg.in/yaml.v2 v2.4.0 // indirect
)
+
+exclude github.com/ugorji/go v0.0.0-20171122102828-84cb69a8af83
diff --git i/instrumentation/github.com/astaxie/beego/otelbeego/go.mod w/instrumentation/github.com/astaxie/beego/otelbeego/go.mod
index b53b2900..a88c751a 100644
--- i/instrumentation/github.com/astaxie/beego/otelbeego/go.mod
+++ w/instrumentation/github.com/astaxie/beego/otelbeego/go.mod
@@ -38,3 +38,5 @@ require (
gopkg.in/yaml.v2 v2.4.0 // indirect
gopkg.in/yaml.v3 v3.0.1 // indirect
)
+
+exclude github.com/ugorji/go v0.0.0-20171122102828-84cb69a8af83
diff --git i/instrumentation/github.com/astaxie/beego/otelbeego/test/go.mod w/instrumentation/github.com/astaxie/beego/otelbeego/test/go.mod
index 5204c090..46adf681 100644
--- i/instrumentation/github.com/astaxie/beego/otelbeego/test/go.mod
+++ w/instrumentation/github.com/astaxie/beego/otelbeego/test/go.mod
@@ -45,3 +45,5 @@ replace (
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp => ../../../../../net/http/otelhttp
go.opentelemetry.io/contrib/propagators/b3 => ../../../../../../propagators/b3
)
+
+exclude github.com/ugorji/go v0.0.0-20171122102828-84cb69a8af83
~/src/go.opentelemetry.io/contrib$ go test -c -o /dev/null go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin/...
? go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin/example [no test files] |
ambiguous import
errors
@bcmills Thanks a lot for quick feedback, great explanation and even workaround ❤️ |
See golang/go#60126 The issue is that `containerd/containerd` is an indirect dependency via a circular import from `containerd/containerd/v2` via `microsoft/hccsim`, but in fact it's not used/built into Talos. So explicitly exclude it, so that `go.work` flows work once again. Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
See golang/go#60126 The issue is that `containerd/containerd` is an indirect dependency via a circular import from `containerd/containerd/v2` via `microsoft/hccsim`, but in fact it's not used/built into Talos. So explicitly exclude it, so that `go.work` flows work once again. Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
What version of Go are you using (
go version
)?Also tested on the latest:
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I added
go.work
and it looks like it caused thego build
tooling to differently handle dependency versions. Reference: open-telemetry/opentelemetry-go-contrib#3805You can checkout this repository https://github.com/pellared/opentelemetry-go-contrib/tree/5a8a020149031cf531deada3c13e83d79c39ed3a and run:
go test ./instrumentation/github.com/gin-gonic/gin/otelgin/...
to reproduce the bug.What did you expect to see?
Build and tests are passing.
Using
go.work
does not affect the buildWhat did you see instead?
I tried even to clear Go modules cache hoping that it will fix the issue. However, for some reason it keeps downloading
github.com/ugorji/go v0.0.0-20171122102828-84cb69a8af83
even thoughgithub.com/ugorji/go/codec v1.2.9
is ingo.mod
:I found a hacky workaround:
However,
go mod tidy
correctly clears thegithub.com/ugorji/go v1.2.9 // indirect
entry fromgo.mod
and the issue is back again:I find this issue frightening. I am not sure if I can confidently use Go workspaces in monorepos.
The text was updated successfully, but these errors were encountered: