I tried getting used to cookiecutter with one of the well-known Python project templates several times, but I always found that those are way too much boilerplate for my simple needs.

So I stick with copying and modifying my previous project every time, and even that doesn't make things much easier because I always find something I should do different next time, so in the end no project is completely like its predecessor.

Let us know what you'll come up with!

test comment

Package DevOPs is a skill. Half assing it will not:

• impress a published package author's peers

• encourage confidence in the authors perseverance to maintain the package

• encourage confidence in the author's willingness to politely respond to Issues and PRs

• package will have issues that never get resolved cuz the author packaging skillset is woefully lacking including but not limited to: Makefile, pre-commit, tox, gha, doctest, documentation, test coverage, multiple platform support, manylinux support, setup for collaboration, and static typing.

So suggest redirecting efforts towards studying how to improve packaging rather than how to avoid packaging.

A suggestion on things to improve documentation:

move the doctest out of in-code documentation and into test suite! So the doctest are proof and contribute to coverage

python -m coverage run --parallel --data-file=.coverage-combine-tests -m pytest --doctest-glob="*.rst" --showlocals $(verbose_text) tests/safe tests/a tests/b

This is straight from a Makefile. Where the file extension for doctest was changed to .rst. Can see have A B testing setup to compare two packages.

Example how to include doctest into Sphinx document

.. literalinclude:: ../tests/a/test_presentation.rst
    :language: pycon
    :name: unique-id
    :caption: illustrative-description