example of a bazel project which refers to an entire submodule of crates by relative path of crate dependency?

[sthornington]

Hi folks,

We are trying to further integrate a legacy mixed C++ + Rust bazel repository with another cargo workspace repository, via git submodule. We are running into some problems with cargo-bazel not creating crate labels for cargo crates referred to by relative path? I am not sure why? Does anyone have an example of how to make this work?

The only way I have gotten it to work so far is by literally putting redundant BUILD files into this otherwise-pure cargo repository so that bazel can build these things with labels like //submodules/mycargorepo/whatever but I would really much prefer if it were @submodules_mycargorepo_crate_index//:whatever or something like that, but I cannot seem to make it work ... Please help!

[sthornington]

The other way it works is, of course, if we publish these crates to a registry then refer to them by version, but that is a bit of a nightmare to commit changes because the path dependency of the temporary out-of-tree modified dependency crate breaks the CI for the outer repo, so we are trying to find a more integrated way to do co-development on these crates and the bazel targets which depend upon them. Thanks!

[sthornington]

@illicitonion is this something that is currently possible, or could be with some amount of (sponsored) work? tldr we have a cargo-based repository, and while it is possible now to iterate on code in it (thanks!), as well as code in the bazel repo which uses it, which links to it through cxx interop and so forth, it's still a bit of a hassle when each feature is finished, since the absolute paths that cargo-bazel puts into the lock file mean that any crate path dependencies are not portable between machines/repo checkouts. So, to get CI to pass on the outer repo, you first need to commit and make a full versioned crate release of the inner, and if CI finds a problem you need to repeat the whole process.

I am imagining some sort of "hermetic" way to refer to cargo crates by relative path within the current project, in a submodule, in a way that was stable and persistent/locked, so that if we had:

enclosing_bazel_repo/WORKSPACE
. . .
enclosing_bazel_repo/submodules/cargo_based_repo
enclosing_bazel_repo/submodules/cargo_based_repo/Cargo.toml # cargo workspace for all the crates and their deps
. . .
enclosing_bazel_repo/submodules/cargo_based_repo/rust/acrate/Cargo.toml

That somehow, in the outer repo, we could refer to labels like @cargo_based_repo_index//:acrate or something like that in a stable, hermetic way. I can't figure out how to do this without actually also creating BUILD files in all the places like acrate and replicating all the build targets and internal cargo_based_repo deps as bazel targets...

[rejuvenile]

For my project, I did place redundant BUILD files in my monorepo Cargo third_party repositories. I'm using from_cargo from crate_universe, so I have BUILD files in my project anyway. In this mode all_crate_deps() never includes monorepo dependencies (even if specified in Cargo.toml) so they must be added by hand, which is fine.

#3754 might also relate to your issue.