Added cargo_bootstrap_repository rule

[UebelAndre]

The problem

I'm looking into ways to write more repository rules using Rust binaries but am constantly stumped on the issue of bootstrapping. Since I can't use the rules themselves in a repository rule, I have to find ways to either build binaries using the rules and host them somewhere to be downloaded, or build outside of Bazel before running Bazel.

The goal

The goal is to be able to build Rust binaries for use in repository rules without needing separate infrastructure to host a binary or require something be ran before the my Bazel invocation

This solution

The cargo_bootstrap_repository rule is inspired by some work done to test crate_universe in CI. It allows for tools to be built in a repository rule, thus avoiding the need for additional infrastructure or build commands.

Evidence

This PR retrofits crate_universe to use this new rule which also stands as an example of how to use it for other things such as #421 which I still find interesting and a nice improvement. With this rule, the worker can be built before it's expected to be invoked.

Details

While it's nice to be able to build binaries in repository rules, this is less optimal in comparison to downloading a binary which can be cached in a repository cache. Each cargo_bootstrap_repository has an install target which allows users to extract the built binary should they want to publish it somewhere. Though, this should only be thought as a small escape hatch for cases where teams are still in the early phases of integrating their projects with rules_rust. Ideally, any team interested in publishing a built binary should build it using the typical rust_binary rule and publish a Bazel built binary.

[illicitonion]

This looks like a reasonable implementation, but I'm curious where you're wanting to use this. In general we don't want folks running cargo build in a workspace rule, so it seems a slightly odd thing to expose...

[UebelAndre]

This looks like a reasonable implementation, but I'm curious where you're wanting to use this. In general we don't want folks running cargo build in a workspace rule, so it seems a slightly odd thing to expose...

That's part of the problem and goal I mentioned. There are repository rules which have rust binaries built for them. But it's not always the case that the binaries can be built and published somewhere so that it can be used in a repository rule. If I write a rust binary in my repo, for use in a repository rule, how do I make sire it's built and usable without standing up another service? The solution doesn't need to be "use Cargo", but I feel it's simple, effective, and easy to maintain. But again, happy to hear other solutions.

[illicitonion]

Oh yeah, I understand the use-case - my question is more whether it's things in rules_rust you're wanting to boostrap, or things outside? Is this making something internal more easily re-usable internally, or is this an effort to make public something that was previously internal?

[UebelAndre]

Oh yeah, I understand the use-case - my question is more whether it's things in rules_rust you're wanting to boostrap, or things outside? Is this making something internal more easily re-usable internally, or is this an effort to make public something that was previously internal?

I have uses outside the rules. To try and not bottleneck other teams or force a crate to be rewritten in some kind of interpreted language, I thought a rule which does bootstrapping would be beneficial to many.

[illicitonion]

Works for me, as long as we're super clear that this isn't going to be covered by stability guarantees when releases come :)

[UebelAndre]

Works for me, as long as we're super clear that this isn't going to be covered by stability guarantees when releases come :)

Agreed. Any suggestions on how I can make that more clear? It is outlined in the COMPATIBILITY.md doc that the cargo package is not covered. Anything more I should do?

[illicitonion]

That's probably sufficient! I forgot that we carved out an exception for //cargo:cargo_build_script.bzl rather than opting the whole dir in :)