`cargo add` should "Do the Right Thing" for workspaces

[epage]

This is motivated by a discussion at crate-ci/cargo-release#288

Currently, cargo add will

• dep by path: use the path
• dep by name: look up version in crates.io and uses it

For workspaces, users generally want

• always use path dependency
• If crate being modified is publishable and the dependency is non-dev, use the version that is currently in the workspace

I propose we change cargo add to:

• If user specifies name@ver, name-as-uri, --git, or --ver, --path, process as we do today
• If name is in workspace (either as path or name),
  • always use path dependency
  • If crate being modified is publishable and the dependency is non-dev, use the version that is currently in the workspace

For the rare times this isn't the desired behavior, it would be relatively trivial for users to adjust. However, knowing the best practice for adding a workspace dep for new users is tricky

• With cargo-release, we've seen people use [patch] because it was the first way they discovered doing this
• It requires hand copying the version over when specifying path
• The version is flat out wrong when just specifying a name
• Its not obvious that dev-dependency doesn't need version which is important when there are test cycles

[epage]

@ordian does this sound good for moving forward? I'd like to have good workspace workflow out in people's hands being vetted before rust-lang/cargo#5586 so we don't have fret over how much we can change things later once this is in cargo.

[ordian]

There is already -p flag that is consistent with what cargo does in the workspace, e.g. cargo build -p <subcrate> <FLAGS>.
Are you suggesting cargo add <subcrate> <dep> syntax instead? I don't find that a good idea TBH, but maybe I misunderstood you. Sorry, looks like I misunderstood. You suggest cargo add <dep>, where <dep> is a crate in a workspace? Yeah, automatically inferring that it exists in the workspace and suggesting to use path might be a good idea. But I would give users a choice with ([Y/n]) option.

Wrt using the currently used version, what if there are multiple used in a workspace? Not sure if I understood correctly, but I don't think that deduplicating non-semver compatible versions is in scope of cargo add.

[epage]

My proposal is that when a user does cargo add <dep> that if <dep> is a member of the workspace and no other information is provided, we automatically do a path + workspace version.

Can a you have multiple versions of a crate be workspace members at the same time? If so, I'd suspect that is a corner case and would either pick the latest or error and tell the user to choose one.

I just found out about https://github.com/rust-lang/rfcs/blob/master/text/2906-cargo-workspace-deduplicate.md which will be a big help in these situations. I want to finish with cargo-edit first but I want to tackle that soon after.

[epage]

Also, I think a prompt would be unnecessary. This is standard enough behavior that prompting people would just be frustrating rather than helpful. Generally, people also have version control to both tell them what happened and help them back out a change.

Too many times, tools mix critical with non-critical prompts and I start auto-"y"-ing through and say yes to the wrong ones.

[ordian]

Yeah, I don't have statistics on what users actually want when they add workspace deps, that's why suggested the prompt idea but it might be not that good if there only one right answer to that (or in 99% cases). Anyway, I don't have a strong opinion here and PRs are welcome :)

[vjpr]

In JS-land, pnpm/yarn add pkg will add pkg as a workspace dependency with path as @epage has suggested. Works well.

https://pnpm.io/cli/add might be an interesting read to see some of the various workspace use-cases that might be good to support.