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.

This came up in a code review discussion for an (accidental) re-implementation of platform_data: the target in platform_data is required to be executable = True. I thought the reason it's called platform_data and not platform_binary is specifically because the target doesn't have to be created by a binary rule, but can be any kind of data!

It would be nice to relax this restriction.

platform_data returns a DefaultInfo provider, discarding other providers from the original rule.

It also does not forward the args of the wrapped rule, so e.g. a py_binary with an args = [ ... ] parameter will not have its args provided when invoked through a platform_data rule.

Was tag/release 0.1.2 deleted? I was building against it, but it no longer exists.

Edit: and at some point in the last few days, the checksum on the 0.1.0 package was changed. Can you not edit/remove existing releases? It breaks the build for everyone that uses this package.

It would be great to add this module to the Bazel Central Registry!

@aranguyen @gregestren