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

https://django.doctor/?show-hn

by rikatee • 6 years ago

105 63 6 years ago

django.doctor

rikatee25• 6 years ago

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/

rglullis2• 6 years ago

Is this based on some Django linter tool or some kind of plugin I am not aware of?

rikatee25• 6 years ago

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

scrollaway• 6 years ago

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

mrlinx• 6 years ago

I'm not one to install these bots on the company repos. Is there a way to run this offline?

rikatee25• 6 years ago

Unfortunately not. It's aimed at SaaS so users gain some convenience but lose a bit of other things :)

rzodkiew• 6 years ago

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).

cameronh90• 6 years ago

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.

raziel2p• 6 years ago

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.

rikatee25• 6 years ago

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 :)

bluntfang2• 6 years ago

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.

nickjj• 6 years ago

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.

kvalekseev• 6 years ago

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.

wfleming2• 6 years ago

For anyone who likes the idea but doesn't use Django, check out https://restyled.io/ - it supports a bunch of tools [1].

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/

marcinzm3• 6 years ago

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).

richardARPANET2• 6 years ago

Walking across the street is also risky.

wfleming2• 6 years ago

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.

rikatee25• 6 years ago

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 :)

cosmic_quanta• 6 years ago

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!

iruoy• 6 years ago

These are all standard tools. Why wouldn't you just run them as part of your CI workflow?

rikatee25• 6 years ago

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 ;)

michaelmior• 6 years ago

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 :)

rikatee25• 6 years ago

Thanks for the feedback, and glad you found it useful :)

ninjapenguin542• 6 years ago

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.

swiley• 6 years ago

I hate things that get this wrong so much.

rikatee25• 6 years ago

I'm sorry swiley :'(

VWWHFSfQ• 6 years ago

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...

rikatee25• 6 years ago

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.

eli• 6 years ago

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.

theptip• 6 years ago

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.

ninjapenguin542• 6 years ago

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.

tmarice• 6 years ago

In most cases they are synonymous. If they're not, you are allowed to disregard the bot's suggestion.

rikatee25• 6 years ago

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

ivan_ah• 6 years ago

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.

rikatee25• 6 years ago

Glad to be of service :)

bredren2• 6 years ago

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.

rikatee25• 6 years ago

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!

bredren2• 6 years ago

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.

zachh• 6 years ago

This looks really great! Is there a privacy policy?

rikatee25• 6 years ago

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

Rotten194• 6 years ago

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?

rikatee25• 6 years ago

I'm working on private repo support. chat with me at django.doctor if you want to get in on the private beta

rikatee25• 6 years ago

We now support private repos :)

harel• 6 years ago

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.

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

Related Stories