Hacker News Reader

Comment by ak217 | Hacker News Reader

I don't know what kinds of codebases you've worked with, but I can tell you that pylint is so far from instant, it became the longest running CI job in multiple reasonably sized codebases I've worked with. Think tens of minutes. Other linters were not much better, until ruff came along. But that's far from the only advantage that ruff brings.

There are other issues with what you said, but the biggest one is: you have some strongly worded criticism for a project that has set a new bar for usability and consistency in Python code quality tooling. These tools are developed by humans like you and distributed to you for free with no obligation to use them. No matter how I look at your comment, I don't see how it's helping.

View on HN

Can you tell us a little bit more about your codebase? I'm curious. Because for it to take tens of minutes, something should be crazy over there.

I'm confused: why are you linting code in CI, rather than as a precommit hook?

Pre-commit hooks are great in small, focused codebases with small, homogeneous teams. In large monorepos with lots of different teams committing, it's impossible to guarantee any kind of consistency in which pre-commit hooks get run, so you need CI to actually enforce the consistency or you'll spend all your time chasing (accidental) violations.

... am I the only one who figures that linting would logically be a very low priority in those circumstances?

Apparently so. Mind explaining your reasoning?

Because devs can disable precommit hooks much more easily than they can work around CO.

I see precommit hooks as where you avoid the low-hanging fruit, like “is this code actually parsable?”

Well, for one, I use Jujutsu, where commits happen every time you run jj status and traditional notions of pre-commit hooks don't really apply. But also, I think (as a matter of principle) nothing should get in the way of performing commits or amends.

Depends on what you're trying to achieve. Jobs like lint checks should ideally be pre-push checks so that the long process doesn't get in the way of commits. But very fast and small checks like warning about trailing whitespaces or ensuring a newline at the end of the file can be done during every commit (even if it was in jujutsu). I would rather not wait till the end to find out. And of course, there are ways to temporarily or permanently disable one or more checks when you absolutely need it.

My editor takes care of trailing whitespace and newline termination. I don't think Jujutsu commits should fail on this or fix it every time jj status is run — seems too magical.

Because commits should be small and fast, and always work, like a save. If you’re running a multi second process during commit it’s going to get ripped out.

Ahah! I worked on a project which used dotnet format in a commit hook. That was a frustrating experience, trying to rebase code.

(Unlike most formatters which are instant, dotnet format takes at least half a minute, because it performs a build just to format your code.)

My thinking is that the linter only has to operate on the code that was actually checked in. And just how many things are you checking about it, anyway?

Reply on news.ycombinator.com