Show HN: A Django code review bot for GitHub pull requests(django.doctor)
django.doctor
Show HN: A Django code review bot for GitHub pull requests
https://django.doctor/?show-hn
64 comments
Sending all your code to a free third party tools seems risky to me. Any entity without a currently working business model but your data (or access to your systems) is going to be very tempted to abuse that access for money. Maybe not now but down the line after it gets sold to a sketchy Russian company (like a lot of browser extensions).
I don't think this critique applies to restyled - it's free for use on open source repos, but costs money for private repos.
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.
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.
Our business model will soon become clear: oranisations will pay. Individuals not. Currently still ironing out things and seeking feedback so at the moment free to all so I can get maximum feedback :)
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 :)
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 :)
If I was still actively working on Django projects, probably would be willing to pay. Value seems fairly clear and proof of value would be straightforward to evaluate.
When I worked on solo projects, sanity checks like these would be very helpful since you don’t have a teammate to help spot “brain fart” situations.
When I worked on solo projects, sanity checks like these would be very helpful since you don’t have a teammate to help spot “brain fart” situations.
Thanks! Even the simple "Syntax Error" comment could be the difference between bed time and another cup of coffee.
Walking across the street is also risky.
This is more like walking across the street blindfolded for no good reason. You can run similar tools locally or hosted yourself or open source.
edit: Or even a paid alternative as those at least seem to have a business model.
edit: Or even a paid alternative as those at least seem to have a business model.
in the case of Django Doctor - there is no direct alternative you can run locally. Nothing else does this:
- finds Django anti patterns. pretty sweet.
- suggests the fix in the PR. One click fix? yes pls.
- Check your entire codebase in seconds via https://django.doctor with no need to install or sign up for anything? hell yeah.
- has a fox as a mascot
- finds Django anti patterns. pretty sweet.
- suggests the fix in the PR. One click fix? yes pls.
- Check your entire codebase in seconds via https://django.doctor with no need to install or sign up for anything? hell yeah.
- has a fox as a mascot
If you don't value your time, sure.
I just want to say that I studied the restyled.io source code (https://github.com/restyled-io/restyled.io) when learning how to build a Haskell web app. Great stuff!
Nice! They're quite different beasts though. Restyled enforces code style, while Django Doctor suggests fixes for Django specific anti patterns and has a fox for a mascot. See. Completely different ;)
These are all standard tools. Why wouldn't you just run them as part of your CI workflow?
I'm probably old fashioned, but I don't understand why would I want something like that as a web-service, rather than something I can run locally (like all the js linters or rubocop).
It's not either/or. We use them in case a developer forgets to run them, or hasn't set their environment up properly or similar.
That's why you make it part of the CI pipeline and require it to pass before merging, making it impossible to forget.
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.
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.
Blocking the build works well for things that are boolean "correct" or "not correct", but some things are not are just "food for thought". Django doctor points out when something looks like it can be improved, but that's ultimately up to the dev to take the advice. It's "have you thought of..." rather than "you must do this".
With the advantage that if the dev likes the advice, all they need to do is click "commit"
With the advantage that if the dev likes the advice, all they need to do is click "commit"
I've been in a few organization with hundreds of repos. It can be a pain to upgrade libraries. In this context, with SaaS you don't need to.
But yes, SaaS is not a silver bullet. If you like convenience and getting updates, bug fixes, and quick set up with no overhead then it's for you. If you want to run things yourself then understandable have a great day :)
But yes, SaaS is not a silver bullet. If you like convenience and getting updates, bug fixes, and quick set up with no overhead then it's for you. If you want to run things yourself then understandable have a great day :)
>I've been in a few organization with hundreds of repos. It's can be a pain to upgrade libraries.
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.
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.
In general I agree, but specifically for this: It does mean you don't have to do it _for this particular feature_. If we can "reduce hard" then that's a good thing. It's one less configuration to manage.
But if you have to do it sometimes, and you're proactive about process and automation, not only is this good practice for quickly patching security vulnerabilities, it will help you solidify your configuration management processes and automation, because at the end of the day, you're going to have to do it.
The suggestion that you don't have to do it for this particular feature is kicking the can down the road.
The suggestion that you don't have to do it for this particular feature is kicking the can down the road.
> It can be a pain to upgrade libraries. In this context, with SaaS you don't need to.
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.
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.
Agreed in general, but Django Doctor is not a linter. It suggests code improvements the dev can choose to commit with one click. Linters block builds until the code conforms to a pre set style, often requiring the dev to manually do it themselves. Django Doctor gives "food for thought" that the dev can follow or ignore.
The same can be said for a linter. You can just ignore the lint warning and have it not block the build as well.
Most linters also don't require manual changes but do automatic fixing, ie: black[0].
Non-user initiated updates to QA tools will only lead to alert fatigue because people will write it off as an update to to tool.
[0] https://github.com/psf/black
Most linters also don't require manual changes but do automatic fixing, ie: black[0].
Non-user initiated updates to QA tools will only lead to alert fatigue because people will write it off as an update to to tool.
[0] https://github.com/psf/black
Maybe I'm grandiose but I see the "form factor" as key: MP3 players existed before ipods. Some people found the new form factor more convenient.
Similarly they way Django Doctor works is more convenient:
- it's suggests a change that can be applied in one click - it's suggestion can be ignored - no overhead cost because it's SaaS
but yes, if you don't value SaaS in this context then that's fair enough :)
Similarly they way Django Doctor works is more convenient:
- it's suggests a change that can be applied in one click - it's suggestion can be ignored - no overhead cost because it's SaaS
but yes, if you don't value SaaS in this context then that's fair enough :)
It might be because I'm old fashioned and come from a terminal background (you kids with your MP3's, I'll stick with tapes). But for me the SaaS is the overhead. Moving away from my terminal and local dev environment. Waiting for web requests to return before I can continue really breaks my workflow. Also the idea that formatting and other coding standards are not decleratively enforced (and autofixed) but an arbitraty choice during review has become strange to me over the past few years. As with Black for example. Every choice about formatting can be premade and automatically applied by a computer. This saves so much time in the review process. No bike-shedding about tabs or spaces. Just conform to one autoformatted standard and optionally convert it to your local preference (and back) in your IDE/Git-hooks.
That said, if you live in Github and other SaaS services this fits really well. In the past I've setup similar workflow to cater to people who never dared to touch a terminal or Git itself. So there is certainly enablement this tool brings to some people.
That said, if you live in Github and other SaaS services this fits really well. In the past I've setup similar workflow to cater to people who never dared to touch a terminal or Git itself. So there is certainly enablement this tool brings to some people.
That's good insight, thanks :)
I wrote https://github.com/kalekseev/django-extra-checks that do exactly this using builtin django checks framework, it has a couple of drawbacks though:
1) Django checks doesn't provide a good way to disable checks for some lines.
2) Parsing AST is quite slow and django check runs on every dev server reload.
Django Doctor suggests code improvements in your pull requests, so you get better code with no extra effort.
What will Django Doctor say about your code? Check now for free at https://django.doctor
If you dig this then you may like to install the bot on your GitHub pull requests
https://github.com/marketplace/django-doctor/
What will Django Doctor say about your code? Check now for free at https://django.doctor
If you dig this then you may like to install the bot on your GitHub pull requests
https://github.com/marketplace/django-doctor/
Ran it on a repo of mine, looks like it thinks TextField is the same as CharField in some cases:
https://django.doctor/dj-stripe/dj-stripe
https://django.doctor/dj-stripe/dj-stripe
Is this based on some Django linter tool or some kind of plugin I am not aware of?
Nope, all 100% pure custom code.
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
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
Call me weird, but I would be more willing to support it if it was an open source system that I could control.
Empty string and none are not the same or in any way redundant.
Linters belong in ci. Humans belong in code review.
I can actually explain to a human why my text field has a default of none.
It's a code-smell in Django, but I agree that this kind of thing shouldn't be "auto-fixed" by a bot. There are perfectly valid reasons why you might want to eschew the convention.
> Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;” the Django convention is to use the empty string, not NULL. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True is required to avoid unique constraint violations when saving multiple objects with blank values.
[0] https://docs.djangoproject.com/en/3.1/ref/models/fields/#nul...
> Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;” the Django convention is to use the empty string, not NULL. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True is required to avoid unique constraint violations when saving multiple objects with blank values.
[0] https://docs.djangoproject.com/en/3.1/ref/models/fields/#nul...
Perhaps I need to clarify "auto fix" - the dev still needs to click "commit" on the suggestion. Given a PR with 3 Django Doctor suggestions, 2 could be ignored and only 1 committed by the dev if they choose.
Unfortunately it's tricky to add new fields in a zero-downtime fashion without making them nullable. Django does not store defaults in the DB (this is surprising, and the opposite of the Rails approach), and this means that if you upgrade your DB first, until you've upgraded your application all writes to your model are going to fail because the (down-level) application code doesn't know it has to specify the (up-level) DB field.
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.
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.
If anyone would like to read more on the topic I wrote a blog post that includes this point and others: https://djangodoctor.medium.com/the-real-difference-between-...
because while Django Doctor suggests potential improvements, I acknowledge they're not guaranteed to be correct according to the context
because while Django Doctor suggests potential improvements, I acknowledge they're not guaranteed to be correct according to the context
I've read the django docs. It's dumb advice parading as "best practice".
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.
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.
Sure, but if it's outside the usual convention it should be explained with a comment. The comment can also include a command to tell the linter to ignore it.
[deleted]
Bear in the comments are "food for thought" and aren't aimed at blocking merge. In the review you can pick which suggestions you want and can ignore the stuff that does not add value to you.
Soon we will be adding a config file so you can mute the things that ar vexatious
Soon we will be adding a config file so you can mute the things that ar vexatious
In most cases they are synonymous. If they're not, you are allowed to disregard the bot's suggestion.
I've been using it for a while and it works really well. It manages to be helpful and not annoying, which is a fine line to tread.
This is pretty good. Found some "Nullable but not blank=True" errors which were hidden because using mostly as an API, but would have had to fix to use the Django admin or forms.
Also suggested reordering of methods within the class, which could be a nice convention to follow for large projects.
Also suggested reordering of methods within the class, which could be a nice convention to follow for large projects.
Glad to be of service :)
Is it possible to use on a private repository? It says "Free for public repositories" but I can't find any information about a non-free option, the github page seems to only list the free tier. Is it not available yet?
Might be nice to have option to use this as a service backing a GitHub Action.
Sort of an extra checking step to my CI.
Sort of an extra checking step to my CI.
Your wish is granted kind of: https://github.com/marketplace/django-doctor/
It's a github app, rather than an action. Actions still require you to update a yaml file to use.
Regarding CI: I don't think Django Doctor should block or fail builds. Django Doctor looks suggests improvements, but it's up to the dev to decide to commit them. Plus, no bot should be commiting changes without dev approval. Hello Skynet!
It's a github app, rather than an action. Actions still require you to update a yaml file to use.
Regarding CI: I don't think Django Doctor should block or fail builds. Django Doctor looks suggests improvements, but it's up to the dev to decide to commit them. Plus, no bot should be commiting changes without dev approval. Hello Skynet!
I saw it is an app, though I don’t see a problem with being able to lint feedback / warnings using an action.
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.
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.
I think it would help to somehow edit the title to add that this is exclusive to Django. Looks cool though! Gave some reasonable suggestions for one of my projects :)
Thanks for the feedback, and glad you found it useful :)
This looks really great! Is there a privacy policy?
There will be shortly.
In summary: - we dont' collect ANY personal data because we don't need ay. we don't even have a database, We can't misuse your persona data if we don't have it!
- we don't create any non-essential cookies on browser
- your code is deleted as soon as it's checked
- the servers are hosted in USA/London
In summary: - we dont' collect ANY personal data because we don't need ay. we don't even have a database, We can't misuse your persona data if we don't have it!
- we don't create any non-essential cookies on browser
- your code is deleted as soon as it's checked
- the servers are hosted in USA/London
It's also open source and self-hostable for folks who like the idea but don't trust that automation to a third party.
[1]: https://docs.restyled.io/available-restylers/