chore: run prek from a locked uv dev group

[shaanmajid]

Summary

Add a locked uv workflow for running prek in CI and local development.

This pins prek via a new dev PEP 735 dependency group, introduces a committed uv.lock file, and updates CI to run prek through uv run --only-group dev --locked. It also adds a frozen uv-lock pre-commit hook to ensure future changes keep the lockfile in sync. Lastly, I noticed that some pre-commit priority blocks did not match the comment sections, so this does some opportunistic cleanup to move these around.

Atop #26461. Closes #26386.

Test Plan

uv run --only-dev prek --all-files

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[sharkdp]

Thank you very much for working on this. I have a few questions.

[sharkdp]

Should the description here be updated (still uses uvx prek)? Maybe also search the repo for other uses of uvx prek?

[shaanmajid]

Ah yeah, I noted this during development but forgot to follow-up. Updated in a few files.

(FWIW, the main motivation of this change was to use a pinned prek version in CI; using a consistent version during local development was mostly an ancillary benefit. But I agree it's worth updating here :))

[sharkdp]

I'm wondering if introducing this global uv.lock file could break some of our existing scripts?

And if we need to update our release workflow to update this file?

[shaanmajid]

Ah, great catch. I inspected the uv and ty repos (which both similar global uv.lock files) to see if there's anything we should mirror here. The only major concern I found was the one you noted: the release process needs to re-generate the lockfile. Made the corresponding update to scripts/release.sh.

[shaanmajid]

Now that there is a global uv.lock, this could also provide the opportunity to fully resolve rooster and all transitive dependencies via the lockfile as well (instead of the current top-level @0.1.1 constraint). A similar change was made to uv recently in astral-sh/uv#19923. Let me know if you'd like me to make a follow-up PR for this :)

[sharkdp]

Will this be updated by renovate?

[shaanmajid]

Yes, I tested by manually downgrading the requirement to prek==0.4.4 and running Renovate locally; the existing pep621 Renovate manager handles this, updating both the requirement in pyproject.toml and the uv.lock file.

(This was not your question, but I also changed how the Python constraint is expressed here -- although it doesn't affect Renovate behavior either way. The initial python_version marker was chosen to match prek's own requires-python, because lockfile generation fails if uv has to resolve the dev group for Ruff's full project Python range. After comparing with uv's dependency-group style, I moved that to a group-level requires-python constraint instead, and bumped to >=3.12 to keep it more recent.)