A lot of cookiecutter template designers try to include all the things from
the start and then due to maintenance burdens, the package fall behind with the
moving ecosystem. For example, one of the most commonly used packages,
cookiecutter-pypackage has, at present moment, not been updated for a year
and has 23 open change requests.
This template is about moving with the ecosystem to provide a modern and
up-to-date cookiecutter template for creating Python packages. In order to keep
up to speed, I focus on tooling configuration rather than code customisation.
Your Python package code can be different each time but the tools should be
standardised and reliable.
Make no assumptions about the Python package code (different every time)
Use standardised tooling for packaging and dependencies (setuptools, twine).
Use best-in-class tooling for testing (tox, pytest, coverage)
Use best-in-class tooling for documentation (sphinx, towncrier, reStructuredText, readthedocs)
Use best-in-class tools for quality assurance (flake8, isort, mypy, black)
Use best-in-class community financial funding platforms (Liberapay)
Use community and maintenance aids (CoC templates, issue templates)