workspace dependency options for cargo add

[bindsdev]

Problem

cargo add, although an already extensive command, currently doesn't have support for easily adding dependencies to [workspace.dependencies] or for specifying that a dependency should be workspace-inherited. This issue proposes an option for both of these use cases.

Proposed Solution

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.

Notes

No response

[weihanglo]

Thank you for your detailed proposal. This is effectively a duplicate of #10608. Going to close this in favour of that :)

[bindsdev]

Thank you for your detailed proposal. This is effectively a duplicate of #10608. Going to close this in favour of that :)

No problem. I guess I overlooked an issue or didn't look far enough when I was looking to see if it had been proposed already 😄

[epage]

Thank you for your detailed proposal. This is effectively a duplicate of #10608. Going to close this in favour of that :)

No problem. I guess I overlooked an issue or didn't look far enough when I was looking to see if it had been proposed already 😄

While not obvious from the outside, we have labels for each command which can make it a lot easier to see what has been proposed before, e.g. Command-add

[bindsdev]

Thank you for your detailed proposal. This is effectively a duplicate of #10608. Going to close this in favour of that :)

No problem. I guess I overlooked an issue or didn't look far enough when I was looking to see if it had been proposed already 😄

While not obvious from the outside, we have labels for each command which can make it a lot easier to see what has been proposed before, e.g. Command-add

Great, thanks for that! Will reference that in the future.