bazelbuild / bazelbuild/rules_rust
Vendoring rules_rust crate deps
- Dominant language
- Starlark
- Stars
- 843
- Forks
- 651
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 15
Description
Currently rules_rust contains several rust tools such as `//tools/rustfmt`, `//tools/urls_generator`, `//util/dir_zipper`, `//util/process_wrapper`, `//crate_universe:cargo_bazel_bin`, `//crate_universe/tools/cross_installer`, `//tools/rustdoc:rustdoc_test_writer`, and `//tools/rust_analyzer:gen_rust_project`. Most of these use `crates_vendor` with checked-in auto-generated BUILD files, but none of them actually vendor the source of their 3rd party crate dependencies.
On [Fuchsia](https://fuchsia.dev), we vendor all of our dependencies, and disallow downloads during the build and in CI. This means that when we try to use rules_rust we run into failures such as not being able to use `rust_binary`/`rust_library` because they need `//util/process_wrapper` and building that requires downloading the `tinyjson` crate which fails.
For that process_wrapper case, we added the `tinyjson` dependency to our set of fuchsia's 3rd party vendored crates, and overrode the rules_rust one by making a local repository in our WORKSPACE:
```bazel
# A dependency of rules_rust
new_local_repository(
name = "rules_rust_tinyjson",
path = "third_party/rust_crates/vendor/tinyjson-2.5.0",
build_file = "third_party/bazel_rules_rust/util/process_wrapper/BUILD.tinyjson.bazel",
)
```
This worked, though we now have to make sure that we keep it up to date if rules_rust changes the deps of `process_wrapper`. However now that we're trying to use more rules_rust features, we're worried that this approach won't scale. Doing the same thing for `gen_rust_project` would require us to vendor >40 crates, and keep them in sync as rules_rust changes.
We're investigating other approaches such as building these rules_rust binaries separately and vendoring them as prebuilts in Fuchsia, which would probably require adding some options in rules_rust to accept prebuilt versions of these tools rather than building them itself. We've also noticed that rules_rust distributes prebuilts, but only for the `cargo_bazel` binary. Are there plans to do this for others like `gen_rust_project` as well?
Before investing more in a workaround, we wanted to ask the rules_rust maintainers: how would y'all feel about vendoring the deps of rules_rust's `rust_binary` targets, particularly `cargo_bazel` and `gen_rust_project`? We recognize that it may be undesirable for everyone to download the deps for these tools if they're not using them, but would it be possible to optionally vendor everything (maybe some sort of config/flag that overrides `mode = "local"` for all instances of `crates_vendor`)? If not do you have other suggestions of how we should be vendoring these deps ourselves?
Contributor guide
Assessment
This issue has not been assessed yet.