I love templates with CookieCutter or in the front-end world, really nice tooling like create-vue. However I wouldn’t use this particular template or recommend it for a few reasons:
Firstly, it’s using setup.py which has been mostly been replaced by pyproject.toml/setup.cfg.
It doesn’t use any pre-commit hooks for things like black or mypy.
It’s not using Poetry.
It’s not using type hints.
It may seem like overkill, but setting things like these up from the outset makes it much more likely to have a high quality codebase that is easy to work with. It’s something that the front-end tooling integrates so cleanly.
All that said however, these are just my personal preferences for the style of programming I enjoy, and to each their own! Keep making great tools however you like!
Seriously, though, I think there are some definite things I’d consider before adopting these as a base for all projects:
setup.py
Yeah, pyproject.toml/setup.cfg is the future, but saying it’s mostly replaced setup.py is an exaggeration. I consider it to be more “just past the bleeding edge and worth keeping an eye on now even if you aren’t an early adopter.” A significant number of projects are still on cpython versions that didn’t even ship toml in the stdlib.
pre-commit
I pretty strongly believe that 1. these should be per-developer, not per-project, and 2. pre-commit is the wrong time to do most of what gets put here anyway.
poetry
Might be worth it if your intent is to build a pip installable package, but that wouldn’t necessarily be my approach for many cli tool uses, and I feel like it’s overkill and not terribly pleasant to use for more “application” type projects.
I love templates with CookieCutter or in the front-end world, really nice tooling like create-vue. However I wouldn’t use this particular template or recommend it for a few reasons:
setup.pywhich has been mostly been replaced bypyproject.toml/setup.cfg.blackormypy.It may seem like overkill, but setting things like these up from the outset makes it much more likely to have a high quality codebase that is easy to work with. It’s something that the front-end tooling integrates so cleanly.
All that said however, these are just my personal preferences for the style of programming I enjoy, and to each their own! Keep making great tools however you like!
Yeah, I should update that one. I have a couple of recent ones which use
pyproject.tomlinstead:I wrote up more about
pyproject.toml(including how to use it without Poetry) here: https://til.simonwillison.net/python/pyprojectI’ve updated https://github.com/simonw/click-app to use pyproject.toml now. Example output here: https://github.com/simonw/click-app-template-demo/tree/968887d8
It’s too bad they’re all wrong! :P
Seriously, though, I think there are some definite things I’d consider before adopting these as a base for all projects:
Yeah, pyproject.toml/setup.cfg is the future, but saying it’s mostly replaced setup.py is an exaggeration. I consider it to be more “just past the bleeding edge and worth keeping an eye on now even if you aren’t an early adopter.” A significant number of projects are still on cpython versions that didn’t even ship toml in the stdlib.
I pretty strongly believe that 1. these should be per-developer, not per-project, and 2. pre-commit is the wrong time to do most of what gets put here anyway.
Might be worth it if your intent is to build a pip installable package, but that wouldn’t necessarily be my approach for many cli tool uses, and I feel like it’s overkill and not terribly pleasant to use for more “application” type projects.
ok, that one’s fair :)