As far as I can tell, there isn’t any configuration for a static analysis tool for the python code. Tools like ruff detect a lot of issues in klippy/, some of them irrelevant and some potentially dangerous.
I’m willing to be the main driving force and contributor, following a plan similar to this:
Derive a list of unique issue codes when running ruff with the default config
Decide which warnings/errors are worthwhile and which are irrelevant
Open a PR for each worthwhile warning/error
Derive a list of unique issue codes when running ruff with --include ALL
repeat step 2
repeat step 3
write a ruff.toml which ignores the irrelevant rules discussed in steps 1 and 4
integrate ruff as a CI step/github action/pre-commit hook
Thanks. I’m not familiar with that tool. I guess the main question I have is - what kinds of errors does it find on the current code?
If it can reliably find “real” errors than I think it could have value adding it to Klipper’s regression test suite. (By “errors” I mean catching real-world faults that could occur during run-time.) We’d then need to evaluate the balance between false-positives and actual found errors.
However, if it reports on indentation or “style issues” than I’m not, personally, interested in it. As, in my experience, chasing a particular coding style leads to unnecessary code churn that complicates merges and can introduce subtle errors.
If I understood Kevin correctly, the real question is, whether the majority of identified issues are “stylistic noise” or real errors that would need attention.
This is the current code base and around 30% are “Multiple imports on one line”.
What are real issues and what might just be “sloppiness” or unneeded is beyond me to judge.
Edit:
If you want to drill down even further, it results in:
I’m aware that not all “errors” (and especially not all “errors” reported by --select ALL) are useful.
I fully agree that things like “multiple imports on one line” can be safely ignored and added to the config file’s ignore list.
My intention was to start this process without using --select ALL specifically to make the introduction easier. And I’m not proposing the sudden introduction of ruff as a blocking step in CI.
Dropping a “ruff.toml” in the project’s root will have no effect on those that don’t explicitly run it or have it in their editor configuration.
But back to the basics, this, as a whole, is a python 3 project, right? Is it a specific version of python 3? It should be included in the config as well.
The shared spreadsheet and the graph above have just been run without any command line options.
I just played around with it out of pure interest.
As far as my understanding goes, Klipper currently is still maintaining Python 2 backwards compatibility, as many installations and even the default installation procedure in the documentation is still based on Python 2.
But for a final call and for the rest of your questions, @koconnor is the relevant authority to answer them.