cargo init add option to remove default comment

[andrewgazelka]

Problem

While initializing a new project using cargo init, a comment is automatically inserted at the top of the Cargo.toml file:

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

Although this is undoubtedly a helpful resource for newcomers and those unfamiliar with Cargo, for seasoned Rust developers this is not necessary and it adds an additional manual step of removing it every time a new project is initialized. Especially for developers working with automated systems or setting up multiple projects, the comment can be slightly annoying.

Proposed Solution

I propose adding an option to the cargo init command, let's say --no-comment, that when used will not include the standard commented URL at the top of the Cargo.toml file. The command would look like this:

cargo init --no-comment

By providing this option, developers have the flexibility to opt-in or opt-out of having the comment in their Cargo.toml file as per their requirements or preferences. It wouldn't impact beginners as the default behavior would still be to include the comment, unless explicitly opted out using the --no-comment flag.

Notes

I believe this minor enhancement would improve the developer experience by reducing manual interventions, particularly for those creating a large number of Rust projects or using automated tools to initialize Rust projects. This change should not affect the functionality of cargo init, and it would be backward compatible since it just introduces a new optional flag.

Please consider this request and let me know if you need any additional information. I am willing to try to implement it. Thanks!

[epage]

For a lot of these requests, we tend to point people to #5151.

For me,

• Too much one-off flags or configuration can make it harder to use. We should consider what customization we prioritize.
• Passing in a flag seems like just as much work as deleting the line, or more work

I could see the possibility of moving this to a note: message that is emitted.

[andrewgazelka]

For a lot of these requests, we tend to point people to #5151.

ah that makes sense. was not aware of this

Passing in a flag seems like just as much work as deleting the line, or more work

I feel using sed adds un-needed complexity when I can just have an alias cargo init --no-comment

I could see the possibility of moving this to a note: message that is emitted.

Are you proposing the comment be part of stdout instead of text in the file?

[epage]

I feel using sed adds un-needed complexity when I can just have an alias cargo init --no-comment

I wasn't thinking of sed but that I would need to edit the file anyways and can just delete the line.

Are you proposing the comment be part of stdout instead of text in the file?

Not proposing it as in saying we should but bringing it up for brainstorming and either stdout or stderr, yes.

[andrewgazelka]

I wasn't thinking of sed but that I would need to edit the file anyways and can just delete the line.

I have a lot of cargo aliases in my zshrc so it would not require taking any more time typing. It would be a difference between cargo init with sed vs cargo init --no-comments or something like that. I agree with you. I think without an alias this makes no sense, but there are a lot of experienced Rust developers who have to manually remove the comment every time and especially when working in a giant workspace with many small (maybe even atomic) Rust libraries this can be very annoying. It is easy to forget to remove the comment and then suddenly you have a PR review that is nit picking at removing the comment and boom a context switch which reduces your flow state.

Not proposing it as in saying we should but bringing it up for brainstorming and either stdout or stderr, yes.

Makes sense. Yea I feel the comment is definitely helpful to beginners (maybe?) but does the comment outweigh it poluting so many people's Cargo.toml? I would be interested to see what other tools do by default.

[weihanglo]

there are a lot of experienced Rust developers who have to manually remove the comment every time

Out of curiosity. Why do people cargo init so often 🤔? I suppose cargo new and cargo init are less-used commands. Perhaps only cargo plugin developers would use them quite frequently.

[epage]

Until we have "cargo script", cargo init is the best native route for one-off workflows

As for my frequency for writing a new crate, its probably once every other month or so? I'm honestly more likely to copy/paste than start fresh though things like automatic inheritance for cargo new would help for people with less specialized workflows than mine.

[andrewgazelka]

there are a lot of experienced Rust developers who have to manually remove the comment every time

Out of curiosity. Why do people cargo init so often 🤔? I suppose cargo new and cargo init are less-used commands. Perhaps only cargo plugin developers would use them quite frequently.

Several use cases. I think the biggest one for me is if I have a giant workspace with many sub-libs where many depend on each other. Doing this speeds up build times afaik and even if it doesn't, it allows for CI to more easily detect changes and run a subset of all tests. Generally, I am making about one crate per day I'd say, but I am def not everyone.

[weihanglo]

Triage: Unless there are more interests in making it a one-off flag, I am now considering it as blocked by #5151.

[epage]

@weihanglo what are your thoughts on the idea of switching the comment to a note: printed to the screen?

[weihanglo]

A note: in console output is easier to miss in the first place.

However, since we have cargo add, maybe the comment is less visible than it was. I still think the comment helps with other settings though.