Allow direct access to binary targets

[jklukas]

I have a use case where we want to build formatter binaries into docker containers and specify the specific linux binary files as input to be included in layers of the container, even if the active platform is macOS. I'd like to standardize on multitool as the framework we use for pulling down these binaries, but there's not a sufficient interface today to access the files via multitool.

The docs in https://github.com/theoremlp/rules_multitool/blob/main/multitool/private/multitool.bzl describe the structure of the per-tool spoke repositories that hold the underlying downloaded files, but we are using bzlmod, and these repositories are not exposed for use.

To be more concrete, we've defined a scalafmt section of our multitool lock file. And we have the following config:

# In MODULE.bazel

multitool = use_extension("@rules_multitool//multitool:extension.bzl", "multitool")

multitool.hub(lockfile = "//build_tools/external_tools:multitool.lock.json")

use_repo(multitool, "multitool")

# This is the line that makes the spoke repo visible
use_repo(multitool, "multitool.scalafmt.linux_x86_64")

The use_repo(multitool, "multitool.scalafmt.linux_x86_64") line allows us to access the binary. We can run it via ./bazel run @multitool.scalafmt.linux_x86_64//tools/scalafmt:linux_x86_64_executable and we'd be able to use that same address to specify the binary as a file to include in our docker container.

But, we get the following warning:

WARNING: .../MODULE.bazel:541:26: The module extension multitool defined in @rules_multitool//multitool:extension.bzl reported incorrect imports of repositories via use_repo():

Imported, but reported as indirect dependencies by the extension:
    multitool.scalafmt.linux_x86_64

Fix the use_repo calls by running 'bazel mod tidy'.

and bazel mod tidy removes the line.

Should we have a way to allow direct access to the downloaded files?

[markelliot]

I’m pretty sure you should be able to depend on the alias that’s exposed and that doing so should pull the correct underlying files…but I’ve not tested that.

The tidy command depends on some metadata the rules return — we could probably add an argument to the module that causes it to expose the spoke repos. The downside is that despite those being relatively stable, such a change would make them require stability (in naming, layout and format).