-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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.
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
authors-file
package field
#14949
Comments
authors-file
package field
In that context, I'm not really seeing us making use of a |
Thanks for the reply. That makes a lot more sense, and seeing as it's not even a requirement means anyone who is in need can simply default to using a CONTRIBUTORS file or the like. I will drop the issue 👍 |
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`
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`
Problem
Hello 👋
I am building some rust software, and couldn't find a package field that allows for mentioning/referencing an AUTHORS file in the authors field. This is unfortunate, as I already make use of a non-standard license, and the license-file field came in very handy. I assumed something like authors-file should also exist, but alas.
When a project sees multiple contributions, It is not feasible to keep track of them all in a authors list, nor is it expandable. It would be nice to have a field where we can pass in a markdown or text file with a list of maintainers/contributors, and have cargo fetch that into its package metadata.
Proposed Solution
I propose adding an authors-file field to Cargo.toml that works similarly to the existing license-file field. Here's how it would work:
The AUTHORS file would support categorization through comments, with lines starting with # being used as category headers:
Additionally, we should provide support for GitHub's CONTRIBUTORS file format, allowing markdown formatting while extracting just the relevant contributor information.
Notes
This is my first potential contribution to the Rust ecosystem, and I'm really excited about it! It follows the precedent set by license-file and provides a more scalable alternative compared to listing authors directly in Cargo.toml.
I'd love to hear what others think and if its a good idea, I'd love to submit a pull request. Looking forward to getting involved with the Rust community through this feature! 😊
The text was updated successfully, but these errors were encountered: