Automatically register workspace members in `workspace.dependencies` in `cargo new`

[epage]

Problem

In using a workspace, I'd like it to be easy to setup workspace members to be used with workspace = true which includes reducing the number of places I need to update paths as I move packages in the workspace.

Proposed Solution

If you have the following workspace

[workspace]

and you run

$ cargo new foo

You should get

[workspace]
members = ["foo"]

[workspace.dependencies]
foo = { path = "foo", version = "0.1.0" }

Notes

RFC 2906 requested we implicitly add version when we see path which was rejected during stabilization.

#13453 requests we implicitly make workspace members available for workspace = true but this comes at many costs.

[epage]

I hesitate in us moving forward with this because I feel like inheriting dependencies is not mature enough

• #12162
• Its easy to look at a manifest-dir to see if a breaking change occurred until you start inheriting dependencies. If we had a good story around cargo-semver-checks, that'd be fine. However, that is likely blocked on public dependencies which is blocked on the quality of the lint, see https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/public.2Fprivate.20deps.20without.20rustc.3F/near/471031580

[epage]

#6126 suggests we either implicitly create patches for workspace members or cargo new adds the patches.

The question is which approach should be "blessed". I suspect with the patch approach, it is more annoying to keep your Cargo.lock inline with your patch versions so they are applied.

[epage]

We should consider the impact on #4242