Live data from Hacker News

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

github.com

21–30 of 32 posts

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

#21

> pytest - Comprehensive test suite (80% coverage minimum) Why would this ever be less than 100%?

It's configurable. The minimum quality gate check is set at 80% here: https://github.com/CuriousLearner/django-keel/blob/main/temp...

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.

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

#22

> pytest - Comprehensive test suite (80% coverage minimum) Why would this ever be less than 100%?

It's configurable. The minimum quality gate check is set at 80% here: https://github.com/CuriousLearner/django-keel/blob/main/temp... 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…

It was not at all clear to me that number was for code coverage. It sounded like it was permitting up to 20% of tests to be failing.

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

#23

Earlier quoted context omitted.

It's configurable. The minimum quality gate check is set at 80% here: https://github.com/CuriousLearner/django-keel/blob/main/temp... 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…

It was not at all clear to me that number was for code coverage. It sounded like it was permitting up to 20% of tests to be failing.

Interesting. Do you have any opinion on what this should be rephrased to, so that it's clearer?

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

#24

Earlier quoted context omitted.

It was not at all clear to me that number was for code coverage. It sounded like it was permitting up to 20% of tests to be failing.

Interesting. Do you have any opinion on what this should be rephrased to, so that it's clearer?

Explicitly say code coverage or lines of code?

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

#25

As someone who up to now has mainly watched Django from the sidelines, as it were, this looks great. What's are your plans for supporting Django v6? (I appreciate it's just gone alpha now, and planned prod release is not for two months.) Likewise for Python 3.14.

Happy to let you know that I've just updated the template to use Python3.14 by default, along with matrix tests that also tests the template against Python 3.14 in here: https://github.com/CuriousLearner/django-keel/commit/87eae7e...

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

#26

encountered this post in reddit maybe an hour ago. the comment sections are very different. i'm gonna stick with HN for sure. good project though. using copier instead of cookiecutter is a good choice.

It was all great on Reddit, though until some folks decided to downvote for no apparent reason and then deleted their accounts. 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.

one small note, you should move quick start section in README to be seen earlier

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

#28

Earlier quoted context omitted.

Interesting! I've loved Strawberry GraphQL. 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 think it's ty the typechecker :D https://docs.astral.sh/ty/

Thanks, this seems interesting!

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

#29

Earlier quoted context omitted.

It was all great on Reddit, though until some folks decided to downvote for no apparent reason and then deleted their accounts. 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.

one small note, you should move quick start section in README to be seen earlier

Thank you for your suggestion. I'll update the README so that people can hit the ground running faster!

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

#30

Nice. Batteries included for major frameworks is always great.

Yes, I maintained a cookie-cutter template for over a decade, and it was a pain for me to get it updated. I wanted to get something newer, like a copier, which eliminates the pain of updating, while I can focus on building things.

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

Post reply on HN