Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bzlmod: Reuse user-defined Go SDK for Gazelle bootstrap #1469

Open
fmeum opened this issue Mar 8, 2023 · 6 comments
Open

bzlmod: Reuse user-defined Go SDK for Gazelle bootstrap #1469

fmeum opened this issue Mar 8, 2023 · 6 comments

Comments

@fmeum
Copy link
Member

fmeum commented Mar 8, 2023

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
Copy link

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
Copy link
Member Author

fmeum commented Apr 13, 2023

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
Copy link

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
Copy link

If it can help, I did some experiments here: ylecornec/rules_go@958b568 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
Copy link
Member Author

fmeum commented Apr 21, 2023

@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
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants