How to contribute?¶

Some recommended packages for Python development¶

pytest: Run pytest in the main folder of the repository to run all test_*.py files
pylint: Scan your code for naming conventions and proper use of Python
rope: Python refactoring tools
sphinx: Generate documentation of your Python package
doc8: A style checker for reStructuredText

These packages and more can be installed using the requirements-dev.txt file:

pip install -r requirements_dev.txt

Conventions¶

Try to keep test coverage high. You can test current coverage by running

cd tests
pytest

Note that we navigated into the tests directory first as to avoid testing the files in the source code directory.

You can generate and view a report of the unit test coverage by running:

cd tests
pytest \
  --cov-config=.coveragerc \
  --cov-report=html \
  --cov=expertsystem

and opening htmlcov/index.html.

Git¶

Please use conventional commit messages: start the commit with a semantic keyword (see e.g. Angular or these examples, followed by a column, then the message. The message itself should be in imperative mood — just imagine the commit to give a command to the code framework. So for instance: feat: add coverage report tools or fix: remove ....
In the master branch, each commit should compile and be tested. In your own branches, it is recommended to commit frequently (WIP keyword), but squash those commits upon submitting a merge request.

Python¶

Follow PEP 8 conventions.
Any Python file that’s part of a module should contain (in this order):

1. A docstring describing what the file contains and does, followed by two empty lines.
1. A definition of __all__, so that you can see immediately what this Python file defines, followed by two empty lines.
2. Only after these come the import statements, following the PEP 8 conventions for imports.
When calling or defining multiple arguments of a function and multiple entries in a data container, split the entries over multiple lines and end the last entry with a comma, like so:

This is to facilitate eventual diff comparisons in Git.

Visual Studio code¶

We recommend using Visual Studio Code as it’s free, regularly updated, and very flexible through it’s wide offer of user extensions.

If you add or open this repository to/as a VSCode workspace, the .vscode/settings.json will ensure that you have the right developer settings for this repository.

You can still specify your own settings in either the user or encompassing workspace settings, as the VSCode settings that come with this are folder settings.