Repository navigation
Replace pre-commit with prek for faster linting #143148
Description
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-fileshyperfine --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-filesHas 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
Activity
hugovk commentedon Dec 29, 2025
Yep, let's keep this one simpler.
Then install pre-commit into the venv (this is the current behaviour).
Or simpler:
In practice, the only way a tool ends up in the venv is if the Makefile installs it when not found.
juhannc commentedon Dec 29, 2025
But then there is no clear way to unite the tooling again in the future. I don't think a discrepancy between the tools used locally and in the CI is a clean approach.
Also, what about the developer guide? Should it mention prek at all? Because that would put additional strain on the developer, first to decide which tool to use and then potentially manually installing something.
emmatyping commentedon Dec 30, 2025
My understanding is that most of performance improvements from prek for a cold cache comes from using
uvto install hooks. Perhaps instead of switching to an entirely different tool, we could introduce pre-commit-uv which sees significant speedups for the cold cache case without needing to change anything else:Cold cache:
Warm cache:
hugovk commentedon Dec 30, 2025
A bigger improvement comes from prek cloning/installing repos in parallel.
prek's 6.1s is a lot better than pre-commit-uv's 13.4s (and pre-commit's 20.5s).
prek also reimplements some hooks in Rust, which helps with warm cache speeds.
dolfinus commentedon Dec 30, 2025
IMHO the more important feature prek 0.2.23+ has is priority - hooks that modify file content (ruff format, etc) can be run sequentially, and read-only hooks (ruff check, mypy, github workflow linters) can be run in parallel. For large number of read-only hooks the speed up can be huge.
Hook installation speed with cold cache is a nice improvement, but this is important only in CI workflows, not on local machine.
picnixz commentedon Dec 30, 2025
And I don't want tools that are not widely used as others. I'm ok with ruff, etc because those are tools I can trust and others can trust. It's more about how widespread
prekis. If it were used as much aspre-commitI'd probably have no issue with it, but for now, I definitely want to see whether the project will be as wide spread aspre-commit. To be clear, I'm willing to cast my core dev vote against the change if I'm forced to installprek. What I eventually want is one tool, not multiple ones used multiple projects that then pollute my global~/.cachefolder. FTR, I'm usinguvx pre-commitbecause I have too many Python versions installed and my default Python version (thanks to my OS) is Python 3.6 (though I may need to update it at some point, I was waiting for OpenSUSE Leap 16.0 to come out) and I prefer having very small system-wide installations.In this case, I would install nothing and leave it to the developer. It's their choice to install additional software and their choice whether they want to trust it.
There is a huge warning about it:
In this case, using priority but ending up with warnings is definitely something I don't want either.
emmatyping commentedon Dec 30, 2025
Regarding priority, I have doubts as to the correctness of running hooks in parallel, that seems likely to have unexpected failure modes.
I also agree with all of the points @picnixz made, especially that I don't think prek is widely used enough to adopt in CPython yet.
gh-143148: Replace pre-commit with prek in CI (#143149)
pythongh-143148: Replace pre-commit with prek in CI (pythonGH-143149)
pythongh-143148: Replace pre-commit with prek in CI (pythonGH-143149)
[3.13] gh-143148: Replace pre-commit with prek in CI (GH-143149) (#14…
[3.14] gh-143148: Replace pre-commit with prek in CI (GH-143149) (#14…
hugovk commentedon Jan 8, 2026
OK, CI is updated to use prek, we can revisit later about using it in the
Makefilewhen adoption is higher. Right now, pre-commit has 81m/month downloads, and prek is 14m/month.If you're not using the
Makefile, you can already use prek instead of pre-commit if you prefer.I think the trick is to keep the existing order for hooks that can write (that is, don't define a priority, and they'll be run in sequential order), but the read-only hooks can then run in parallel afterwards (so give them all something like
priority: 100).I'm running with this in a
.prek.yaml(via an alias) and haven't seen any problems (yet). It's also 0.8 seconds faster, 2.6s compared to 3.4s without (and 2.1s faster than pre-commit's 4.7s).Anyway, we can also reconsider adding
priorityin the future when switching to prek in theMakefile.pythongh-143148: Replace pre-commit with prek in CI (python#143149)
vivodi commentedon Mar 23, 2026
I recommend migrating directly to the pre-commit.ci GitHub app instead of the approach in this issue.
Running prek within GitHub Actions lacks persistent caching, forcing CI to re-download and reinstall all hooks from scratch on every run. In contrast, the pre-commit.ci GitHub app caches environments efficiently, ensuring time is spent only on executing hooks rather than setup. This would be significantly faster than both existing options.
I opened the issue #146317 Replace prek GitHub Action with pre-commit.ci GitHub app for better performance for this.
j178 commentedon Mar 23, 2026
@vivodi Did you check that? Where’s that claim coming from?
I just looked at the logs from the latest
lintjob:https://github.com/python/cpython/actions/runs/23422492043/job/68130457779
From what I can see,
prek-actiondid reuse the cached hooks and didn’t reinstall them.vivodi commentedon Mar 23, 2026
I just tested it—running via the pre-commit.ci GitHub app takes about 38 seconds, which is roughly the same as running
prekin GitHub Actions.Sorry for the confusion earlier, and apologies for the noise.