Workspace crates should have an implicit patch for crates in the workspace.

[carllerche]

Whenever using workspace crates, I often end up having to add a list of patches in the root Cargo.toml for all the sub crates. For example, in tokio:

[patch.crates-io]
tokio = { path = "." }
tokio-async-await  = { path = "./tokio-async-await" }
tokio-codec = { path = "./tokio-codec" }
tokio-current-thread = { path = "./tokio-current-thread" }
tokio-executor = { path = "./tokio-executor" }
tokio-fs = { path = "./tokio-fs" }
tokio-io = { path = "./tokio-io" }
tokio-reactor = { path = "./tokio-reactor" }
tokio-signal = { path = "./tokio-signal" }
tokio-tcp = { path = "./tokio-tcp" }
tokio-threadpool = { path = "./tokio-threadpool" }
tokio-timer = { path = "./tokio-timer" }
tokio-tls = { path = "./tokio-tls" }
tokio-udp = { path = "./tokio-udp" }
tokio-uds = { path = "./tokio-uds" }

This is because, when compiling examples and benches (at least), the workspace crates are not, pulling from crates.io.

[sfackler]

I've run into this as well - it's pretty annoying!

[asajeffrey]

Ditto.

[h4x3rotab]

This is really annoying. Hope it can be fixed soon

[epage]

Before anything else, I wanted to call out from our contributing guide

Due to limited review capacity, the Cargo team is not accepting new features or major changes at this time. Please consult with the team before opening a new PR. Only issues that have been explicitly marked as accepted will be reviewed.

Until we've improved the situation, it is unlikely for any new feature we've not already committed to to be developed or reviewed. Even once that situation is resolved, it takes a person to step up and work on issues like this. Its not just a matter of implementing it but first resolving in a discussion in this thread what the behavior should be, including any compatibility concerns.

Talking about use cases would also be useful to make sure the feature will work as intended. For example, we've got two upcoming features related to dependencies and a possible alternative route for this one:

• cargo add foo will automatically use both the registry and path if foo is a workspace dependency, debuting in rust 1.62
• You will be able to centralize dependency definitions once Tracking issue for Deduplicate Cargo workspace information RFC #8415 is stablized
• What if we changed our route on this and had cargo new add the patch statements for you?

With use cases, we can discuss the pros and cons of any of these as a potential alternative way of resolving the underlying need.

[pksunkara]

when compiling examples and benches (at least), the workspace crates are not, pulling from crates.io.

I am sorry but can someone expand on why this is needed? Examples and Benches will take the deps from local code anyway, right?

[epage]

At this point, we have

• cargo add
• workspace inheritance

Reducing the need for this. If we feel doing something is worth pursuing, there is the alternative I brought up of having cargo new add explicit [patch]s (though that might confuse cargo add if we stopped putting the path in). We already have #12779 which edits the workspace Cargo.toml.

[epage]

Of note, this request is the opposite of #11133