🎉👍 First off, thanks for taking the time to contribute! 👍🎉
The following is a set of guidelines for contributing to coreutils. These are mostly guidelines, not rules. Use your best judgment and feel free to propose changes to this document in a pull request.
If you want to implement a tool from scratch, surely read the Creating a Tool section for orientation on where to start from.
The Code of Conduct for this repository here
In the Issues tab, click New issue, select Bug report or Feature request, then add the required information and submit it.
Always direct the Pull Request to the dev branch, try to be as descriptive as possible.
To start a tool, copy the template:
cp .template -r <TOOL_NAME>Now you can start editing files inside of the new directory (TOOL_NAME)
Here is a list of steps you should follow (not necessarily in order):
- Replace "template" occurrences in
build.rsby the TOOL_NAME. - Make changes in
Cargo.tomlindicated fields. - Configure argument parsing with
clapatcli.rs, here are some rules:- Every
Argneeds a.help(). - About the flags:
- Every flag needs,
.long()and.short()options - If the option is specified by the POSIX standard, use the short flag option specified.
- For long options and short options that are not specified by the POSIX standard, the flag should match other famous coreutils implementations names (if needed, use clap's
.visible_alias()or.visible_aliases()to fill this requirement) renaming long options can be discussed in the PR.
- Every flag needs,
- Every
- Every help message should start with upper case letter and end with a dot.
- Exit code is defined by the POSIX standard (extra customization might be required for extensions).
- We recommend that you create a Pull Request with check boxes (see an example).
- Update the README with the new status of the tool and contributors section.
- Create your PR.
You can create an in-progress PR, as well as a completed one.
Use the PR to debate, ask questions and ask for reviews (don't forget to be respectful and follow the Code of Conduct).
- Don't use nightly-only features.
- The code must be formatted by
rustfmtusingrustfmt.tomlconfiguration, otherwise the CI will fail.- Install the toolchain with:
rustup toolchain install nightly, format your code withcargo +nightly fmtand be sure thatcargo +nightly fmt -- --checkdoesn't print anything.
- Install the toolchain with:
- Main function should be the first block after global use statements and module statements (not module blocks).
- Documentation should always be included when needed, for both functions, methods, modules, etc.
- Tests, when possible, should always be included/updated with your changes.
- Always comment what you're doing if it's not obvious, should be before the code that need explaining.
- Try to be conservative about dependencies, only add if it is very necessary or if it will add good amount of ergonomics with few sub-dependencies. (you can check the dependency tree using
cargo-treecrate)- As for dependencies versions, use
"~<Version>"for crates below 1.0 and"^<Version>"for crates above 1.0.
- As for dependencies versions, use
- Avoid unsafe Rust in the tools code, if necessary, add a function in
coreutils_corecrate with necessary abstractions.
- First line should start with the name of the tool that is being modified, followed by
:. - The second line is empty.
- Reference issues and pull requests goes on the description after the second line.
Git Commit Messages Template:
Format if you're editing submodule:
<TOOL/LIB>: <SUBMODULE>: <SUBSUBMODULE>: <DESCRIPTION>
If there's no submodule:
<TOOL/LIB>: <DESCRIPTION>
Examples::
Mkdir: Added --mode option
Mkdir: add nested use imports and log error messages to stderr
Core: mkfifo: simplify the logic of mkfifo function