Contributing

These are the contribution guidelines for repod.

Development of repod takes place on Arch Linux’ Gitlab: https://gitlab.archlinux.org/archlinux/repod.

Please read our distribution-wide Code of Conduct before contributing, to understand what actions will and will not be tolerated.

License

All code contributions fall under the terms of the GPL-3.0-or-later.

All documentation contributions fall under the terms of the GFDL-1.3-or-later.

All past and present authors of repod are listed in Authors.

Discussion

Discussion around repod takes place on the arch-projects mailing list and in #archlinux-projects on Libera Chat.

Writing code

The project is written in typed Python. Please refer to the issue tracker for open tickets and ongoing development.

Tox and pdm need to be installed to be able to test the project’s code and to generate its user facing documentation.

The code base is type checked, linted and formatted using standardized tooling. Please make sure to run tox before providing a merge request.

For all notable changes to the code base make sure to add a Changelog entry in the [Unreleased] section.

Note

The changelog style follows the keep a changelog methodology.

Valid subsection topics are:

• Added for new features.

• Changed for changes in existing functionality.

• Deprecated for soon-to-be removed features.

• Removed for now removed features.

• Fixed for any bug fixes.

• Security in case of vulnerabilities.

Integration for text editors

An editorconfig file is provided in the code repository repository and the text editor in use should be configured to make use of it.

Additional helpful integrations for linting and type checking are:

• flake8

• isort

• mypy

Documentation

All code is documented following numpydoc (see the accompanying style guide for further info).

Writing tests

Test cases are developed per module in the tests/ directory using pytest and should consist of atomic single expectation tests. Huge test cases asserting various different expectations are discouraged and should be split into finer grained test cases or covered using parametrized tests.

Note

New code additions are not accepted below 100% test coverage.

The tests are distinguished between coverage tests and integration tests. While the former are meant to target what is commonly referred to as unit tests, the latter are meant to test more complex scenarios, involving actual repository actions, etc.

To execute all coverage tests use

on Linux

tox -e coverage-linux

on macOS

tox -e coverage-macos

To run all integration tests use

tox -e integration

Writing documentation

Documentation is written in reStructuredText and assembled using sphinx in the docs/ directory.

To build the documentation use

tox -e docs