bzlmod: Reuse user-defined Go SDK for Gazelle bootstrap

[fmeum]

The gazelle module currently always uses the go_default_sdk defined by rules_go, even if another module registers an SDK that takes precedence over the default one. This results in two SDKs being fetched when only a single one should be needed.

Ideally we would be able to ascertain that a given SDK is sufficient to compile Gazelle with and just use that one instead of go_default_sdk.

[ylecornec]

As an additional data point, it looks like this is even more of a problem for platforms not supported by go_default_sdk.

On NixOS in particular, downloaded binaries do not work because there is no dynamic loader in the standard location. But it is still possible to register host toolchains, or toolchains from rules_nixpkgs (with nixpkgs_go_configure in the case of go) in your main project.

[fmeum]

Assuming that Gazelle compiles with any reasonably recent Go SDK, we could have the go_sdk extension provided by rules_go generate a repository that provides the label of the first host-compatible SDK. Then Gazelle's module extension could use this label.

I will gladly help anyone who wants to get started implementing this.

[jtcarnes]

I work in an environment that go_default_sdk rule becomes problematic. Happy to make the MR as I have time. @fmeum what would be the best first port of call for this? What would the project find acceptable as a solution to the problem?

[ylecornec]

If it can help, I did some experiments here: https://github.com/ylecornec/rules_go/commit/958b568c108ba931b1396159dc82064dadd74fa8 and managed to setup gazelle on a project compatible with both NixOS and Ubuntu. In this POC:

• The go_sdk module extension generates a host_compatible_toolchain repository which exposes the label of a toolchain that could be used by gazelle (it required changes to go_repository_cache to use a go_sdk_label argument instead of go_sdk_name).
• The toolchains considered are the following:
  • Toolchains declared with the host tag
  • Toolchains declared with the download tag that are compatible with a call to detect_host_platform
  • Toolchains declared with a new custom tag, that can be used to declare toolchains defined outside of rules_go (for instance with nixpkgs_go_configure).

[fmeum]

@ylecornec That looks pretty good. Could you split it into two parts, moving the addition of the new tag to the second one? The first one could be an easy merge, but I would like to think more about the API for the second part.

[ylecornec]

Thanks, I split it into two parts and opened these PRs:

• https://github.com/bazelbuild/rules_go/pull/3543
• https://github.com/bazelbuild/rules_go/pull/3546.