Pre-commit: How to test hook arguments with `try-repo`?

[metmajer]

Hi there!

I am in the process of making a contribution to a pre-commit hooks repo to enable arbitrary arguments to be mixed into the execution of certain processes. In order to test the correct behavior of my contribution, I was looking into pre-commit try-repo. However, neither try-repo nor run allows the configuration of extra arguments for the pre-commit hook.

Any suggestions? Thanks!

[asottile]

You're correct that pre-commit run / pre-commit try-repo don't really have a methodology for setting args: [...] for a hook.

how I usually do this

The way I usually attempt this workflow is to first run pre-commit try-repo:

(for example)

$ pre-commit try-repo https://github.com/asottile/pyupgrade
[INFO] Initializing environment for https://github.com/asottile/pyupgrade.
===============================================================================
Using config:
===============================================================================
repos:
-   repo: https://github.com/asottile/pyupgrade
    rev: 1db939202cdafbd1c144e165157cd4fffc8520c9
    hooks:
    -   id: pyupgrade
===============================================================================
[INFO] Installing environment for https://github.com/asottile/pyupgrade.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
pyupgrade............................................(no files to check)Skipped

From that, I would copy out the sample configuration that it spits out, modify it, and write it to .pre-commit-config.yaml:

repos:
-   repo: https://github.com/asottile/pyupgrade
    rev: 1db939202cdafbd1c144e165157cd4fffc8520c9
    hooks:
    -   id: pyupgrade
        # manual modifications vvv
        args: [--py3-plus]

And then use pre-commit run after that.

(If you don't want to clobber your own .pre-comit-config.yaml file you can always write it to a different file and then use pre-commit run --config ... ...)

potential features to make this easier

So I don't want to add an --args option to pre-commit run directly because it usually won't make any sense (you'd want to use the checked in configuration). I do think it is potentially useful for pre-commit try-repo, however there's a potential oddity that I'm not sure about: pre-commit try-repo will run _every_ hook in the remote repository. Passing --args on to all of the hooks will almost always fail.

If there's a potential feature here, it would have to be limited to the case where pre-commit try-repo is invoked with a particular hook in mind (pre-commit try-repo https://github.com/asottile/pyupgrade pyupgrade --args=...) for instance. Then there's a decision about the ergonomics of the --args command. Would it be --args 1,2,3 and then comma splitting (and escaped commas, bleh) or something like --args 1 2 3 ... (using nargs='+') though this often ends up with parsing ambiguities (especially when the arguments are very likely to be --dashed themselves). Probably gets complicated quickly -- might not be worth implementing for the complexity.

Let me know your thoughts on this :)

[metmajer]

@asottile wow, thank you so much for your elaborate answer. I've found a neat way to test the hook and circumvent the need to push code to my repository for changes to take effect by using a repo: local directive:

 repos:
 - repo: local
   hooks:
   - id: terraform_docs
     name: terraform_docs
     entry: ./terraform_docs.sh
     language: system
     files: (\.tf)$

Then, I run pre-commit run terraform_docs --files ./variables.tf ./outputs.tf, make local changes, re-run, and repeat if the results are not as expected. To me, this is the best option for now and this also qualifies for an automated test using Bats. Here's a longer description of the approach for your consideration: https://github.com/antonbabenko/pre-commit-terraform/pull/25#issuecomment-431649551. Thoughts?

I would love to see a --args option that requires a hook to be provided, but then again, if coupled with try-repo, the need to push code before it can be tested would still remain, which in my mind, conflicts with the goal of continuous integration (always keeping the repo in a releasable state).

Anyways, this is such a great project and does an amazing job in building more quality and discipline into our deliverables. Thank you so much!

[metmajer]

@asottile as I have found a solution that works well for me, feel free to close!

[asottile]

Cheers! Thanks for the issue