Understanding how to configure pre-commit with repo: local

Question

I'm trying to get pre-commit working at work (I have it working on personal computer). Our security setup will not allow pre-commit to reference external repos and pip install external packages from them.

It seems like my options are:

1. Keep a copy of needed repositories on local git server
2. Setup .pre-commit-config.yml to use local repo

Before I decide which path to take, I want to know more about how the local repo works, but can't find a lot of documentation on the specifics on the pre-commit website (or elsewhere).

I've got the .pre-commit-config.yml setup like the example below.

repos:
-   repo: local
    hooks:
      - id: isort
        name: Run isort
        entry: isort
        language: system
      - id: black
        name: Run black
        entry: black
        language: system
      - id: flake8
        name: Run flake8
        entry: flake8
        language: system
      - id: pydocstyle
        name: Run pydocstyle
        entry: pydocstyle
        language: system

If I use the above .pre-commit-config.yml, what system versions of the packages are used? Is it the version in the active conda environment (I'm using conda)? I thought that would be the case, but the pre-commit hooks appear to be running even though I don't have isort, black, and flake8 or pydocstyle in the activated conda environment.

That seems odd to me, but I can't find anything online to confirm what system versions of those packages will be used in the local repository setup.

Also, what happens if I use language: python instead of language: system?

I'm also open if anyone else has any ideas about a way to use pre-commit with the security restrictions I face besides what I've outlined.

Virgil

Answer 1

repository local hooks are documented here

generally they are the escape hatch for the framework and are generally not the route you should be aiming to take (the suggested route being using the reusable repositories)

language: system is an additional escape hatch, in this mode pre-commit does not manage your tools and you must install them all manually (this defeats the purpose of the framework entirely, but it enable some amount of legacy compatibility in some use cases). for language: system it will run the tools as if you're running them in your shell (for example entry: flake8 will use whatever which flake8 returns)

language: python on the other hand is a managed environment, pre-commit will set it up and install it for you. ~generally if you're using language: python with repo: local you'll leverage additional_dependencies to install those things

each of the languages are documented on the website as well

---

disclaimer: I created pre-commit

Woodbury

Anthony - thanks for the info. I appreciate the help and your efforts to create pre-commit. I wanted to clarify a couple other things that I think I understand from the docs, but am not entirely sure. When selecting types: [python] will that just run on any Python files in the commit? Also, is there a way to setup pre-commit so it downloads and setups up the needed packages from Anaconda? I have a constraint that things must come from Anaconda's repositories at the moment (which is why I'm considering using the local repo with language: system). – Virgil

To clarify, I think I have things figured out, except whether it is possible to have things downloaded from Anaconda's main/conda-forge repositories. Is that currently possible or a potential feature request (e.g. add language: python-conda)? – Virgil

there's already a language: conda -- and yes types controls what files are run on -- that said those are both separate questions (comments get deleted on SO frequently) and may benefit as separate Q&A – Woodbury

If your pre-commit hooks depend on Python packages that are already specified in a requirements file of some kind, does it still defeat the purpose of the framework to use a local hook? It seems wasteful to create a separate Venv just to run e.g. Flakeheaven, when I already did pipenv install --dev flakeheaven and can run it cleanly and safely with pipenv run flakeheaven. I'm curious if you think that's some kind of anti-pattern in your framework, or if that's an acceptable/supported use case. – Jez

yes, because I can't just clone your repo and run the tools -- I have to somehow figure out your custom development environment and align all the stars and have everything installed and working – Woodbury

@anthonysottile Thanks. Came here thinking along same lines as OP. You just helped me understand why pre-commit prefers remote tools over locals. – Antisocial