If you start working on a new feature or a fix, please create an issue on
GitHub shortly describing the issue and assign yourself.
Your startpoint should always be the
develop branch, which contains the
Create an own branch or fork, on which you can implement your changes. To get your work merged, please:
create a pull request to the
developbranch with a meaningful summary,
check that code changes are covered by tests, and all tests pass,
check that the documentation is up-to-date,
request a code review from the main developers.
If you contribute to the development of pyPESTO, install developer requirements via:
pip install -r requirements-dev.txt
This installs the tools described below.
Firstly, this installs a pre-commit tool. To add those hooks to the .git folder of your local clone such that they are run on every commit, run:
When adding new hooks, consider manually running
pre-commit run --all-files
once as usually only the diff is checked. The configuration is specified in
Should it be necessary to perform commits without pre-commit verification,
git commit --no-verify or the shortform
For automatic continuous integration testing, we use GitHub Actions. All tests
are run there on pull requests and required to pass. The configuration is
To make pyPESTO easily usable, we try to provide good documentation, including code annotation and usage examples. The documentation is hosted at pypesto.readthedocs.io and updated automatically on merges to the main branches. To create the documentation locally, first install the requirements via:
pip install .[doc]
and then compile the documentation via:
cd doc make html
The documentation is then under
Alternatively, the documentation can be compiled and tested via a single line:
tox -e doc
When adding code, all modules, classes, functions, parameters, code blocks should be properly documented.
For docstrings, we follow the numpy docstring standard. Check here for a detailed explanation.
Unit tests are located in the
test folder. All files starting with
test_ contain tests and are automatically run on GitHub Actions.
Run them locally via e.g.:
tox -e base
base covering basic tests, but some parts (
being in separate subfolders. This boils mostly down to e.g.:
You can also run only specific tests.
Unit tests can be written with pytest or unittest.
Code changes should always be covered by unit tests. It might not always be easy to test code which is based on random sampling, but we still encourage general sanity and integration tests. We highly encourage a test-driven development style.