Gazelle Label Mismatch When Using go_deps Bzlmod Extension and default rules_go Repo Name

[stefanpenner]

What version of gazelle are you using?

Latest: 0.39.1

What version of rules_go are you using?

Latest: 0.50.1

What version of Bazel are you using?

7.1.2

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

All

What did you do?

When generating BUILD.bazel files using Gazelle, labels are created based on the repo_mappings of the module where Gazelle is declared. This ensures that the correct labels are generated for dependencies.

However, issues arise when Gazelle is run in different contexts, specifically when using the go_deps Bzlmod extension. In this context, the repo_name of rules_go is set to io_bazel_rules_go, rather than the default rules_go.

Typically, this difference in repo_name is handled well by the go_deps extension, which generates appropriate labels in external Go modules' BUILD.bazel files. The issue occurs when an external Go module already has a BUILD.bazel file with labels referring to the default @rules_go instead of @io_bazel_rules_go.

This can happen in two scenarios:

1. The module was published with BUILD.bazel files referencing @rules_go.
2. A developer uses a replace directive for local development of an external module, which includes its own BUILD.bazel files with references to @rules_go.

What did you expect to see?

BUILD.bazel files generated by Gazelle with the default rules_go repo_name of @rules_go should be loadable via the go_deps Bzlmod extension, regardless of the context where they are used.

What did you see instead?

BUILD.bazel files generated by Gazelle with the default @rules_go repo_name are not loadable within the go_deps Bzlmod extension, as the extension only recognizes @io_bazel_rules_go. This causes build failures due to mismatched labels.

Workarounds

1. Switch all rules_go usages to use the repo_name io_bazel_rules_go globally. This works but is unexpected, as most users are accustomed to the default @rules_go.

2. Override and force the extension to regenerate the BUILD.bazel files with the correct labels. However, this is tedious and not ideal for users, who would prefer something automated.

3. Modify Gazelle to generate BUILD.bazel files using @io_bazel_rules_go in the context of go_deps. While this may solve the issue, it could break backward compatibility or have other unintended consequences.

For Discussion

• Could this discrepancy between rules_go and io_bazel_rules_go more smoothly?
• Should bzlmod extensions always override existing BUILD.bazel files?
• Should a repo generated from this bzlmod extension inherit the repo_mappings not of gazelle, but from the users project? Is that even possible?

[fmeum]

Case 1 should probably either be consumed as a Bazel module directly or brought in with clean mode. Do you have an example for this case?

For case 2 I'm not so sure what to do.

[stefanpenner]

@fmeum Thanks for responding!

for clean mode are you referring to fetch_repo --clean?

I believe by default it is auto, should that change?

re: case (2). I think, but I should double check, we actually copy files, before running fetch_repo so --clean would also address that too. Let me investigate.