//go/tools/gopackagesdriver fails on generated code when used with @rules_go as repo name #3515
Description
What version of rules_go are you using?
0.39.0
What version of gazelle are you using?
0.30.0
What version of Bazel are you using?
7.0.0-pre.20230316.2 (rolling)
Does this issue reproduce with the latest releases of all the above?
Yes: https://github.com/bricedp/rules_go_repro
What operating system and processor architecture are you using?
macOS 11.7.4 (Intel)
Any other potentially useful information about your toolchain?
Using Bzlmod without any content in WORKSPACE.bzlmod (fully migrated to MODULE.bazel)
What did you do?
Currently, the implementation of //go/tools/gopackagesdriver includes a hard-coded reference to the @io_bazel_rules_go repo name. When users import this module using the @rules_go repo name instead (without a repo_name="io_bazel_rules_go" override), the driver fails in some cases. For instance, I observed issues in VS Code when importing generated code built from protocol buffers. The package could not be found at all.
The GitHub repository below contains a reproduction of the issue with potential fix to verify:
https://github.com/bricedp/rules_go_repro
See README.md for instructions on use.
Note: My experience is with VS Code but this likely affects other editors as they all use the same driver.
What did you expect to see?
There is already a variable for overriding repo name with the GOPACKAGESDRIVER_RULES_GO_REPOSITORY_NAME (in this case it needs to be set to "@rules_go"), but the code in bazel_json_builder.go does not make use of this variable.
I propose we apply the following commit to bazel_json_builder.go to use the rulesGoRepositoryName variable, sourced from the GOPACKAGESDRIVER_RULES_GO_REPOSITORY_NAME environment variable. That environment variable can either be added to one's driver shell script or to VS Code settings under go.toolsEnvVars.
Fix in commit: https://github.com/bricedp/rules_go/commit/53a8f5ae44f4055cdfa962e153a85be9a8888b11
It appears this is the only hard-coded reference to @io_bazel_rules_go in all of the code used for the Go packages driver.
Happy to open a PR if others agree on this solution. Also happy to update the associated documentation. Let me know if there's a way to test this change to prevent regression.
What did you see instead?
See before and after images of the fix:
Before:
After:
