rules_go: Can't build a project that depends on gocloud.dev v0.24.0 and some other packages

Looks like https://github.com/googleapis/google-cloud-go/pull/6266 fixed the issue for google storage, verified that the issue is present before this PR and vanishes after this PR.

This fix is not released yet, but 1.24 release is being prepared from what I see: https://github.com/googleapis/google-cloud-go/pull/6336. You can try the pre 1.24 release to see whether it works:

go get -u cloud.google.com/go/storage@0da97cafde217f8e578319e9d8c2a2b427bfe708

We had the same issue at one point. The issue is basically version drift between the go_googleapis workspace, and the google.golang.org/genproto/googleapis module. When a target uses both as a dependency, for the protobufs Gazelle prefers to resolve to go_googleapis, but that may or may not contain code that would be in google.golang.org/genproto/googleapis.

When something like this comes up, Gazelle can be taught to always resolve to go_googleapis with something like

go_repository(
    name = "org_golang_google_genproto",
    # These build directives are required so that we avoid pulling in @org_golang_google_genproto
    # types that have "weird" build files that are incompatible with rules_go's way of building
    # Go packages. They get pulled in because the override in rules_go for those packages (they
    # have special handling there) isn't up-to-date with the current version of these required
    # by google's storage package. Since there's no change in the _content_ of these types, but
    # just in the version metadata, we can get away with simply replacing them.
    build_directives = [
        "gazelle:resolve go google.golang.org/genproto/googleapis/api/annotations @go_googleapis//google/api:annotations_go_proto",  # keep
    ],
    importpath = "google.golang.org/genproto",
    sum = "h1:ucpgjuzWqWrj0NEwjUpsGTf2IGxyLtmuSk0oGgifjec=",
    version = "v0.0.0-20220919141832-68c03719ef51",
)

I ran into this problem again recently, using the latest version of Gazelle, rules_go, etc, and the only solution that worked for me was to downgrade com_google_cloud_go_storage to v1.15.0.

As that version is getting increasingly old, I imagine it will eventually cause compatibility problems, are there any other workarounds that have worked for folks?

Does anyone else find this error message could be more explicit about the suggested corrections and diagnostic commands?

ERROR: /.../pkg/demo/BUILD.bazel:14:10: GoLink pkg/demo/demo_/demo failed: (Exit 1): builder failed: error executing command bazel-out/host/bin/external/go_sdk/builder '-param=bazel-out/darwin-fastbuild/bin/pkg/demo/demo_/demo-0.params' -- -extld external/local_config_cc/cc_wrapper.sh '-buildid=redacted' -extldflags ... (remaining 1 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
link: package conflict error: google.golang.org/genproto/googleapis/api/annotations: multiple copies of package passed to linker:
	@org_golang_google_genproto//googleapis/api/annotations:annotations
	@go_googleapis//google/api:annotations_go_proto
Set "importmap" to different paths or use 'bazel cquery' to ensure only one

1. I wonder if it could be populated with code that could be copy pasted into the WORKSPACE file with the suggested importmap modifications
2. What bazel cquery command is being suggested? I hardly ever use bazel cquery, and this sends me on a quest for the proper incantation.

Ran into this issue too and downgrading google storage to v1.15.0 really does the magic… ❤️