Allow to select Go SDK version from declared SDKs

[ash2k]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

See linked issue.

Which issues(s) does this PR fix?

Fixes #3302.

Other notes for review

[fmeum]

This looks pretty good now, thanks.

[linzhp]

Right now, we have:

It must still be named go_sdk, but this is a temporary limitation that will be removed in the future.

Can we instead remove this limitation, so we can name Go SDK with different names and switch with --@io_bazel_rules_go//go/toolchain:sdk=host_sdk, --@io_bazel_rules_go//go/toolchain:sdk=experimental_sdk, which matches the target name of go_download_sdk, go_wrap_sdk, go_host_sdk and go_local_sdk:

go_wrap_sdk(
    name = "experimental_sdk",
    root_file = "@other_repo//go:README.md",
)

go_host_sdk(
    name = "host_sdk",
    root_file = "@other_repo//go:README.md",
)

[fmeum]

@linzhp Wouldn't --extra_toolchains cover the case of selecting a particular toolchain "by name"? Matching by name rather than by label will not work well with Bzlmod, so I'm hesitant to introduce this now.

[ash2k]

Can we merge this please and consider using SDK names for the flag separately? I just really need this feature ASAP. Thank you!

[zakcutner]

@linzhp Wouldn't --extra_toolchains cover the case of selecting a particular toolchain "by name"? Matching by name rather than by label will not work well with Bzlmod, so I'm hesitant to introduce this now.

@fmeum Sorry to ping you on an old PR, I wanted to check if I was understanding your suggestion properly before opening a new issue. I'm facing the same problem where I want to force a different toolchain to be used by passing a flag, and I'm not sure --extra_toolchains would cover this use case.

# WORKSPACE

...

go_download_sdk(
    name = "go_sdk",
    version = "1.21.1",
)

go_wrap_sdk(
    name = "patched_go_sdk",
    register_toolchains = False,
    root_file = "@patched_go//:README.md",
)

...

I think bazel build --extra_toolchains=@patched_go_sdk_toolchains//:go_darwin_amd64 ... does not quite work how I would need, since it would enable both go_sdk and patched_go_sdk (and Bazel would choose somehow between the two) rather than enforcing that patched_go_sdk is used over go_sdk?

In addition, I think there's no way to have a flag with this method that works in general across platforms that I could add to my project's .bazelrc file, i.e. I would need to specify --extra_toolchains=@patched_go_sdk_toolchains//:go_linux_arm64 on ARM64 Linux?

[fmeum]

I think bazel build --extra_toolchains=@patched_go_sdk_toolchains//:go_darwin_amd64 ... does not quite work how I would need, since it would enable both go_sdk and patched_go_sdk (and Bazel would choose somehow between the two) rather than enforcing that patched_go_sdk is used over go_sdk?

Enabling (i.e., "registering") both go_sdk and patched_go_sdk is totally fine. Bazel tries all toolchains in a specified order and those listed in --extra_toolchains always come first. Assuming both go_sdk and patched_go_sdk match the required platform constraints, patched_go_sdk will be preferred with that command-line flag (and not used without it).

In addition, I think there's no way to have a flag with this method that works in general across platforms that I could add to my project's .bazelrc file, i.e. I would need to specify --extra_toolchains=@patched_go_sdk_toolchains//:go_linux_arm64 on ARM64 Linux?

You should be able to specify --extra_toolchains=@patched_go_sdk_toolchains//:all to register all the different platform variants of the given toolchain.

[zakcutner]

@fmeum Thanks so much for the quick response, that works great for my use case!