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.
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!
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.
the inline tests / class documentation via classvars is a very neat idea! did you come up with that for fixit or is it a common pattern i just happen to not have encountered before?
It's a pattern that I have used multiple times in the past, and greatly appreciate for modular components like this, but in this specific case, this was the pattern used by the original authors of Fixit 1, and I was very happy to maintain and improve upon that during the redesign.
The user guide has a short section on writing custom rules [1], and the API reference also covers the attributes of a LintRule [2]. I plan to document this in more detail at some point in the future.
Good catch, looks like a mixup somewhere in the writing/editing/publishing pipeline. The correct examples are given in the user guide [1], and I'll see if we can get the post updated accordingly. Thank you!
