Why no `.toolchains` property in `repository_ctx`?

[Filip Filmar]

Hi all.

I have another potentially interesting finding: it seems that `repository_ctx` does not have a `.toolchains` property.

IIUC, this makes it tricky to pass a binary into a repository rule, if you want to vary the binary based on the host platform. I didn't notice that there is the appropriate API in `repository_ctx`.

I ended up doing some guesswork to find the appropriate binary. But if seems as if this should be something that would need to be offered by bazel to have any chance at robustness.

For some background: I'm creating rules for downloading archives using the bittorrent protocol. Of course, to do this I want to pass a binary into the rule, and use it to start a download. I'd like to make it be a multi-platform rule, so I need a way to introduce a level of indirection depending on the host platform.  

Regular rules do this via toolchains, so even here it feels like `.toolchains` should be supported in the `repository_ctx` API.

Am I missing something?

Thank you,

F

[David Turner]

Toolchains require a Bazel build configuration to be resolved, and repository rules are run in a context where no such thing exists yet (for good reasons).
 
You can work around this issue by populating a repository with symlinks to various host tools that are auto-detected in a custom repository rule, then referencing these with labels that look like @host_tools//:toolname everywhere else.

Hope this helps,

- Digit

Thank you,

F

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bazel-discuss/CAKaOXijwiG906BqfyL%3DU7BDJQEAzBrMtiJYpv6rc-ydU14DGmQ%40mail.gmail.com.

[Filip Filmar]

On Fri, Aug 8, 2025 at 7:27 AM David Turner <di...@google.com> wrote:

Toolchains require a Bazel build configuration to be resolved, and repository rules are run in a context where no such thing exists yet (for good reasons).

Thanks for explaining. 

 

 

You can work around this issue by populating a repository with symlinks to various host tools that are auto-detected in a custom repository rule, then referencing these with labels that look like @host_tools//:toolname everywhere else.

I ended up reusing a similar device that is already set up by rule_multitool. It's a one-off so I didn't see fit to make it better.

F