[CI] Linter and formatter

[adam-smnk]

Adds 'ruff' as Python linter and code formatter, and 'pre-commit' for easy rules application both locally and in CI.
New lint CI workflow is also added.

The formatting tools are added as optional dependencies.
They can be installed using:
uv sync --extra dev-tools
and locally run with:
pre-commit run --all-files

[adam-smnk]

The PR is split into two commits to make reviewing simpler.
The first one contains only the new linter infrastructure.
The second commit applies formatting to the repo.

Current lint config is a simple opinionated collection of rules.
Open to suggestions and changes. 🙂

[rengolin]

If a PR fails on formatting, is there an actionable thing for developers to do to fix the formatting without having to patch by hand every difference?

[rolfmorel]

If a PR fails on formatting, is there an actionable thing for developers to do to fix the formatting without having to patch by hand every difference?

Would be great to set it up as on llvm-project, e.g. llvm/llvm-project#146732 (comment) where a Github action comments something like

⚠️ Python code formatter, darker found issues in your code. ⚠️

You can test this locally with the following command:
darker --check --diff -r HEAD~1...HEAD mlir/python/mlir/dialects/transform/tune.py 
mlir/test/python/dialects/transform_tune_ext.py

View the diff from darker here.
--- python/mlir/dialects/transform/tune.py	2025-07-03 14:02:19.000000 +0000
+++ python/mlir/dialects/transform/tune.py	2025-07-03 14:05:57.797604 +0000
@@ -28,11 +28,11 @@
 
 @_ods_cext.register_operation(_Dialect, replace=True)
 class KnobOp(KnobOp):
     def __init__(
         self,
-        result: Type, # !transform.any_param or !transform.param<Type>
+        result: Type,  # !transform.any_param or !transform.param<Type>
         name: Union[StringAttr, str],
         options: Union[
             ArrayAttr, Sequence[Union[Attribute, bool, int, float, str]], Attribute
         ],
         *,
@@ -67,11 +67,11 @@
             ip=ip,
         )
 
 
 def knob(
-    result: Type, # !transform.any_param or !transform.param<Type>
+    result: Type,  # !transform.any_param or !transform.param<Type>
     name: Union[StringAttr, str],
     options: Union[
         ArrayAttr, Sequence[Union[Attribute, bool, int, float, str]], Attribute
     ],
     *,

and then on further revisions the comment is edited to become:

✅ With the latest revision this PR passed the Python code formatter.

Just need to find the right Github workflows to copy (and appropriately massage) from llvm-project/.github.

[rolfmorel]

On the topic of copying from llvm-project: I would prefer if we also just keep to whichever code style is being enforced upstream. Just need to dig around a bit to find the right files that specify it.

[rolfmorel]

As I now have more familiarity with pyproject.toml and uv than I would like: https://docs.astral.sh/uv/concepts/projects/dependencies/#development-dependencies says we should put "optional" dependencies which are "for development only" under the [dependency-groups] section (rather than [project.optional-dependencies]). See https://github.com/llvm/lighthouse/pull/22/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R9-R13 as an example.

My take is that the main difference whether the "optional group" can be specified as an optional "extra" upon pip-installing. That is, whether pip install lighthouse[dev_toots] would be the right thing to support.

Note that this changes the installation syntax from ... --extra dev_tools to ... --group dev_tools.