cargo add to add a folder as member to an existing workspace project

[sassman]

Problem

As I was reading thru #10608 I was missing one aspect: to use cargo add to extend an existing workspace project by a new member.

Originally the feature was requested at cargo-generate (see cargo-generate/cargo-generate#1340)

But I wonder if that should be "base" functionality of cargo add or not?

To summarize the assmptions:

1. one has a cargo project that is a workspace project
2. one has an existing cargo project that should become a workspace member (e.g. generated by hand or cargo-generate) we name this member_y
3. call cargo add to put this named project as a member in the workspace project manifest

Proposed Solution

Not sure, if this is really wanted it could be

cargo add --member ./member_y

Notes

• In cases where the current project is not a workspace project, this command should just fail and make no further assumptions
• In cases where the named member_y does not live within the folder tree of the current working directory (someone calles it like cargo add --member ../member_y the command should just fail and suggests that member_y should be moved into the current folder
• In cases where member_y is not a valid cargo project the command should also fail

[epage]

When you run cargo new or cargo init, we will automatically add the new package as a member.

However, in your case, it already exists.

Overloading cargo add feels like it could make the command more confusing. We could make a new command.

Either way, there is also the question of value. We are not trying to have people never directly edit manifests. With cargo add, we help users confirm the name, auto-select versions, guide them through features, etc. With adding to members, we'd be taking a value the user already knows and putting it in toml. The opportunities to do this are reduced by cargo new and using globs in members.

[sassman]

Those are all fair points. Yet, having a dedicated new command for this feels counter intuitive and somehow over engineered.

As part of cargo add it would feel at least at the right place, this is the command that in my mind would feel the place to be when I would want (if ever) this functionality.

But I agree the value-add is essentially very low.

For now I'm going to implement it in cargo generate since it's somehow the counterpart of cargo new or init.

So feel free to close this issue.