4 ms·

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

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 6y 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 6y 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.
  - rikatee 6y ago
    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"
rikatee 6y 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 :)
- bluntfang 6y 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.
  - rikatee 6y ago
    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.
    - bluntfang 6y ago
      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.
- nickjj 6y 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.
  - rikatee 6y ago
    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.
kvalekseev 6y ago
I wrote https://github.com/kalekseev/django-extra-checks 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.

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 6y 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 6y 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.
- rikatee 6y ago
  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"

rikatee 6y 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 :)

bluntfang 6y 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.
- rikatee 6y ago
  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.
  - bluntfang 6y ago
    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.
nickjj 6y 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.
- rikatee 6y ago
  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.

kvalekseev 6y ago

I wrote https://github.com/kalekseev/django-extra-checks 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.