Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Option to set default authors for cargo new|init #15027

Open
Kladki opened this issue Jan 7, 2025 · 6 comments
Open

Option to set default authors for cargo new|init #15027

Kladki opened this issue Jan 7, 2025 · 6 comments
Labels
A-manifest Area: Cargo.toml issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-init Command-new S-triage Status: This issue is waiting on initial triage.

Comments

@Kladki
Copy link

Kladki commented Jan 7, 2025

Problem

When making a new cargo package, I rarely set the author to anything other than myself. I don't want to have to write out my full name and email whenever I make a new package.

Proposed Solution

Inside the cargo configuration file, there should be an option to set default authors which should be set when running cargo new or cargo init.

Notes

No response
@Kladki Kladki added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Jan 7, 2025
@epage epage added Command-new Command-init A-manifest Area: Cargo.toml issues labels Jan 7, 2025
@epage
Copy link
Contributor

epage commented Jan 7, 2025

We used to infer package.author (#2696) but we then removed setting author in #9282. RFC 3052 explicitly called out that we'd not set the field. This proposal is for making it an opt-in but the value of package.authors is fairly limited. In fact, I wonder if we should instead be deprecating it.

@weihanglo
Copy link
Member

What is the difference between the current status and deprecating it. Is it like an announcement that Cargo no longer develops any new feature for it?

@epage
Copy link
Contributor

epage commented Jan 7, 2025

Some combination of

  • Document it as deprecated (and reject features)
  • Provide a deprecation warning on use
  • Remove on next edition

@weihanglo
Copy link
Member

  • Document it as deprecated (and reject features)

This looks fine, if we focus on rejectin features.

  • Provide a deprecation warning on use
  • Remove on next edition

This would push people away from using package.authors. Popular crates like clap provide crate_authors! macro to populate the value at compile time. And there are thousands of uses of it on GitHub.
Do we prepare to have that churn for the ecosystem?

As an alternative, we could decide to freeze any feature regarding package.authors in this issue. Whenever a new feature request pops up, we link to this issue.

@epage
Copy link
Contributor

epage commented Jan 7, 2025

clap no longer includes the authors in any output by default. Looking at a sampling of those search results:

  • package.authors is set and authors is set on clap, but clap isn't showing it
  • package.authors is not set and authors is set on clap, but clap isn't showing it
  • they are using clap v2 which means it is likely legacy code

epage added a commit to epage/cargo that referenced this issue Jan 15, 2025
@epage
docs(ref): Deprecate 'package.authors'
bce93d3 
This was left as a future-possibility in
[RFC rust-lang#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html).
Without a clear role for this field within Cargo/crates.io,
there seems little reason to actively support it (e.g. rust-lang#14949, rust-lang#15027),
including working through feature requests.
I see the potential for having some fields with more specific roles
(where to go for support, where to go for disclosing vulnerabilities, etc)
but even these run into the mutable data problem of `authors`.
Users can always manage metadata for their own purposes through `package.metadata`.

The RFC called out clap as an example of something that uses this.
Clap no longer does by default but users can opt-in through a
`help_template`.

For now, this notes the status in the documentation.
When we have[user control over Cargo lint (rust-lang#12235)
(and figure out namespacing with lints that overlap with Rust),
we can give a warning on this.
Based on feedback from users, we can evaluate removing this field in a
future edition.

We may want to consider doing similar for `badges`
@epage epage mentioned this issue Jan 15, 2025
Merged
@epage
Copy link
Contributor

epage commented Jan 15, 2025

In the Cargo team meeting, we discussed the status of package.authors and seemed to be in favor of deprecating it, so I've posted #15068.

epage added a commit to epage/cargo that referenced this issue Jan 15, 2025
@epage
docs(ref): Deprecate 'package.authors'
32d6e9d 
This was left as a future-possibility in
[RFC rust-lang#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html).
Without a clear role for this field within Cargo/crates.io,
there seems little reason to actively support it (e.g. rust-lang#14949, rust-lang#15027),
including working through feature requests.
I see the potential for having some fields with more specific roles
(where to go for support, where to go for disclosing vulnerabilities, etc)
but even these run into the mutable data problem of `authors`.
Users can always manage metadata for their own purposes through `package.metadata`.

The RFC called out clap as an example of something that uses this.
Clap no longer does by default but users can opt-in through a
`help_template`.

For now, this notes the status in the documentation.
When we have[user control over Cargo lint (rust-lang#12235)
(and figure out namespacing with lints that overlap with Rust),
we can give a warning on this.
Based on feedback from users, we can evaluate removing this field in a
future edition.

We may want to consider doing similar for `badges`
github-merge-queue bot pushed a commit that referenced this issue Jan 16, 2025
@weihanglo
docs(ref): Deprecate 'package.authors' (#15068)
2909c01 
### What does this PR try to resolve?

This was left as a future-possibility in
[RFC
#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html).
Without a clear role for this field within Cargo/crates.io,
there seems little reason to actively support it (e.g. #14949, #15027),
including working through feature requests.
I see the potential for having some fields with more specific roles
(where to go for support, where to go for disclosing vulnerabilities,
etc)
but even these run into the mutable data problem of `authors`.
Users can always manage metadata for their own purposes through
`package.metadata`.

The RFC called out clap as an example of something that uses this.
Clap no longer does by default but users can opt-in through a
`help_template`.

For now, this notes the status in the documentation.
When we have[user control over Cargo lint (#12235)
(and figure out namespacing with lints that overlap with Rust),
we can give a warning on this.
Based on feedback from users, we can evaluate removing this field in a
future edition.

This is as discussed in a recent Cargo team meeting

### How should we test and review this PR?

### Additional information

We may want to consider doing similar for `badges`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-manifest Area: Cargo.toml issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-init Command-new S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@epage @weihanglo @Kladki