Show HN: Django Keel – 10 Years of Django Best Practices in One Template

But Keel is based on copier which has a "pull" based approach. It means unlike cookiecutter where you generate project from template once, you can run `copier update` to update your project with the latest addition to the template. (It takes care of merging based on the initial config that you selected).

It's just running one command `copier update`. Docs here: https://django-keel.readthedocs.io/en/latest/?h=copier+updat...

You don't need to fork it unless you want to make some improvements or build upon the base template itself.

If you end up adding anything, you may also choose to give back to the template so that others can use it.

I do not understand what you meant by "ty", though?

I've chosen copier because of all the pain I've gone through for years just to keep my template and projects running in parallel updated.

Also, to answer why ever be less than 100% is that it depends. Usually, I prefer writing behavioural & integration tests, over chasing per-line coverage which might give a false confidence.

I'm not saying getting 100% coverage is bad, but with my experience working on several different projects, I've seen that the last 10-20% is usually low-value surface.

For critical modules like auth, money, policies (business-logic), should aim at close to > 95%.

When you reach that 100% mark, in my opinion, you might have to write brittle tests which slows down your refactoring with little risk reduction.

Again, to summarize, it's not a black/white answer on having 100% or no coverage, but this differs from project to project, and generally having anything above 80% that covers the core-business logic of projects tends to work in my opinion.

I have also added temporal (though still testing it) since it's getting a lot popular these days.