feat: expose toolchains
New Feature
Exposed toolchains so that they can be used independently of registering them with the repo rules.
Test plan
Checked that my code is able to build while using the new public toolchain rules.
Since we have tar I'm generally supportive of adding more common tools
i am beginning to think that we should have another ruleset called rules_bash where bring in these tools hermetically. bazel-lib is becoming bloated.
https://github.com/tweag/rules_sh is already maintained by some Nix experts 😉
@thesayyn this PR doesn't have actually fetching the tools yet. I wanted buy in on adding this before I put that work in. Plus I'm using this with Nix so I don't actually need that part for my stuff 😅
Regarding rules_bash (or rules_sh), how would you feel about something like toolchains (much like platforms) that just contains the toolchain_types, the providers, and the rules for instantiating the toolchain, so there's a common definition. Actual fetching of the toolchains would belong in other repos. I am discussing this a little bit with @alexeagle and Matt Clarkson on Slack 🙂
I think the toolchain_types have to go somewhere else
https://github.com/bazel-contrib/SIG-rules-authors/issues/91
@alexeagle / @thesayyn greatly scoped this down to just exporting the toolchain rules. Also happy to close this and just import them from private in my code if that's preferred.
I don't see on this thread an answer to: why would you want to load the toolchain symbols independently from registering them? Any increase to the public API surface constrains what maintainers are able to change, so it should come with an accompanying end-user benefit.
I updated the overall PR description to cover the motivation, which is registering these toolchains without the binaries being provided by aspect_bazel_lib. If that doesn't align with the goals here, we can just close this, and I will just directly import them from the private directory.