bazel-gazelle: Cannot compile //:gazelle when using version 0.25.0

Edit: After some more messing around, I found that placing this in my WORKSPACE was sufficient to fix the problem

# gazelle:repository go_repository name=org_golang_x_xerrors importpath=golang.org/x/xerrors

This seems to be related to the new static dependency resolution mode (9c47513). I had success applying this patch to Gazelle:

diff -urN a/deps.bzl b/deps.bzl
--- a/deps.bzl
+++ b/deps.bzl
@@ -317,6 +317,7 @@ def gazelle_dependencies(
     _maybe(
         go_repository,
         name = "org_golang_x_mod",
+        build_external = "external",
         importpath = "golang.org/x/mod",
         sum = "h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o=",
         version = "v0.6.0-dev.0.20220106191415-9b9b3d81d5e3",

Without the patch (i.e. using static dependency resolution mode), the generated @org_golang_x_mod//module:module target is missing the @org_golang_x_xerrors//:go_default_library dependency which causes the “missing strict dependencies” error.

Using rules_go v0.34.0 and gazelle v0.26.0, I get these errors when my go_repository() calls are in a macro, but not when the same calls are in the WORKSPACE. Should I file a new issue about this?

To expand on @nickgooding’s comment, if you use gazelle from within bazel, then putting the following in the WORKSPACE file worked for me:

############################################################
# Define your own dependencies here using go_repository.
# Else, dependencies declared by rules_go/gazelle will be used.
# The first declaration of an external repository "wins".
############################################################

go_repository(
    name = "org_golang_x_mod",
    importpath = "golang.org/x/mod",
    sum = "h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o=",
    version = "v0.6.0-dev.0.20220106191415-9b9b3d81d5e3",
    build_external = "external",
)

go_rules_dependencies()

            compilepkg: missing strict dependencies:
                /private/var/tmp/_bazel_sngoc/7dc6b2f9a9dfc0f9597820642aefdeec/sandbox/darwin-sandbox/287/execroot/__main__/external/co_honnef_go_tools/analysis/facts/tokenfile/token.go: import of "golang.org/x/tools/go/analysis"
                
            compilepkg: missing strict dependencies:
                /private/var/tmp/_bazel_sngoc/7dc6b2f9a9dfc0f9597820642aefdeec/sandbox/darwin-sandbox/352/execroot/__main__/external/co_honnef_go_tools/config/config.go: import of "github.com/BurntSushi/toml"
            No dependencies were provided.

            compilepkg: missing strict dependencies:
                /private/var/tmp/_bazel_sngoc/7dc6b2f9a9dfc0f9597820642aefdeec/sandbox/darwin-sandbox/362/execroot/__main__/external/co_honnef_go_tools/go/ast/astutil/util.go: import of "golang.org/x/exp/typeparams"
            No dependencies were provided.

I still get some issues with dependency resolve of org_golang_x_tools.

Adding this to WORKSPACE file manually tell gazelle how to resolve the dependency which works as a lightweighted workaround in some cases.

# gazelle:repository go_repository name=org_golang_x_tools importpath=golang.org/x/tools
# gazelle:repository go_repository name=com_github_burntsushi_toml importpath=github.com/BurntSushi/toml
# gazelle:repository go_repository name=org_golang_x_exp_typeparams importpath=golang.org/x/exp/typeparams

These deps are being loaded into WORKSPACE from a macro in a separate file, so I wonder if that affected the static resolution somehow?

The latest version of rules_go and bazel-gazelle works out of the box

~For what it’s worth, this issue is not reproducible with the latest rules_go v0.33.0 release. Judging just from the release notes, this is likely due to the updated org_golang_x_xerrors, just like @lukedirtwalker had proposed above as a workaround.~

Nope, sorry. The problem persists – I thought I was doing the same thing as described in the issue, but wasn’t. When that worked, I jumped to the most ready explanation, but this was not correct. Sorry!

I tested it in my repo yesterday and I was able to build everything without build_external, so I think you are right that new rules_go version might have fixed this. https://github.com/sluongng/nogo-analyzer/commit/21610b27d2d0219610e43b0d8bbaa263786f438d

However, i think that org_golang_x_xerrors and org_golang_x_mod are very common dependencies in all projects and thus can be easily overriden inside several WORKSPACE macro calls. User can troubleshoot this by doing this query.

bazel query 'set(//external:org_golang_x_mod //external:org_golang_x_xerrors)' --output=build | grep -v '#'

go_repository(
  name = "org_golang_x_mod",
  importpath = "golang.org/x/mod",
  version = "v0.6.0-dev.0.20220106191415-9b9b3d81d5e3",
  sum = "h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o=",
  build_external = "external",
)

go_repository(
  name = "org_golang_x_xerrors",
  generator_name = "org_golang_x_xerrors",
  generator_function = "ugazelle_deps",
  importpath = "golang.org/x/xerrors",
  version = "v0.0.0-20200804184101-5ec99f83aff1",
  sum = "h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=",
  build_external = "external",
)

Thank you @nickgooding

Your solution works. I just took this diff and applied it with patch_args = ["-p1"],. Now my project works!

Actually for us it also doesn’t really work. The workaround only partially helped but then with clean cache builds fail.

Seems manually adding the xerrors dependency helps:

go_repository(
    name = "org_golang_x_xerrors",
    importpath = "golang.org/x/xerrors",
    sum = "h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=",
    version = "v0.0.0-20200804184101-5ec99f83aff1",
)

This seems to be explicitly overriding the version that would otherwise come from rules_go.