MNT: upgrade uv.lock (pyqt5-qt5 5.15.5, pyqt5-sip 12.16.1)

[neutrinoceros]

This is obtained by uv lock --upgrade and two changes happened since the affected portions of the lock file were last updated:

• uv 0.5.9 introduced a change of behavior regarding resolution forking (Fork version selection based on requires-python requirements astral-sh/uv#9827)
• PyQt5-sip 12.16.1 was released

I have not examined each change in detail yet, so I want to take the upgrade for a spin on CI to learn if it's even worth doing or necessary.

[neutrinoceros]

Evidently this doesn't work out of the box. Maybe I need to explicitly opt-in the old default behavior instead.

[neutrinoceros]

that's not it. --fork-strategy=fewest or --fork-strategy=requires-python produce similar results. Maybe that's a regression in uv 0.5.9 then. I'll try to report upstream if I have time soon.

[neutrinoceros]

I've come around to pinning uv itself in #189, which hopefully will help disentangling this situation

[neutrinoceros]

I checked that

• uv.lock is not updated if I remove the --upgrade flag, regardless if I use uv 0.5.8 or 0.5.9
• uv 0.5.8 generates the exact same lock file if running from scratch

This means that the breaking change must be caused by some external factor, most likely by a newly dropped release of one (or more ?) packages that this lock file keeps track of. PyQt5-sip 12.16.1 is an obvious suspect here.

[neutrinoceros]

I just remembered that I originally wrote the forked dependencies in pyproject.toml manually and generated uv.lock with these constraints. See https://github.com/1313e/CMasher/pull/181/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

This means that uv lock may actually never have done the right thing on its own here. I'll definitely need to report upstream.

[neutrinoceros]

reported as astral-sh/uv#9907