[nickjj]

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

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.

[aequitas]

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

[rikatee]

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

[aequitas]

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.

[rikatee]

That's good insight, thanks :)