Cargo workspace member dep version ranges

[TroyKomodo]

Problem

In cargo workspace

crates {a, b, c}

a requires: b >= 1.0

c requires: b >= 1.1

b is at 1.2.0

how can I specify these versioning conditions when publishing to crates io without resorting to using path = "../../b" or some other combination of path based providing.
Currently workspace deps override the version config value.

Proposed Solution

Have a new config member = true which allows you to reference workspace members directly without using a workspace dep and then allow that member to have version ranges and if not provided use the current version of the member.

I don't like the idea of paths because it makes it increasingly messy. I think its silly we need to declare workspace members as part the workspace-deps list.

Alternatives

1. Allow for a new template in the path syntax to resolve to the root of the workspace b = { path = "{root}/crates/b" }

2. Lift the restriction of workspace version inheritance and instead allow workspace deps to override the version.

Notes

No response

[epage]

So if I'm understanding correctly, you want to do:

---

Cargo.toml:

[workspace]
members = ["crates/*"]

crates/a/Cargo.toml

[package]
name = "a"

[dependencies]
b = { version = "1.0", member = true }

crates/c/Cargo.toml

[package]
name = "c"

[dependencies]
b = { version = "1.1", member = true }

crates/b/Cargo.toml

[package]
name = "b"
version = "1.2.0"

---

Instead of:

---

Cargo.toml:

[workspace]
members = ["crates/*"]

crates/a/Cargo.toml

[package]
name = "a"

[dependencies]
b = { version = "1.0", path = "../b" }

crates/c/Cargo.toml

[package]
name = "c"

[dependencies]
version = { version = "1.1.0", path = "../b" }

crates/b/Cargo.toml

[package]
name = "b"
version = "1.2.0"

---

Is that correct?

[epage]

Allow for a new template in the path syntax to resolve to the root of the workspace b = { path = "{root}/crates/b" }

That is supported through the unstable path-bases feature, see #14355 and https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#path-bases

Lift the restriction of workspace version inheritance and instead allow workspace deps to override the version.

This would allow you to reuse the path but reduce have a custom version range, right?

[TroyKomodo]

Yes that's correct.

[TroyKomodo]

This would allow you to reuse the path but reduce have a custom version range, right?

Yes, so we could do workspace = true and add the dependency to the workspace deps. And then override the version in the place where it is inherited.

[dependencies]
b = { version = "1.0", workspace = true }

I also think in your 2nd example you switched the package version with the dependency version.

[epage]

Variants of member = true include:

• Auto-insert the version into path dependencies, see Tracking issue for Deduplicate Cargo workspace information RFC #8415 (comment)
• Don't require a workspace.dependencies entry for workspace members, see Allow manifest dependencies of same-workspace crates to use workspace = true #13453

Those don't handle the problem of when you want to intentionally have your version requirements diverge.

One part of #13453 that has particular relevance for member = true is that both can only fully process dependencies after the workspace is fully loaded which is not the case today. To support this, we'd need to add extra phases of parsing manifests and this was a major reason #13453 was rejected.

As an alternative to #13453, we proposed #15180 but that still has the problem of centralizing the version requirements.

[epage]

To avoid making assumptions, what is your use case for having version requirements diverge? Do you have any strategy to ensure your version requirements are not too low / stale?

[TroyKomodo]

To avoid making assumptions, what is your use case for having version requirements diverge? Do you have any strategy to ensure your version requirements are not too low / stale?

In our workspace if we make a change to a member because we need it in another member we then bump that version in place. We also have a publish time check to detect if any version is too low since we build with the version minimums.

The reason we need this is because it is very hard to detect programmatically if we depend on the newer version or if it was just a consequence of it being apart of the same workspace that the dependency version changed.

However obviously with semver breaking changes and we bump a major version we would need to fix that everywhere that is expected. However we could add a range to catch both ranges if we support both.

[epage]

We also have a publish time check to detect if any version is too low since we build with the version minimums.

Could you provide more details on this check?

[TroyKomodo]

We also have a publish time check to detect if any version is too low since we build with the version minimums.

Could you provide more details on this check?

It's a wrapper around -Z direct-minimal-versions https://crates.io/crates/cargo-minimal-versions

[epage]

Ah, I was not aware that had --detach-path-deps which is what I assume you are using for this.

[TroyKomodo]

Ah, I was not aware that had --detach-path-deps which is what I assume you are using for this.

Yes that is correct.