Add Ruff config

[zas]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences:

Problem

• JIRA ticket (optional): PICARD-XXX

Solution

Action

Additional actions required:

• Update Picard documentation (please include a reference to this PR)
• Other (please specify below)

[zas]

@phw ruff could replace isort, pylint, and flake8 we have configs for, so that's a first step.

I created a separated workflow for now, but we may want to actually replace pylint in existing workflows.
Also I fixed files according to extra warnings I was getting locally, some are quite interesting (like missing @staticmethod I detected because my precommit hook is running flake8, but those weren't catched by ruff afaik), most are cosmetic only.

Those related to raise ... from are trickier, most of times we want to use from parent exception, but in case we actually handle it, so I tried to stick to some ... logic. A review is very needed though ;)

Question: should'nt we write a proper pyproject.toml with a project section now?

[phw]

I didn't know about ruff, but this definitely looks like a simplification. Would of course be interesting to have this integrated into codacy (astral-sh/ruff#13391). Then we could really have only one tool.

It already found quite some things. Especially the missing raise ... from ... are already an annoyance when looking at some error logs with the "during handling of the error..." messages.

I added astral-sh/ruff-action@v3 to the allowed actions, so we can see how this performs here on the next run of this branch.

[phw]

Question: should'nt we write a proper pyproject.toml with a project section now?

@zas Generally yes. But we also still need setup.py for our custom build stuff. And ideally we should not duplicate metadata.

Would be great if all the metadata can stay in pyproject.toml, though. At least https://packaging.python.org/en/latest/guides/modernize-setup-py-project/#how-to-handle-dynamic-metadata suggests that with modern setuptools both metadata from pyproject.toml and setup.py can be combined. So we can have at least the static data in pyproject.toml, while still have everything that is dynamic generated in setup.py.

[zas]

But we also still need setup.py for our custom build stuff. And ideally we should not duplicate metadata.

About that, I think we should move to uv