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 #143149

[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