Unable to use workspace dependency in patch

[tigerros]

I tried this code:

# empty project
[workspace.dependencies]
shakmaty = { git = "https://github.com/niklasf/shakmaty", branch = "master", default-features = false }

[patch.crates-io]
shakmaty = { workspace = true }

I expected to see this happen: dependencies that use shakmaty from crates.io get replaced by the git version.

Instead, this happened:

error: failed to parse manifest at `Cargo.toml`

Caused by:
  dependency (shakmaty) specified without providing a local path, Git repository, version, or workspace dependency to use

The error says I can use a workspace dependency.

Meta

rustc --version --verbose:

rustc 1.86.0 (05f9846f8 2025-03-31)
binary: rustc
commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb
commit-date: 2025-03-31
host: x86_64-pc-windows-msvc
release: 1.86.0
LLVM version: 19.1.7

[moxian]

This is a cargo issue, and would be more appropriate in cargo repo (https://github.com/rust-lang/cargo/issues).
rustc doesn't really know anything about workspaces...

[epage]

We should fix that error message to not mention workspace dependencies.

Could you help me understand your motivation for wanting to use a workspace dependency in a patch?

[tigerros]

Could you help me understand your motivation for wanting to use a workspace dependency in a patch?

To make sure dependencies use the crate version defined in workspace.dependencies.

[epage]

If its in workspace.dependencies, why not just have the original dependency inherit from it, rather than having some kind of dependency in there and then have the patch inherit it?

[tigerros]

I don't understand. I can't inherit the workspace dependency for dependencies (which are not in the workspace) of workspace members. That's why I'm using a patch. Am I misunderstanding?

[epage]

Ok, so you are patching a transitive dependency. You mentioned you want the version/source to be in workspace.dependencies. What value do you expect to gain from that?

Is this patch considered to be temporary or will you be maintaining it long term?

[tigerros]

I gain the same value as when I specify shared dependencies in workspace.dependencies rather than duplicating it in each crate.

[epage]

[patch] is only read in the root of the workspace, so there shouldn't be a need for duplicating a patches source.

We've had a lot of back and forth. If there is more, it might be good to provide a complete but minimal reproduction case which might help clarify some of the points of what you are doing.

[weihanglo]

There is one nasty difficulty of supporting this: [patch] can also be in Cargo configuration (.cargo/config.toml), and configuration has no knowledge of what workspace is. That said, it can be interpreted as "whichever workspace cargo is building."

On the other hand, while what you're doing is not disallowed, I would suggest using crates.io dependencies in workspace.dependencies, and git repo patch in patch section instead. Benefit of this pattern:

• Your package can still be able to publish to crates.io.
• It is easier to spot whether you're using the same version of shakmaty across the entire dependency graph. Git dependencies are treated as completely different, and you might have chance getting duplicate versions of shakmaty.

[epage]

Looks like we have #12031 for tracking the quality of that error message