- Feature Name:
- Start Date: 2021-01-07
- RFC PR: rust-lang/rfcs#3052
- Rust Issue: rust-lang/rust#83227
This RFC proposes to make the
package.authors field of
This RFC also proposes preventing Cargo from auto-filling it, allowing crates
to be published to crates.io without the field being present, and avoiding
displaying its contents on the crates.io and docs.rs UI.
The crates.io registry does not allow users to change the contents of already
published versions: this is highly desirable to ensure working builds don’t
break in the future, but it also has the unfortunate side-effect of preventing
people from updating the list of crate authors defined in
This is especially problematic when people change their name or want to remove their name from the Internet, and the crates.io team doesn’t have any way to address that at the moment except for deleting the affected crates or versions altogether. We don’t do that lightly, but there were a few cases where we were forced to do so.
The contents of the field also tend to scale poorly as the size of a project grows, with projects either making the field useless by just stating “The $PROJECT developers” or only naming the original authors without mentioning other major contributors.
crates.io will allow publishing crates without the
package.authors field, and
it will stop showing the contents of the field in its UI (the current owners
will still be shown). docs.rs will also replace that data with the crate
cargo init will stop pre-populating the field when running the command, and
it will not include the field at all in the default
Cargo.toml. Crate authors
will still be able to manually include the field before publishing if they so
Crates that currently rely on the field being present (for example by reading
CARGO_PKG_AUTHORS environment variable) will have to handle the field
being missing (for example by switching from the
env! macro to
The implementation of this RFC spans multiple parts of the Rust project:
Cargo will stop fetching the current user’s name and email address when running
cargo init, and it will not include the field in the default template for
crates.io will allow publishing versions without the field and with the field empty. The Web UI will remove the authors section, while retaining the current owners section.
The API will continue returning the
authors field in every endpoint which
currently includes it, but the field will always be empty (even if the crate
author manually adds data to it). The database dumps will also stop including
docs.rs will replace the authors with the current owners in its UI.
Cargo currently provides author information to the crate via
CARGO_PKG_AUTHORS, and some crates (such as
clap) use this information.
Making the authors field optional will require crates to account for a missing
field if they want to work out of the box in projects without the field.
This RFC will make it harder for third-party tools to query the author information of crates published to crates.io.
By design, this RFC discourages adding the metadata allowing to know historical crate authors and makes it harder to retrieve it. In some cases, crate authors may have wanted that information preserved. After this RFC, crate authors who want to display historical authors who are not current crate owners will have to present that information in some other way.
This RFC reduces the problems related to changing the names in the authors field significantly, as people will now have to explicitly want to add that data instead of it being there by default.
We could do nothing, but that would increase the support load of the crates.io team and would result in more crates being removed from the registry due to this issue.
package.jsonhas an optional
authorsfield, but it’s not required and the interactive
npm initcommand does not prepopulate the field, leaving it empty by default. The npm Web UI does not show the contents of the field.
setup.pydoes not require the
authorsfield. The PyPI Web UI shows its contents when present.
authorsfield, and the RubyGems Web UI shows its contents.
composer.jsonhas an optional
authorsfield. While it’s not required, the interactive
composer initcommand allows you to choose whether to pre-populate it based on the current environment or skip it. The Packagist Web UI does not show the contents of the field.
- What should we do about the metadata in already published crates?
package.authors field could be deprecated and removed in a future
A future RFC could propose separating metadata fields that could benefit from
being mutable out of
Cargo.toml and the crate tarball, allowing them to be
changed without having to publish a new version. Such RFC should also propose a
standardized way to update and distribute the extracted metadata.