pre-commit update

[PGijsbers]

Reference Issue

closes #1146
The issue identified problems with the outdated fixed versions of the pre-commit file. For me personally, it lead to different issues, so I decided it's probably best to bump all dependencies to their newest versions.

What does this PR implement/fix? Explain your changes.

Update all dependencies used in pre-commit hooks to their most recent version.
Other files have been updated accordingly to pass the new pre-commit tests, this mainly involves:

• black formatting of docstrings, which now no longer have a leading and trailing space.
• black formatting of many comma-separates lists (e.g., when calling a function), which is now by default reformatted to one-item-per-line, as opposed to only using this if it would otherwise exceed line length. (Personally I am a fan)
• Resolving a few new mypy complaints.

How should this PR be tested?

Not really sure, installing the latest pre-commit hooks and verifying that it works as expected?

[mfeurer]

Great PR. Do you know if there's a way we could automate these updates of black etc.?

[mfeurer]

Sorry, this was supposed to be an approve.

[PGijsbers]

Do you know if there's a way we could automate these updates of black etc.?

The reason we use fixed versions is to make sure that everyone has the same environment because, as you see from this PR, rules can change between different versions. Second, since rules can change between versions, as I see it automated version bumps would mean either:

• updating only the pre-commit file, leading to a state where the repository might not pass its pre-commit checks
• updating the pre-commit file and auto-formatting (works for black, but mypy issues can't be automatically resolved). Force merging these changes means automatically accepting whichever changes black makes (not a fan, should probably be evaluated by us before accepting the new style guide). Doing it through an automated PR means that effectively very little work is actually automated (a version bump and formatting for review by us), doing this for every release of black/mypy might actually lead to more work?

So I am not really sure of any useful way to automate this procedure.

edit: as a middle ground perhaps it can be part of a post-release job, where after each major release we have the dependencies checked/updated. But I am still not sure if the time spent automating this is worth it, maybe there's premade github workflows.

[mfeurer]

Good points. Maybe something like the dependabot which opens PRs to bump the versions, and we can then add to the PRs to fix these issues? But maybe it's not worth pursuing this?

[PGijsbers]

Opened an issue so we can look into it later 👍

[PGijsbers]

(of course, feel free to start looking into this yourself now if you want to)