Repository navigation
package.authors is deprecated without explanation #16458
Description
https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field
The
authorsfield
Warning: This field is deprecated
The optionalauthorsfield lists in an array the people or organizations that are considered the “authors” of the package. An optional email address may be included within angled brackets at the end of each author entry.
[...]
This field is surfaced in package metadata and in theCARGO_PKG_AUTHORSenvironment variable withinbuild.rsfor backwards compatibility.
I found this in the docs, and had no clue what to do. A warning just saying "This field is deprecated" is not very useful, in my opinion. I was very confused. After a bit of research, I now know why it was deprecated. I propose adding a (short) explanation as to why it was deprecated, possibly a link to the RFC making it optional (which AFAICT contains most of the rationale for deprecating it), and note that you do not need anything to replace it.
Secondly, I think "(deprecated)" should be added in the table of contents:
authors — The authors of the package.
Just like was done with [replace]:
[replace] — Override dependencies (deprecated).
Activity
epage commentedon Jan 2, 2026
For some reason, making too much ado about deprecated functionality in the documentation, like providing treatises explaining why, doesn't sit right with me but unsure if any biases are playing a part in this so I might need to sit on this for a bit.
Specifying what to use instead does make sense but
authorswas not superseded.We probably should not link to RFCs. Too many people confuse these as living pieces of documentation, rather than historical documentation. It might work for a deprecation to say "here is the decision" but that is all we can say. Motivations can evolve over time. Even then, the subtlety of where RFCs are relevant can easily be lost.
GideonBear commentedon Jan 2, 2026
With "and note that you do not need anything to replace it", I mean to add a note explicitly saying that it wasn't superseded, and that it's safe to remove it without adding anything else. I expect a deprecation notice to contain something actionable.
The need for an explanation also decreases slightly with that; it's mostly that "this is deprecated" without anything else was very confusing for me.
epage commentedon Jan 2, 2026
Is it safe to remove? I assume third-party tools, like packagers, are using it and removing it in those contexts is not safe without other steps.
The most we can probably say is that it is ignored by cargo and crates.io
GideonBear commentedon Jan 3, 2026
Fair point! Lmk what you want to do with it, I can PR.
georglauterbach commentedon Jan 22, 2026
What's the status here?
Remove deprecated package.authors field
Remove deprecated package.authors field
Add TOML formatting support (#4226)
blinry commentedon Apr 10, 2026
I found this issue after seeing in the Cargo documentation that the field is deprecated, and being a bit confused as to why.
I'd also recommend a short note in that section explaining that the field was never used by any of the cargo tooling, so it's safe to remove (if that's true?).
JosiahParry commentedon Apr 10, 2026
This deprecation is quite intriguing to me. Does this mean that cargo doesn't want to provide a mechanism for crate attribution and authorship?
Depending on the license of a crate, downstream users are required to preserve copyright and attribution information. This info may exist in a NOTICE or LICENSE file in the crate source but
authorshas been a nice programmatic way to extract attribution info.I guesss I would frame this as a question as:
Context: Using Rust in the R language:
For further context, I'm one of the maintainers of the
extendrproject (think PyO3 but for R).The R package repository's policy on using Rust is
We use the
authorsfield to generate aLICENSE.notefile for appropriate attribution when submitting rust-powered R packages to the package repository via the R functionwrite_license_note()ensuring that we have appropriate attribution during the submission process.epage commentedon Apr 10, 2026
For people looking for more context on the deprecation, see https://rust-lang.github.io/rfcs/3052-optional-authors-field.html
shian15810 commentedon Apr 28, 2026
I think people are confused as to why making
authorsfield optional has anything to do with makingauthorsfield deprecated.johnnyasantoss commentedon Jun 4, 2026
Yes! Really confused even after reading the RFC. You won't be able to update authors after publishin, but what if that's okay?
KiChjang commentedon Jul 7, 2026
To be honest, a short note that says something like "use
AUTHORS.mdfor authorship" is good enough. As it stands, this note is not up to the diagnostic standards set by the Rust compiler.Upgrade to 2.368.2 (#15)
dead-claudia commentedon Aug 13, 2026
Quick question: what's the status of this? I see a "needs design" label, but it's unclear what would need "designed". If anything, #17332 looks like a proposed design of sorts, so I'm kinda confused.
epage commentedon Aug 13, 2026
A PR is an implementation. The tag is for design. The line is a bit more vague with documentation but there is discussion on what is worth covering for this.