[pre-commit.ci] pre-commit autoupdate

[pre-commit-ci]

updates:

• github.com/pre-commit/pre-commit-hooks: v4.6.0 → v5.0.0
• github.com/astral-sh/ruff-pre-commit: v0.0.233 → v0.9.4
• github.com/pre-commit/mirrors-mypy: v1.11.2 → v1.14.1
• github.com/psf/black: 24.8.0 → 25.1.0
• github.com/rhysd/actionlint: v1.7.1 → v1.7.7
• github.com/igorshubovych/markdownlint-cli: v0.41.0 → v0.44.0

[diazona]

Thanks for looking into the failures! I'm busy these days and wouldn't have time to look at any of this until this weekend.

FWIW the typing error looks to be caused by the fix to my bug report pypa/pyproject-metadata#126, so we have a situation where different versions of pyproject-metadata have different type constraints. I would imagine there should be a way to write the type constraints in this project so that they work with both older and newer versions of pyproject-metadata, but if not, we can always require a minimum version of it. Regardless, since it's not actually related to the pre-commit changes, I'd suggest making that fix in a separate PR.

(also X | Y was officially introduced in Python 3.9 IIRC, although I think you can enable it with from __future__ import annotations as early as 3.7, or something like that)

[sjlongland]

Yeah, fair comment … I'll try and split those up when I next get the chance. I had a few brief moments at work yesterday to quietly slip that in but my quick fix doesn't appear to have solved much (pre-commit.ci still reports failures), so perhaps the answer here is:

1. figure out a fix for the build failure on a separate branch based off this one
2. cherry-pick those into a clean branch, submit a PR for that
3. rebase this branch off the newly merged main

Had the bot done this the day before I might've dealt with it then because it was a public holiday here in Queensland (King's Birthday long weekend) so I would have had the time, but this week has been a busy one.

Might be able to get to it on Friday evening (Australia/Brisbane; early Friday morning US/Pacific).

[diazona]

If I correctly understood what's going on, the failure would happen on main as well: it was caused by the release of a new backward-incompatible version (0.8.1 I think) of pyproject-metadata. So no need to base the new branch on this one. It only showed up here because this was the first time our pre-commit CI workflow ran since that version of pyproject-metadata got released.

It might not be a bad idea to add a scheduled run of our CI on main every week or so, and that way if the package gets broken by a dependency update, we'll find out relatively quickly.

[sjlongland]

Yeah, that's not a bad idea… I do the same thing at work for that reason. Weekly re-build of everything to ensure nothing silently breaks.

I got fed up of seeing builds that were 'green', and turn 'red' the moment someone touches them because dependencies shifted.

[sjlongland]

After #185, I get a sneaking suspicion we may actually be able to use the latest ruff releases.

[diazona]

I'll get back to this soon 😅 life got in the way....

[diazona]

I'm a little tempted to just close this PR and let the bot start from scratch on a new branch next time....

[sjlongland]

Yeah, might be a thought… we'll close for now and see what it comes up with in a few weeks time.

[diazona]

Thanks! I deleted the branch, too, otherwise the bot might just try to reopen this.