In which way should I depend on workspace local crates?

Hi, I was wondering what kind of solution should I choose when depending on local crates inside of a workspace. Currently the project I’m working on contains multiple external crates which are accessed in local crates with

ext_crate.workspace = true
Or
ext_crate = { workspace = true, … }

While local crates are accessed like this

local_crate = { path = ”…”, … }

As is suggested here Cargo Workspaces - The Rust Programming Language

Is there a reason for this inconsistency? Or would it be appropriate to depend on these local crates in the workspace and access them in other crates via the workspace?

This option would allow specificying each crate only once which would allow

  • Namespace conflictions to be solved in workspace level.
  • Renaming crates requiring only workspace cargo.toml to change.
  • Let local crates access each other consistently with how they access external ones.

Are there some drawbacks that I am not seeing?

Thank you :grin:

The workspace = true syntax is pretty new, while the path syntax has been there forever, so path is more common historically. But I don't see a problem with using workspace = true for local crates.

1 Like

I wouldn't call it an inconsistency, because inherited dependencies are somewhat different from path dependencies. Inherited dependencies are expanded to "real" dependencies and don't do any resolution themselves. They override the manifest of the workspace member before dependency resolution, whereas path dependencies—like version or git dependencies—are part of dependency resolution. I don't see why you shouldn't combine both either, if that fits your workspace structure.

1 Like