undefined | Better HN

0 pointsamethyst2y ago0 comments

They are two linters with very different goals. Where Ruff prioritizes speed over all other concerns, and chooses Rust as the method of achieving that goal with a set of generic lint rules, Fixit is focused on making it easy for Python developers to write custom lint rules.

The use of LibCST (which has a parser written in Rust) makes it easy to build lint rules in Python. Fixit allows engineers to write local lint rules in their project repo with a minimum of boilerplate, and then immediately enable them, without needing to write custom plugins or packages, and without needing to rebuild or deploy a new version of Fixit. This lowers the barriers to writing rules, and provides a quick development and feedback cycle when testing them.

Hierarchical configuration allows Fixit to fit well into larger monorepos, with each team/project able to easily control what lint rules run on their code base. Open source projects homed in those monorepos also have tools to ensure that results are the same when running on internal vs external CI systems.

0 comments

2 comments · 1 top-level

lonelyOrca2y ago· 1 in thread

That's very helpful, thanks. Could you also perhaps comment on how the speed compares between the two? I imagine Ruff is faster, but not sure where Fixit 2 lies (order Pylint, flake8?).

Thanks again for working on this awesome project and contributing to the community!

amethystOP2y ago

At the moment, it's somewhere around pylint and flake8, depending on the number of lint rules running, but that's with no caching or performance optimization beyond per-file multiprocessing. I have plans for simple caching that should generally make Fixit faster than Flake8 with a warm cache, assuming that custom lint rules are reasonably performant. Fixit already has mechanisms for tracking time spent per rule, and we plan to make it easier to see which rules are the slowest in each run.

That said, I doubt it will ever achieve performance parity with Ruff, given that it's running Python code by design. But we also believe that offering targeted lint rules with auto-fixes more than makes up for time spent running linters by reducing the number of iterations spent during development, shortening code review, etc.

Eg, if there are common mistakes in a codebase that cause frequent rejections or extra iterations in code review, custom lint rules with auto-fixes can help catch — and fix — those mistakes before developers waste hours or days waiting for avoidable rejections.

j / k navigate · click thread line to collapse