Open joshparallel opened 1 year ago
Thanks for the issue report! The best thing to help out initially here would be a PR modifying https://github.com/bazelbuild/rules_rust/tree/main/examples/crate_universe (maybe https://github.com/bazelbuild/rules_rust/tree/main/examples/crate_universe/cargo_workspace specifically) which demonstrates the issue, so we can do some debugging of precisely what the issue is. After that, hopefully either someone can get it fixed up, or can help guide you towards doing so yourself :)
@illicitonion Thanks! I just tried in #1921.
Update: I traced this to an issue in cargo_toml
, and filed an issue: https://gitlab.com/crates.rs/cargo_toml/-/issues/25
You can set [package] workspace = "../../"
to make the association explicit, and not rely on a search.
(First off thank you all so much for developing these Bazel rules! I'm really excited to start using Bazel in my company's Rust codebase.)
I have a few instances of crates nested in other crates, like so:
When I try to update the
Cargo.Bazel.lock
file with e.g.CARGO_BAZEL_REPIN=true bazel test //...
, I get:The relevant part of
.../firmware-shared/serialization/macros/Cargo.toml
is:But these dependencies are in fact listed in the workspace
Cargo.toml
file:I'm guessing that Crate Universe is thinking that
serialization/Cargo.toml
-- the crate within whichserialization/macros
is nested -- is the workspaceCargo.toml
file, when in fact it isn't.For now I made all nested-crate dependencies explicit rather than using workspace dependencies, but would love for Crate Universe to handle this! Please let me know how I can help!