Contributing

If you find a bug, have a feature request or similar, feel free to submit an issue.

Contributing guidelines#

If you want to contribute to the development of the UPP, you should create a fork of the repository. You can read about forking workflows here, or take a look at the contributing guidelines in the training dataset dumper documentation.

You should make changes inside a feature branch in your fork. It is generally a good idea not to work directly on the the main branch in your fork. Then, when your feature is ready, open a merge request to the target branch on upstream (which will usually be main). Once this is merged to upstream, you can git pull upstream main from your fork to bring back in the changes, and then fork again off main to start the development of a new feature. If your feature branch becomes outdated with its target, you may have to rebase or merge in the changes from the target branch, and resolve any conflicts, before you can merge.

Remember to keep you fork up to date with upstream.

Code Formatting#

It's good practice to document your code with module and function docstrings, and inline comments. Consider also providing type hints for the function in/outputs. Code formatting and linting is handled by Ruff (both the linter and the ruff-format formatter), with mypy for type checks. All of these run automatically through the project's pre-commit hooks, so you don't need to invoke them by hand.

To format and lint your contribution, run the pre-commit hooks:

pre-commit run --all-files

You can also install the hooks so they run automatically on every commit:

pre-commit install

Testing#

It is highly encouraged to adhere to provide unit and/or integration tests for every new added feature. You can test your code and check the coverage using.

coverage run --source upp -m pytest --show-capture=stdout
coverage report