Add a `repo: self` option to allow easy consumption of hooks defined inside .pre-commit-hooks.yaml

[ssbarnea]

By adding an option like repo: self or repo: ., that would not use rev, we could simplify self-testing of hook defined in current repository. This would help testing for hook publishers.

Current we are using other more convoluted methods for tests hooks defined locally while we are unable to use our own hooks inside the same repository that exposes them.

An alternative to this would be extend the meaning of the current repo: local to allow referencing hooks defined inside pre-commit-hooks.yaml without having to redefine them there (basically being able to mention just their id).

I hope this describes well enough the use case. I currently maintain a collection of hook at https://github.com/ansible/actions/blob/main/.pre-commit-hooks.yaml which rely on uv an npm native version management for reasons explained in #1462

[hehaoqian]

@ssbarnea I do agree that it is pain without repo: self

but I want to mention about the problem of repo: self

repo: self is similar to prek try-repo or pre-commit try-repo,
that virtualenv is not cached, and reinstalled every time try-repo is called.

I think that only python has full editable installation support. Other languages do not.
The safest way to ensure the hook is consistent with the current code of the repo,
would be doing a reinstallation of virtual env in each commit,

Due to these restrictions, to support repo: self in the most safest way,
prek should fully reinstall the virtualenv, without using editable installtion,
every time the hook is run, and remove the virtualenv after the hook completes.
(Although this is slow)

[j178]

I don’t think we should support this. Like @hehaoqian mentioned, repo: self isn’t pinned, so it can’t be cached and gets recreated on every run, which makes it a lot less useful.

We’d recommend always using the full repo URL pointing to the current repo as a workaround.

[ssbarnea]

@j178 How is this different from repo: local when it comes to caching and pinning? The only different is about enabling use of hooks defined locally, in one case is inside the same file and in second case is inside its sister .pre-commit-hooks.yaml file.

Using an URL to itself is not an option because you want to test the hooks that you just modified and see that they are working on your own repo.

AFAIK, self/local are very similar regarding their limitations. I can understand that adding new special meaning key can impose some undesired maintenance costs.

Maybe there is a way to implement this within local with different syntax for the "id?", something like

- repo: local
  hooks:
    - id: .pre-commit-hooks.yaml/hook-id

Alternative syntax using a custom loader:

- repo: local
  hooks:
    - id: !from-hooks hook-id

The custom loader approach has the advantage on allowing to implement the entire feature at config loading level, as the loader will return the 'resolved' config.

On the other hand, my impression is that TOML does not have a custom loader, so maybe another approach would be better? What matters is to enable hook authors to easily dogfooding their hooks.