Provide a transition for switching the target platform to the exec platform?

[EdSchouten]

In bazel-contrib/rules_oci#590 and bazelbuild/rules_rust#2684 we noticed that a common mistake in rulesets is that they use executables provided by toolchains outside the scope of ctx.actions.run(). Namely, they get embedded into runfiles directories of binaries and tests.

One approach to work around this issue is to declare "run" toolchains, where you essentially leave exec_compatible_with cleared, but set target_compatible_with instead. This is what rules_python uses, which it can do because the toolchain is never directly invoked as part of ctx.actions.run(). It's only embedded into runfiles directories, so that a subsequent py_binary() can run it. In other cases this is impractical, because there is a desire to use tools both within ctx.actions.run() AND runfiles directories. In those cases you need to declare all toolchains in twofold, which is highly inconvenient.

In the PRs linked above we managed to prevent the duplication by adding a special transition like this:

def _transition_to_target_impl(settings, attr):
    return {
        # String conversion is needed to prevent a crash with Bazel 6.x.
        "//command_line_option:extra_execution_platforms": [
            str(platform)
            for platform in settings["//command_line_option:platforms"]
        ],
    }

transition_to_target = transition(
    implementation = _transition_to_target_impl,
    inputs = ["//command_line_option:platforms"],
    outputs = ["//command_line_option:extra_execution_platforms"],
)

This can be combined with a helper rule that depends on a toolchain and returns its configuration through one or more providers. By setting the execution platforms to the target platform, the toolchain resolution is performed in such a way that the exec and target platforms are identical.

Considering that we already needed a transition like this in multiple places, would it make sense to provide it as part of rules_platform? Or would it instead be desirable to extend Bazel's Starlark API for supporting more flexible resolution of toolchains? See bazelbuild/bazel#19645.

[groodt]

This would be so useful! The approach you've got there is brilliant! I don't think I ever would have thought to try doing it that way! That's some deep, deep magic. It would be great to have this approach blessed somewhere, or an alternative formalized!

Out of curiosity, would anyone happen to know if/how buck2 handles this? Maybe they have an approach that we could learn from for bazel.

[groodt]

Another great property of this solution is that it works in non-RBE scenarios. The default platform will be @platforms//host so the transition will be noop in non-RBE.