Allow passing multiple crate names to cargo new

[heisen-li]

Allow passing multiple crate names to cargo new.

close #9823

[rust-highfive]

r? @alexcrichton

(rust-highfive has picked a reviewer for you, use r? to override)

[heisen-li]

Strangely enough, I had to modify the test new::no_argument.

error: The following required arguments were not provided:
    <path>

to

error: The following required arguments were not provided:
    <path>...

Should this change be?

[alexcrichton]

Thanks for the PR!

I'd be a bit worried about how this feature would interact with flags like --name and such. That flag specifically is intended to apply to just one crate, but it's also imaginable that other flags like --edition both may and may not want to apply to all crates. Additionally you may also want some --lib and --bin crates. I'm not really sure how this can be handled to separately configure each new crate, and it seems like the best solution would be to continue to make one crate at a time.

[ehuss]

On a similar note, I would be concerned about the interaction with future changes like rust-lang/rfcs#2922 (#3506), which could add some complexity (especially if it adds interactive prompts).

[heisen-li]

Thanks for the PR!

I'd be a bit worried about how this feature would interact with flags like --name and such. That flag specifically is intended to apply to just one crate, but it's also imaginable that other flags like --edition both may and may not want to apply to all crates. Additionally you may also want some --lib and --bin crates. I'm not really sure how this can be handled to separately configure each new crate, and it seems like the best solution would be to continue to make one crate at a time.

Thanks for your reply. I understand your concern.

In my intended design, this only adds the ability to create multiple crates at once, whether bin or lib.

When reading the source code of the Cargo, I found that the cargo install and cargo uninstall commands can be used to install and uninstall multiple files at the same time.

This is also required in some scenarios, as suggested by @jyn514 .This does provide a solution.

In addition, the creation command of a single crate and the interaction of flags such as --name --edition are not affected.I can add more tests if necessary.

As you said, if there are different requirements for the current crate, for example, different lib, bin, edition, and name are required, creating a crate each time is the best solution.

[heisen-li]

On a similar note, I would be concerned about the interaction with future changes like rust-lang/rfcs#2922 (#3506), which could add some complexity (especially if it adds interactive prompts).

Thanks for the reply.

As in the reply above, in my envisioned design, none of the previous commands were affected for the creation of a single crate. It doesn't seem to be very complicated when it comes to adding some complex features in the future.

As you may be concerned, I do not recommend customizing each crate when creating multiple crates at the same time. This increases the operation difficulty and reduces the usability.

[jyn514]

I'd be a bit worried about how this feature would interact with flags like --name and such.

I think it would be reasonable to forbid using --name with multiple crates. I don't think cargo needs to forbid creating multiple crates at all for the user experience to still be good.

[heisen-li]

I'm so sorry, I missed one thing. Applying the clap:::multiple function to the previous command results in cargo new a b c --vcs git fossil, which creates four crates a, b, c, and fossil. This was obviously not the intent of the order, and the Fosil sign should have been wrong.
The correct output should be:

error: Found argument 'fossil' which wasn't expected, or isn't valid in this context

USAGE:
    cargo.exe new <path> --vcs <VCS>

For more information try --help

So I used the clap:::use_delimiter function instead.
Also, I added some test cases.

[jyn514]

I don't understand - why do you think that behavior is wrong? I would rather be able to use spaces than have to use commas and get slightly better errors in rare circumstances; it seems correct that the command above generated a fossil crate.

[heisen-li]

I don't understand - why do you think that behavior is wrong? I would rather be able to use spaces than have to use commas and get slightly better errors in rare circumstances; it seems correct that the command above generated a fossil crate.

Thank you for your reply.
I think this may be confusing, and I think it’s more acceptable to put multiple crates names together to create them.

[alexcrichton]

Yes @qiangheisenberg I agree with your responses and about what this PR does. My point though is that it can be surprising that this PR behaves as it does. For example cargo new a b c --name d probably doesn't behave right since I think it names everything d. Additionally I think it is likely common enough to want to individually customize each created package that simply saying "you can't pass --lib, --bin, or other customization flags" isn't a great solution.

Overall I don't know if the use case of initializing multiple crates at once with the exact same configuration except for name is really all that common. Today you can invoke cargo new multiple times, and I don't think there's really something compelling as to why that should be changed?

[heisen-li]

Thanks for the reply.
I understand that this feature may not be that useful for most people. It just might be helpful for #9823 and #9825. It does provide a little convenience.

I'm just a simple extension of the previous one, and I don't think it's too much trouble with the complexities that follow.

I understand your concern. If the introduction of this feature causes a lot of problems or the cargo doesn't need it, you can always turn it off.

[alexcrichton]

I'd like to propose that we do not accept this feature and say that cargo new will only create one crate at a time at this time, but I'd like to get others thoughts on this as well:

@rfcbot fcp close

[rfcbot]

Team member @alexcrichton has proposed to close this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @ehuss
• @joshtriplett

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Agreed. I think it's reasonable to ask people to use for x in crate1 crate2 crate3 ; do cargo new $x ; done in the somewhat unusual case of creating multiple new crates at once.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[alexcrichton]

Ok looks like nothing major came up in the meantime, so I'm going to close.

[heisen-li]

Ok looks like nothing major came up in the meantime, so I'm going to close.

Maybe this issue #9823 can be closed?