A common point of confusion I see around `run_binary` is that it's hard coded to only expand `$(location` values which in codebases I work in are otherwise completely eliminated due to it being described as "legacy"
> location: A synonym for either execpath or rootpath, depending on the attribute being expanded. This is legacy pre-Starlark behavior and not recommended unless you really know what it does for a particular rule. See [#2475](https://github.com/bazelbuild/bazel/issues/2475#issuecomment-339318016) for details.
If `execpath` is used instead as the appropriate alternative, the rule does no do any expansion and fails the action. This change adds support for expanding all available patterns whenever they're provided.
All actions which use tool or executable for which is not clear if it comes from a toolchain, must set a `toolchain` parameter ( migration of Automatic Exec Groups).
As we discussed internally, I've modified actions so that it's recognised that tools are not from the toolchain. Hence, there will not be an error which states `Couldn't identify if tools are from implicit dependencies or a toolchain. Please set the toolchain parameter. If you're not using a toolchain, set it to 'None'.`. Hence, no need for the toolchain parameter.
This rule is an alternative for genrule(): it can
run a binary with the desired arguments,
environment, inputs, and outputs, as a single
build action, without shelling out to Bash.
Fixes https://github.com/bazelbuild/bazel-skylib/issues/149
Alexandre Rostovtsev