Replace pre-commit with prek for faster linting

[juhannc]

Feature or enhancement

Proposal:

First, I hope this is the correct issue template. If not, please let me know, and I can resubmit the proposal using the proper template.

prek is a "reimagined version of pre-commit, [...] designed to be a faster, dependency-free and drop-in alternative".
It has already been adopted by major projects from Apache, FastAPI, and Django (see prek/Who is using prek?).

Running prek against the entire CPython codebase yields a speedup of almost 2.5x without a cache and 1.25x with a warm cache.

hyperfine --warmup 2 --runs 5 \
 --prepare "prek cache clean" "prek run --all-files" \
 --prepare "pre-commit clean" "pre-commit run --all-files"
Benchmark 1: prek run --all-files
 Time (mean ± σ): 19.835 s ± 0.290 s [User: 50.857 s, System: 6.248 s]
 Range (min … max): 19.527 s … 20.201 s 5 runs

Benchmark 2: pre-commit run --all-files
 Time (mean ± σ): 48.944 s ± 0.448 s [User: 76.063 s, System: 6.096 s]
 Range (min … max): 48.522 s … 49.681 s 5 runs

Summary
 prek run --all-files ran
 2.47 ± 0.04 times faster than pre-commit run --all-files

hyperfine --warmup 2 --runs 5 \
 "prek run --all-files" \
 "pre-commit run --all-files"
Benchmark 1: prek run --all-files
 Time (mean ± σ): 6.763 s ± 0.124 s [User: 35.990 s, System: 2.134 s]
 Range (min … max): 6.589 s … 6.900 s 5 runs

Benchmark 2: pre-commit run --all-files
 Time (mean ± σ): 8.537 s ± 0.048 s [User: 43.797 s, System: 1.903 s]
 Range (min … max): 8.484 s … 8.608 s 5 runs

Summary
 prek run --all-files ran
 1.26 ± 0.02 times faster than pre-commit run --all-files

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-143148: Replace pre-commit with prek in CI #143149
• [3.13] gh-143148: Replace pre-commit with prek in CI (GH-143149) #143359
• [3.14] gh-143148: Replace pre-commit with prek in CI (GH-143149) #143360

[StanFromIreland]

CC @hugovk

[AA-Turner]

I don't think we should yet wholesale replace, prek is still on 0.x, and explicitly notes in the README that it is not at parity etc.

However, using prek if pre-installed feels reasonable, we already do this with uv.

A

[juhannc]

I don't think we should yet wholesale replace, prek is still on 0.x, and explicitly notes in the README that it is not at parity etc.

What's blocking parity with pre-commit is the lack of the gc command to clean only unused objects vs. cleaning the entire cache and some missing languages for hooks that pre-commit supports (cf. prek/TODO). Given preks speed in installing new hooks, I feel like the missing gc command is not critical. And regarding the missing language support, none of those are required for the hooks in CPython. But I understand if you are hesitant to switch to prek. In that case, we can leave the issue and PR open until prek evolves further.

[picnixz]

Personally, I don't want to switch to yet another tool. I'm not against changing the CI itself but I'm against changing something that works with my local configuration (that is, I'm ok with the Makefile picking either prek or pre-commit, but I don't want to be forced to install it).

In that case, we can leave the issue and PR open until prek evolves further.

Usually, we prefer closing issues & PRs instead of keeping them open as we never know when it will be "ready" (it's not a problem to reopen the issue and PR afterwards).

[juhannc]

I'm against changing something that works with my local configuration (that is, I'm ok with the Makefile picking either prek or pre-commit, but I don't want to be forced to install it).

I totally understand your hesitation to change a running system. What about making prek the new default for new developers (as per the devguide), but changing the Makefile to fallback to pre-commit? As of right now, this would surely be possible, although I see prek developing features pre-commit never implemented (and probably never will), such as priority, which allows for a custom order of execution and running hooks in parallel, potentially increasing the speed gain even further. This is obviously stuff for a separate issue, but would require everyone to switch to prek. But yes, in the meantime, a two-pronged approach would work and would be transparent to the developer. Both tools would work just fine.

[AA-Turner]

Looking at the numbers again. ~8.5s to ~6.5s isn't massively compelling for the extra complexity here.

In terms of CI, linting is already one of the fastest jobs, and hence not on the critical path.

I think for now we should hold off on making this change. I'll close in a few days unless there's opinions to the contrary from other core devs.

A

[hugovk]

I support this.

I've been using prek for months (https://hugovk.dev/blog/2025/ready-prek-go/) and have switched most of my projects over. I'm using it locally with Git for CPython (not via make check) and all the other python/ repos too.

I don't think we should yet wholesale replace, prek is still on 0.x, and explicitly notes in the README that it is not at parity etc.

Ruff and uv are also still on 0.x :) I think all the hooks I need across all my projects are supported by prek. Everything we use here is already supported.

Personally, I don't want to switch to yet another tool. I'm not against changing the CI itself but I'm against changing something that works with my local configuration (that is, I'm ok with the Makefile picking either prek or pre-commit, but I don't want to be forced to install it).

Fair enough, although the Makefile uses a venv and does everything for you -- when you run make check, if pre-commit isn't in the venv, it installs and uses it from the venv. So if we used prek in the venv, it would take care of that for you too, and you wouldn't notice, except for much faster runs.

Looking at the numbers again. ~8.5s to ~6.5s isn't massively compelling for the extra complexity here.

Two seconds is a good improvement for pre-commit, when run locally, this is a worthwhile improvement. And ~20s vs ~49s is huge for uncached! (With extra config, prek also allows running hooks in parallel, which would be even quicker.)

However, using prek if pre-installed feels reasonable, we already do this with uv.

👍

I suggest:

• CI: Use j178/prek-action
• Makefile: If others don't want to use prek in the venv, then we can have it check if a system prek exists, and use that; otherwise fallback to the current pre-commit in the venv.