add a flag to `cargo add` to put dependency in workspace and inherit it

[Muscraft]

Problem

There is no way to tell cargo add that you want to add a dependency from a workspace explicitly. It is currently only done implicitly if you run cargo add foo and there happens to be a workspace dependency that matches it. There is also no way to add a dependency to a workspace and some of its members at the same time.

Proposed Solution

add flags similar to --inherit and --workspace foo,bar that explicitly allows you to add a dependency from a workspace and add a dependency to a workspace and some of its members.

Notes

This fell out of #10606. During the discussion of what should be included in cargo add support for workspace inheritance before workspace inheritance gets stabilized. The implementation of this should ideally not happen before stabilization of workspace inheritance.

--inherit:
This would be the main one to add a dependency from a workspace. Usage similar to cargo add foo --workspace -p bar, which would add foo to bar from a workspace. This could error if the workspace does not define that dependency or add it to the workspace if not found. features and optional are allowed to be used with this. features needs to be talked about as it might be good to add it to the workspace dependency features if the workspace dependency is not found. optional can only go to the inheriting package.

--workspace foo,bar
This would be to add a new workspace dependency to a workspace and then to the members that are specified, 1 member is required. Any flags does not conflict with [workspace.dependencies] would be allowed to be defined as well here and they would always go to the workspace dependency.

[epage]

Right now, you can explicitly name the source for a dependency (--path, --git, foo@version) but we will also infer the source (foo). We currently

• Check for an existing dependency in the same dependency table in the package
• Check for a workspace dependency
• Check for a workspace member
• Check for an existing dependency in a different dependency table in the package

But there is no way to explicitly state you want a workspace dependency (and have it error if it doesn't exist).

There is also no way to explicitly add a dependency to workspace.dependencies

Some questions I have

• Should adding a dependency with a workspace source error or automatically add the dependency
  • If automatically add, which dependency do we add the features to?
• Do we need a dedicated way of editing workspace.dependencies without touching a package's dependencies?
• Would it be confusing to --workspace flag for either case (seeing as that normally means "apply to all workspace members")

[epage]

--workspace foo,bar
This would be to add a new workspace dependency to a workspace and then to the members that are specified, 1 member is required. Any flags does not conflict with [workspace.dependencies] would be allowed to be defined as well here and they would always go to the workspace dependency.

imo I find it confusing that you pass package names through the --workspace flag.

[Muscraft]

I thought about suggesting --workspace and --workspace --members foo,bar but I didn't love that. It could be changed to --inherit and --inherit --members foo,bar

[epage]

imo there isn't really a reason to specify multiple members at once. We don't have any other way of adding dependencies to multiple packages. The only case I can think of is an option to migrate a workspace to workspace dependencies but since that is "one time", I don't see as much value.

[Muscraft]

In that case, do we go with --inherit and --workspace?

[epage]

Could you clarify how the flags differ? I feel like that wasn't too clear to me

[Muscraft]

I think there should be two different flags one for inheriting a workspace dependency and one for adding a dependency to a workspace and then inheriting it (it would also just be for adding a dependency to a workspace or overriding one).

--inherit would be for just inheriting a workspace dependency. That way you can limit the other flags to be used with it to only those supported and have nothing related to changing a source. This would be used for inheriting, adding features, or setting optional.

--workspace would be for adding a dependency to [workspace.depndencies], setting the source/version, and changing features. You could maybe extend this so that when trying to add a dependency and it is defined in a member it would switch it to foo.workspace = true if they're compatible.

Removing setting members for --workspace removes some of its functionality and I can understand if only one flag is wanted or needed.

[bindsdev]

I created an issue today proposing similar functionality, but it was closed in favor of this one (wasn't aware I was making a duplicate). Just going to present my ideas to further the conversation and to help eventually determine what the best approach would be. My proposal was as follows:

Adding to [workspace.dependencies]

Adding to the [workspace.dependencies] section could be done through a --workspace option. Chapter 3.3 of the Cargo Book, under The dependencies table section, states that:

• Dependencies from this table cannot be declared as optional

This would mean that the --workspace option would have to be mutually exclusive with the --optional option.

Adding workspace-inherited dependencies

Workspace-inherited dependencies could be added through a --workspace-inherited option. Chapter 3.1 of the Cargo Book, under the Inheriting a dependency from a workspace section, states that:

• Other than optional and features, inherited dependencies cannot use any other dependency key (such as version or default-features).

This would mean that the --workspace-inherited option would have to be mutually exclusive with all of the Source options, and all of the Dependency options besides --optional, --no-optional, --default-features (since it doesn't add to the dependency keys), --features, and --dry-run.

The --workspace-inherited option would just add crate_name.workspace = true to the desired dependencies section or crate_name = { workspace = true, ... } if --optional and/or --features were specified.