3 ms·
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
by ak217 2y ago
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.
- zahlman 2y agoI'm confused: why are you linting code in CI, rather than as a precommit hook?
- ak217 2y agoPre-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.
- zahlman 2y ago... am I the only one who figures that linting would logically be a very low priority in those circumstances?
- OrderlyTiamat 2y agoApparently so. Mind explaining your reasoning?
- kstrauser 2y agoBecause 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?”
- sunshowers 2y agoWell, 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.
- goku12 2y agoDepends 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.
- sunshowers 2y agoMy 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.
- wiredfool 2y agoBecause 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.
- zahlman 2y agoMy 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?
- orra 2y agoAhah! 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.)
- greatgib 2y agoCan 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.
- deleted 2y ago[deleted]