🎉👍 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):
- Add the TOOL_NAME to all TOML files related to a platform so CI can better test your code
- Replace "template" occurrences in
build.rs
by the TOOL_NAME. - Make changes in
Cargo.toml
indicated fields. - Configure argument parsing with
clap
atcli.rs
, here are some rules:- Every
Arg
needs 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 an 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 checkboxes (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
rustfmt
usingrustfmt.toml
configuration, otherwise, the CI will fail.- Install the toolchain with:
rustup toolchain install nightly
, format your code withcargo +nightly fmt
and be sure thatcargo +nightly fmt -- --check
doesn't print anything.
- Install the toolchain with:
- The 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 functions, methods, modules, etc.
- Tests, when possible, should always be included/updated with your changes.
- Always comment on what you're doing if it's not obvious, should be before the code that needs explaining.
- Try to be conservative about dependencies, only add if it is very necessary or
if it will add a good amount of ergonomics with few sub-dependencies. (you can
check the dependency tree using
cargo-tree
crate)- 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_core
crate with necessary abstractions.
- The 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