Replace flake8 with ruff for linting and code style enforcement

[Borda]

🧾 Description

This PR replaces flake8 with ruff, a fast, modern Python linter that consolidates multiple tools into a single, streamlined solution.

✅ Why ruff?

• ⚡ Speed: ruff is written in Rust and offers lightning-fast linting — much faster than flake8, especially on large codebases.
• 🔧 Tool Consolidation: ruff covers functionality from several other tools, including:
  • flake8 (plus many of its common plugins)
  • black (code formatting)
  • pyupgrade (syntax upgrades)
  • isort (import sorting)
• 🧩 Consistency: With one tool managing style, linting, and even formatting, we eliminate potential conflicts and reduce maintenance overhead.
• 🔁 CI Simplification: Fewer moving parts in the linting pipeline — one config, one command, less to debug.

🔄 Changes

• Removed flake8 and its plugins from dependencies and CI setup.
• Added ruff and configured it to match our previous linting behavior.
• Updated development and linting documentation accordingly.

📌 Next Steps

• Evaluate enabling ruff format to fully replace black, allowing a single tool to manage formatting and linting seamlessly.

cc: @sirosen @edgarrmondragon

[sirosen]

ruff is not strictly superior to these other tools, although many people act as though it is. I have been burned in the past by taking a contribution to do this on another project without proper evaluation and had to switch back.

I consider ruff's lack of a plugin framework to be strict blocker. I'm the author of flake8-typing-as-t and use it in this project and several others. As far as I know, ruff has no such rule.

I also have written my own autofixer (slyp) for rules which we found useful at my work, and haven't thoroughly tested it against ruff to ensure there are no conflicts. In fact, given how configurable ruff is (a downside of it, IMO), I haven't even made time to evaluate it and ensure that slyp can behave in a compatible way.

Although I am theoretically open to using ruff, especially in projects which are already using it, I consider this PR dead on arrival without a prior discussion and agreement to use the tool. I feel so strongly about this that I'm closing it. We can reopen in the future if that seems appropriate.

[Borda]

I consider this PR dead on arrival without a prior discussion and agreement to use the tool. I feel so strongly about this that I'm closing it. We can reopen in the future if that seems appropriate.

no problem let's keep it dead, just for your info flake8 was not catching all issues but who cares :)

[sirosen]

just for your info flake8 was not catching all issues

I reviewed the changeset in response to this, to see what the issues were -- i.e. where flake8, slyp, or other tooling could be improved.

I see none which I would characterize as "issues" -- rather, I see differences. I don't consider it necessarily an improvement to defer all imports under a TYPE_CHECKING block which can be deferred, for example.
There's one case of a chained exception which is a minor improvement in the general case, but is actually intentional since check-jsonschema has a behavior in which it prints chained exceptions (so controlling the chain is how we produce desirable output).

I also note that you can't see the things which ruff wouldn't detect but which are already correct in the code, so this kind of one-way comparison isn't fully valid as a way of evaluating these tools.