Allow manifest dependencies of same-workspace crates to use workspace = true

[CinchBlue]

Problem

I have 100+ workspace crates. In order for any of them to use each other, they need to use relative path.
It would be nice to just use:

[dependencies]
my-crate.workspace = true

for in-workspace crates when referring to other same-workspace dependencies. That way, I can move crates around + rename crates easily without having to edit every manifest that uses it in the workspace.

Proposed Solution

It should theoretically be possible without any surface changes at the manifest level. Each workspace crate has a canonical name, and alias could be handled through some additional spec field.

Notes

No response

[epage]

The original RFC took a different approach, making version implicit if path is used, see https://github.com/rust-lang/rfcs/blob/master/text/2906-cargo-workspace-deduplicate.md#no-longer-need-both-version-and-path-to-publish-to-cratesio

This was rejected during stabilization which had some complications. I suspect this will run into some of the same. Not knowing what version you intend to use when publishing can get complicated.

If we limited the design to path dependencies only, that helps but that leaves off a good segment of users.

[CinchBlue]

I suspect this will run into some of the same. Not knowing what version you intend to use when publishing can get complicated.

Then can't we alter publishing? This doesn't seem impossible, but it is indeed complicated. Where to start?

If we limited the design to path dependencies only, that helps but that leaves off a good segment of users.

What are other cases? I don't understand.

[epage]

Then can't we alter publishing? This doesn't seem impossible, but it is indeed complicated. Where to start?

We'd need to do so in a way that is backwards compatible and where the solution is not worse than the problem.

The cargo team is limited in its bandwidth for efforts it can shepherd. For myself I can't commit to helping in driving this process. For an idea of what we are working on instead, see https://blog.rust-lang.org/inside-rust/2024/02/13/this-development-cycle-in-cargo-1-77.html

What are other cases? I don't understand.

The big problem is when you want publish a package with a path dependency. In that case, you need to specify the version field for when its published.

If we make these implicit dependencies only exist with path dependencies, and not version dependencies, then we avoid a lot of the problems but then we make this only work for internal packages.

[epage]

This came up in conversation. In designing this, we'd need to decide how each field field gets set

• version: do we use package.version as a version requirement, artifically raising it? Would people need to define it manually for proc-macros so they can use = operator?
• registry: do we leave this as default?
• default-features: we'd likely need to close out Poor interaction between workspace dependencies and default-features #12162 first

[epage]

Another challenge with resolving this is in the implementation: we can't fully load a package until all packages in the workspace are partially loaded so we know what path (and maybe version) to use for each dependency. We've been trying to avoid multi-phase manifest parsing, especially mult-phase normalization. Manifest parsing is also very complex and I worry about adding to that complexity.