Workspace dependencies

Our private enterprise project “imeka” has about 40 binaries and the core lib is not really huge. It was starting to be a pain to work with, mostly because of RSL and the build time. The build time is perfect when we modify something outside the lib (bin, bench, test), but RLS insists on checking all binaries, each time, wathever I change.

All this to say that I tried using workspace in my project. I kept the most used part of my lib in “core” and all subprojects depend on “core”. In short, it’s a star pattern. RLS is now much more fun to use! And it’s building fast enough except when working on “core”, which is normal. However, I have two problems now:

  1. I have some tests in core/tests/*.rs (so, outside the lib). When I modify one, cargo test recompiles “core” and all subprojects. This makes no sense to me. How could an outside test have any impact on the subprojects? cargo test was automatic on a non-workspace project. Afaik, this is a bug.

  2. Most of the time I build from imeka/ and everything goes well. I compiled from a subproject yesterday and I suddenly had a missing dependency. cargo probably does a sum of dependencies before building the whole project, so my subprojects can use the dependencies of the other projects. However, it can’t do so when working on a subproject. Is there a way to ensure that all projects in my workspace have their dependencies? Imo, it shouldn’t even compile otherwise.

Thank you.

Are you using extern crate or the automatic inclusion from 2018 edition? As far as I’m aware the latter should not let you accidentally access dependencies available from other crates, but the former might.

I’m using automatic inclusion from the 2018 edition. Now that I think about it though, it was a missing feature, not a missing crate

core
nalgebra = { version ="0.17", features = ["serde-serialize"] }

subproject
nalgebra = { version ="0.17" }

So, you’re telling me that it shouldn’t happen on missing crates? EDIT I tested and it doesn’t happen on missing crates, only on missing features. Do you guys consider this as a bug?

Yeah, Cargo collects all the features requested from across the whole dependency graph, and builds the dependency with all of them. This means you can accidentally rely on features you haven’t requested.

This broke my work project after a cargo update, when a third party library stopped asking for a feature in one of its dependencies… that we had accidentally relied upon.

I consider this to be a real bug, but it’s not immediately obvious how to fix it.

Anyone can answer my first question? Why changing a out-of-the-lib test recompiles all dependant crates? How could an outside test have any impact on the subprojects?