Default install arguments on `.pre-commit-config.yaml`, because `--hook-type`s again

Hi, @asottile! 👋 😊

I was writing https://github.com/conventional-changelog/commitlint/pull/2715, and I ended up having trouble trying to communicate to the use how to use pre-commit install.

I understand this has been addressed multiple times on https://github.com/pre-commit/pre-commit/pull/1145, and I only skimmed the linked duplicates, but I wonder if you’d be open to another approach. Namely, to define the install args on .pre-commit-config.yaml, maybe under some new key, and also maybe adding a new command (like auto-install?).

This is not the most elegant solution, but it lessens the pain on people with non-trivial setups, and let’s them say “just pre-commit auto-install, no excuses” to their team mates.

Thanks for entertaining my idea!

[pkoch]

I imagine pre-commit install -t commit-msg isn’t that bad ?

In my case, it’d be pre-commit install -t commit-msg -t commit, and this would be even worse for people with more elaborate setups.

---

I think this ends up being a product decision. I’m of the opinion that pre-commit should aim to be setup with just pre-commit install.

From what I can read on https://pre-commit.com, its central promise is it “just working” and people not having to worry to setup their own virtualenvs (or cash equivalent in other langs) and put the right symlinks in the right place.

You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit.

By skipping this hook types bit, we’re effectively pushing that that installation responsibility problem back to the user. I now have to “copy and paste bash scripts from project to project” again, even if they’re small. Telling people to “just type it” is putting the install script in another place (prolly the project’s README or, even worse, in their heads).

Including this last mile clearly (to me) brings users value.

---

Now, I’m not insensible to the growth pains that seem very obvious from hook types. My solution proposal is indeed a big hammer (which could be boon for some other future problems, but clearly feels like a hack nonetheless). Maybe the right call is to wait for the next breaking change and make default_hook_types be only [commit]? Maybe something else?

[asottile]

I’m going to continue to defer for now