lefthook as alternative to pre-commit

[jorenham]

I personally have bad experience with pre-commit. I was using it in all of my open- and closed-source projects, but stopped using it because of this. Not because out of spite, but because I don't want to risk that any of my users experience the same thing. I won't bore you with the details, but in case you're interested you can refer to numpy/numtype#388.

Either way, I've since migrated to lefthook. In the limited experience I have with it now, I've found it to be a "better pre-commit", and I haven't encountered any downsides so far.

As biased as I am, I believe that pre-commit is harmful for the open-source community. I'm afraid that its promotion on the sp-repo-review website could also be.

So I'd like to propose that sp-repo-review either stops requiring pre-commit in favor of lefthook, or to otherwise allow lefthook to be used as a (preferred) alternative.

[danielballan]

Just noting that it is written in Go, distributed on PyPI with a shim package that ships compiled code as package data.

[jorenham]

Just noting that it is written in Go, distributed on PyPI with a shim package that ships compiled code as package data.

Hm yea, they appear to have reinvented the wheel. Maybe open an issue for it?

[danielballan]

For what it’s worth, your experience is not the first one I have heard regarding this corner of the OSS ecosystem. I would support taking a broader look at the options.

[abkfenris]

There is also work being done on a pre-commit compatible implementation in Rust: https://github.com/j178/prefligit

[jorenham]

There is also work being done on a pre-commit compatible implementation in Rust: j178/prefligit

There's an issue there that's worth noting: j178/prek#73 (comment)

[henryiii]

Pre-commit is not just a git commit hook manager (it's got a terrible name). It is a framework to run checks written in over a dozen languages. First party support for providing hooks are provided by over 3 thousand projects (and it's used by over a hundred thousand projects). It also has its own CI system with updates and automatic fixes. You can't just replace it by a git hook manager. I don't even run pre-commit install very often; I usually run pre-commit run -a or let CI do it for me. I'm assuming either Astral will step in here at some point, or some other project (like prefligit) will end up being a valid runner - the structure of pre-commit hooks and config is very straightforward and would be easy to write a runner for. But until I see something that's able to fully replace most of what it can do, I don't think it's fair to discard an extremely helpful tool due to being annoyed at how easily the maintainer blocks people. He also happens to be a leading maintainer for pytest, by the way.

I'm happy to support an alternative for repo-review-sp if it supports all the checks we check for (which isn't that many). I'm not interested in jumping from "allow a new framework" to "recommend that new framework as a replacement" in one step, though! ;)

[jorenham]

I agree that it's a very useful tool, and that Lefthook isn't a drop-in replacement.

Currently, sp-repo-review requires pre-commit to be used, but only as a git commit hook manager. These requirements can also be fulfilled by a different tool like Lefthook. Additionally, many users (like myself) do not care for anything else that pre-commit has to offer.

[henryiii]

sp-repo-review "requires" that you have a .pre-commit-config.yaml, which is how you define the list of checks. It does not require that you install it as a git commit hook manager. Can you provide a mapping of the checks we require to a different tool? If so, we can make the checks recognize that as also fulfilling the check.

Also, you absolutely can skip checks, nothing is "required". tool.repo-review has a field for ignoring checks. Projects might not have docs, for example, so you can just skip any checks.

[henryiii]

Looking at https://github.com/numpy/numtype/blob/main/lefthook.yml, it seems to just be defining arbitrary commands, which we can't verify passes our check (how do you check to see if ruff is being used? Just look for a ruff command? Including one run via uv?). To me, it looks like lefthook is literally the part of pre-commit I don't care about (pre-commit hooks), and not the part I do care about (defining checks).

[henryiii]

(PS: to be clear, I'm not knocking lefthook, I'm just saying it doesn't look like something we can statically analyze to see if people are adding certain checks)

[jorenham]

Yea I see how it might be tricky to recognize those commands. Back when I was using pre-commit I also noticed that sp-repo-review did not recognize it anymore when I changed the pyright pre-commit hook to run locally using uv.

The only thing that I can think of right now would be to use a substring or regex based on the run command, to see whether it contains e.g. pyright, ruff, mypy, etc. This could also be applied to pre-commit, so that custom local pre-commit hooks would also be recognized.