Update ruff and explicitly specify supported cpython and pypy versions

[JSCU-CNI]

Some housekeeping and an update to the latest ruff version.

[Schamper]

@twiggler how do you want to deal with this?

[twiggler]

@twiggler how do you want to deal with this?

With regards to the envlist, the monorepo has something similar, see: https://github.com/twiggler/dissect-monorepo-test/blob/8f07fe4b6ac73240049c314cbca4e2ff3d6ffd3b/pyproject.toml#L14

I remember dropping pypy310 because carbon-black-cloud-sdk~=1.4.3 did not built. (Note to self: document this and that the monorepo ci requires all optional dependencies to build, in contrast with the current ci).

With regards to the ruff bump: monorepo has ruff>=0 .13.1 (see https://github.com/twiggler/dissect-monorepo-test/blob/8f07fe4b6ac73240049c314cbca4e2ff3d6ffd3b/ruff.toml#L2). All projects need to be fixed up before we can bump to 0.15.12 globally in the monorepo. I am fine with merging this in, but notice that when we do the migration we regress back to 0.13.1, untill all projects are updated.

[twiggler]

@twiggler how do you want to deal with this?

In the mono-repo, it is a bit annoying to have to fix all projects to upgrade ruff. Perhaps a solution is to see which new rules are giving trouble, temporary ignore those, and then fix one rule at a time (in the monorepo).

[Schamper]

Alright, but do we want to merge this in then? 😄 Will it make things complex for the move to mono repo, or should it be fine?

In the mono-repo, it is a bit annoying to have to fix all projects to upgrade ruff. Perhaps a solution is to see which new rules are giving trouble, temporary ignore those, and then fix one rule at a time (in the monorepo).

That sounds like more work than just sitting down, running ruff check --fix dissect tests, ruff format dissect tests (just fix?) and fixing up any stragglers manually.

[JSCU-CNI]

Just a small note that if this is merged before #1390, then that PR should change the supported python versions to 3.14 (or 3.15? 😄)

[twiggler]

Alright, but do we want to merge this in then? 😄 Will it make things complex for the move to mono repo, or should it be fine?

(see above; with migration I meant monorepo migration)
I am fine with merging this in, but notice that when we do the migration we regress back to 0.13.1, untill all projects are updated.

So I am fine 😄
We just need to update all projects after or before the monorepo migration to be able to bump ruff.
During the monorepo migration, all tox.ini files are discarded and all pyproject.tomlare rewritten, so they will not interfere.

That sounds like more work than just sitting down, running ruff check --fix dissect tests, ruff format dissect tests (just fix?) and fixing up any stragglers manually.

Indeed, if most linting problems stemming from a ruff upgrade can be solved that easily automatically with ruff check --fix, then there is no problem 👍.

[william-billaud]

fox-it/dissect#99 took basically ~2 week to update all ruff repo, on a basis of 2/3 repo updated per day and it was something like 10/15 minutes for most repo (including "Add ruff commit to git blame ignore revs" commit).

Furthermore 52aaa64 was a +600/800 commit, this one is only +20/18, I think that in most repo the only change will be the ruff version in the pyproject.toml.

I don’t know when the migration to the monorepo is scheduled (or if it will simply happen when it’s ready), but I can help a bit if needed. I'm not saying that I will do the 33 in two week, but I can do some, especially if I have no so useful meeting in the coming weeks.

[william-billaud]

Let me know if you want a bulk of PR that update ruff version, or if you prefer waiting (as it also depends of your availability to merge these PR).