Managing dependencies of crates inside a workspace

[MaikKlein]

Workspace Foo

• Crate A depends on Bar
• Crate B depends on Bar
• Crate C depends on Bar
• Crate D

Where Bar is an external dependency that I also maintain. When I want to update to a newer version of Bar, I would have to change 3 Cargo.toml files, which is a bit cumbersome. It would be nice if I could specify the dependency in one place. Is this possible?

[alexcrichton]

Ah yes currently this isn't possible I believe. You can use something like [replace] during development but for actual publication the relevant Cargo.toml files all need to be updated individually

[jrobsonchase]

I've got a similar use case, though I don't actually control the duplicated dependency, and I've got a bunch of them.

The obvious solution, to me at least (and anyone who's worked on a large maven project), seemed to be some sort of variable substitution a la #4221, but it looks like that's a no-go. From that conversation:

we'd rather work on enhancing workspaces to support using one version of a crate across the workspace.

Is anything of that sort in the works?

My current (not very good) solution is to throw all external dependencies into a dedicated crate that then re-exports them so that they're at least all in one place. The downside is that now all of the external crates get built whenever any of my crates gets built, even if it needs only a subset, and it works poorly for macros, even with the accidentally-stabilized macro-reexport function.

I've looked into cargo-outdated and cargo-edit, but both seem more concerned with making sure that things are up-to-date, when I really care more about making sure that all of my crates agree on dependency versions.

[qiuxiafei]

Any update on this issue? Maybe something like managed dependency in maven is required to manage the version of some dependency throughout all sub-crates.

[sourcepirate]

+1

[viktorchvatal]

What about changing Cargo to allow specifying dependencies and their settings like version, etc., in workspace Cargo.toml? These could be used as default parameters for dependencies in inner crates.

Workspace Cargo.toml could have default versions specified

[dependencies]
log = "0.3.9"

All inner crates could inherit version from workspace just by omiting version at all

[dependencies]
log = {}

or specify any other dependency version for the crate

[dependencies]
log = "0.4.5"

[sanmai-NL]

@alexcrichton:

Ah yes currently this isn't possible I believe. You can use something like [replace] during development but for actual publication the relevant Cargo.toml files all need to be updated individually.

Why? Can you explain please? 🙂

[alexcrichton]

@sanmai-NL publication to crates.io forbids [patch] and [replace], so publication to crates.io requires that all the manifests are updated

[emschwartz]

Any update on this? I have a similar issue to @MaikKlein and @jrobsonchase. I work on a project with 16 crates in a workspace and currently it's a pain to make sure we only have one version of each common dependency. It would be very useful to have a way to specify the versions once in the workspace Cargo.toml.

[bstrie]

All inner crates could inherit version from workspace just by omiting version at all

[dependencies]
log = {}

I would prefer a more explicit syntax to communicate that the version is taken from a higher scope. This could be a new value for the version attribute such as version = "workspace" or version = "default", or a new attribute altogether like use-workspace-version = true.

[alexcrichton]

For anyone interested in this issue I've posted an RFC which I think will help resolve this. Feedback on the RFC would be most welcome!