`cargo new` and `cargo init` should optionally populate `package.description` in `Cargo.toml`...

[busticated]

Problem

hey there 👋

i noticed that crates.io requires a package have a description (docs) but the cargo new and cargo init commands currently do not let you set that field.

Proposed Solution

allow users to set a package's description field via option flag - something like:

cargo new path/to/my-crate --name my-crate --description 'a new crate, yay!'

Notes

No response

[epage]

There are a lot of fields of interest and a lot of ways to handle them (CLI vs prompts) and I feel this would be better left to be part of #5151.

[busticated]

sure, but i suppose the blocker there is that there currently isn't an RFC?.. or did i miss it? from that thread, i'm not sure what the templates feature is, really. at the least it seems reasonable to expect that cargo new and cargo init would produce a valid manifest for crates.io even if those required fields cannot be set via flag / option.

[epage]

I'm going to propose to the cargo team that we close this.

I feel like there isn't enough of a case to justify breaking ground on this independent of #5151 where we can take a more holistic view of the problem. If nothing else, the user can always workaround this by editing the file directly. For me, the better route would be to focus on warnings once we have #12235.

[weihanglo]

at the least it seems reasonable to expect that cargo new and cargo init would produce a valid manifest for crates.io even if those required fields cannot be set via flag / option.

I've seen lots of cases that people are lazy and always submit default placeholders of different tools. From where I see it, producing an incomplete manifest is an intentional choice giving people think twice before uploading to crates.io.

[weihanglo]

Going to close this. See #12736 (comment) for alternatives.