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.
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 :)
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 ;)
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).
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.
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 :)
>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.
> 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 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.
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
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.
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.
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.
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
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.
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?
Readit News
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/
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.
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 :)
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.
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/
https://django.doctor/dj-stripe/dj-stripe
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
> 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...
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.
Deleted Comment
Soon we will be adding a config file so you can mute the things that ar vexatious
Also suggested reordering of methods within the class, which could be a nice convention to follow for large projects.