Show HN: A Django code review bot for GitHub pull requests

Which is a pretty standard arrangement for SaaS dev tools that I think makes it pretty clear your data isn't the business model. What I like about that model it is a reasonable balance of customers actually paying for the thing they use (so the business owner isn't beholden to advertising or tempted to abuse data access), and supporting the open source community (without which most of the modern web couldn't exist). I won't say it's entirely without risk - you need enough paid use to cover the costs of the open source use. But I think it's an ethical and sustainable approach if you can achieve that.

And, again, restyled is open source - if you don't trust the owner, you can run it yourself.

btw, we dont actually have any of the user's data. We literally do not have a user database. All we have is a link to a public repo. It currently works only on public repos. So no danger of Django Doctor doing anything odd with your code because the code is already public. No risk of Django Doctor doing anything strange with your personal data because we don't have any :)

The only reason you'd release a tool like this as a github integration and not an open source library (optionally with a CLI tool) is that you want to get money from it - nothing wrong with that, but that is very much an either/or question.

Sure, configuration management is hard, it doesn't mean you don't have to do it. If anything, in an organization that big, you should have someone creating a process for managing dependency upgrades. There will always be critical security vulnerabilities and other use cases for package upgrades that need to be patched across all of your repos.

I see manually updating libraries as a feature that allows for deterministic linting.

I wouldn't want my linter to always be updated to the latest version because that might introduce warnings or deprecation errors that aren't warnings or errors in the version of the tools used in the code I'm linting.

The closest to existing tools are: https://github.com/lamby/django-lint/ https://github.com/PyCQA/pylint-django

but- you have to set those up yourself in a CI and update them manually and not have the cool feature like PR integration, "fix it for me" (you would have to fix it yourself like a barbarian), the slick companion website with the beautiful blue progress bar :)

With Django Doctor you just click "install on GitHub" and boom, you get updates at no effort, and if you like the suggestion Django Doctor makes you just click commit

From chatting to folks, most applications just YOLO this, and accept downtime on every such DB operation; you might not even notice that this is happening at first because you'd need to have a create _during_ your DB migration. It'll bite you sooner or later though. I'm sure for many apps a client-side retry is totally acceptable, assuming it's safe to do so.

The idea that empty string and none are equivalent is distasteful.

Nobody makes this argument for int fields right? "Just use 0"?

I hate having different conventions for different field types and losing a potentially meaningful distinction between empty string and 0.

The idea seems to be born out of truthy & falsey values. (A big source of gotchas and bugs in my experience)

I'd say it's the role of django forms to clean data into a normalized form. So converting null to empty string there might make sense.

For example, I have a project where I pass back CI info to a slack channel so the dev can look at things easy and go to relevant links based on the notification.

If I was committing a feature branch and DD had a suggestion it would be fine to know at time of commit.

I agree it shouldn’t make it commit changes in this workflow, though. Just point them out.