Is it a good idea to not depend on cargo?

[csmoe]

I'm not challenging the core design of rules_rs — I'm just exploring a possible alternative at the implementation level.

Currently, rules_rs reimplements Cargo's feature and dependency resolution logic on its own. In practice, I've run into a few problems with this:

1. Host and target feature/dependency mixing. Host and target feature dependencies get mixed together, so some host-only dependencies leak into the target's dependencies. This pollution causes certain crates that compile fine under Cargo to fail under rules_rs, because the extra dependencies leave rustc unable to reach a decisive result during trait resolution.
2. Build script environment variables not set correctly. Some of the environment variables that Cargo sets for build scripts aren't set properly. For example, cc-rs relies on OPT_LEVEL to pass optimization flags to C libraries, but rules_rust only supports 0–3 (see https://github.com/bazelbuild/rules_rust/blob/97e0d25539a1f7aca65625762679fa742ae8d750/rust/toolchain.bzl#L813), whereas opt-level can also be z (and s).

I'm still debugging my project. As far as I know, Cargo's feature and dependency resolution is quite complex, and Cargo itself keeps evolving. So I'm not sure how robust rules_rs's effort to replicate Cargo's behavior really is in the long run.

[dzbarsky]

@csmoe Hi! Thanks for filing!

1. Yes, this is a known gap, Cargo resolver-v2 host/target feature-world split #157 should address it
2. This seems orthogonal to feature/dependency resolution. Also I would highly suggest to not compile C code in build scripts via cc-rs, it's better to disable/override the build script and supply a cc_library where you have much more control over how it's built and can make better use of Bazel's capabilities

The reason that we reimplement parts of Cargo resolution are for performance and better integration with Bazel's downloader, caching, etc. https://github.com/bazelbuild/rules_rust uses cargo more fully for crate/feature resolution and suffers from worse performance and UX. It's possible that using Cargo even more fully than rules_rust could be an interesting trade-off in this space, if you have prototyped something I'm happy to take a look!

From what I know, I think it's going to be tricky because Cargo and Bazel will both want to orchestrate the build. Perhaps some changes to Cargo could allow a more effective resolution that Starlark could consume to materialize the repos :)