Using the following tools:
- Testing: pytest
- Building: flit
- Documentation: sphinx, readthedocs
- Publishing: TestPyPi, Github Actions
Inspired by projects from Marvin Friede and Martin Buttenschoen.
The most important configuration options for everything are found in the pyproject.toml-file.
Following convention, the code for the package example_package_samuelhomberg lives at src/example_package_samuelhomberg/ and the corresponding tests at test/. Whyle pytest is used for testing, the actual tests are written using the unittest package. The code and tests are of no further importance.
The documentation is configured (path to code, theme, logo and favicon, ...) in docs/source/conf.py.
Documentation was written using sphinx and the project the registered at readthedocs for automatically updating documentation.
I followed this guide to build a package and manually uploaded it to PyPi (or in this case, only to TestPyPi). The building backend flit relies on the configuration in pyproject.toml and can dynamically load the version number and short project description.
The workflows configuring the github actions are found in .github/workflows/.
This is done using the test.yml workflow. As of now, the tests are not really automated but manually triggered (see Future Improvements).
This is done using the publish_release.yml workflow, which is heavily based on the guide found here. This workflow is also manually triggered. To still have version numbers for the GitHub Release, get_version.py script saves a file with the version, which can is used in the workflow. As before, it would be better to switch to a tagged release scheme (see Future Improvements).
- Instead of using manually controlled workflows (
workflow_dispatch), it would be better to have a complete [build -> test -> publish -> release] workflow tied to tagged commits, as in this example using${{ github.ref_name }}. However, automatic releases apparently create tags with version numbers.