We should add the coverage and build status badges on the site

Non Administrative Installation (curl http://pre-commit.com/install-local.py | python via http://pre-commit.com/#install) is failing with DistributionNotFound: No distributions at all found for wheel:

No distributions at all found for wheel
Exception information:
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/virtualenv_support/pip-1.5.5-py2.py3-none-any.whl/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/usr/lib/python2.6/dist-packages/virtualenv_support/pip-1.5.5-py2.py3-none-any.whl/pip/commands/install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/usr/lib/python2.6/dist-packages/virtualenv_support/pip-1.5.5-py2.py3-none-any.whl/pip/req.py", line 1177, in prepare_files
    url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File "/usr/lib/python2.6/dist-packages/virtualenv_support/pip-1.5.5-py2.py3-none-any.whl/pip/index.py", line 277, in find_requirement
    raise DistributionNotFound('No distributions at all found for %s' % req)
DistributionNotFound: No distributions at all found for wheel

Looks like virtualenv issue.

Add commitizen to the list of supported hooks.

See instructions.

• https://github.com/librariesio/libraries.io/blob/master/docs/add-a-package-manager.md
• can likely use all-repos.json and maybe(?) take some inspiration from the go implementation for libraries.io (since the distribution mechanism is similar)

The setup.cfg contains the below mentioned code but still the directories which were supposed to get skipped are being tested for style:
This works fine with flake8 but it's failing for pydocstyle

[pydocstyle]
match-dir = ^((?!doc|tests).)*$
ignore = D105, D107, D203, D204, D213

This is the hook I used (I also tried using a look hook but it didn't work).

-   repo: https://github.com/PyCQA/pydocstyle
    rev: 5.0.2
    hooks:
    -   id: pydocstyle

In sections pre-commit install and pre-commit install-hooks are mentioned "hook environments"... Not sure what this means... Could you clarify?

Could not test what result it bring as pre-commit install --install-hooks only returns pre-commit installed at .git/hooks/pre-commit as message...

Originally from this issue: pre-commit/pre-commit#384

follow-up to jgirardet/sublack#31
deferred from pre-commit/pre-commit#838

as i conversed with sublack author, it became apparent that its pretty hard/tricky to integrate pre-commit/black for example with editor integrations (in order to fix exact project set-ups)

i wonder if the issue can be elevated/helped in some way

As requested pre-commit/pre-commit#659

Congratulations, your search is now ready!
I've successfully configured the underlying crawler and it will now run every 24h.

You're now a few steps away from having it working on your website:

• Copy the following CSS/JS snippets and add them to your page

<!-- at the end of the HEAD -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/docsearch.js@2/dist/cdn/docsearch.min.css" />
<!-- at the end of the BODY -->
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/docsearch.js@2/dist/cdn/docsearch.min.js"></script>
<script type="text/javascript"> docsearch({
  apiKey: '5f052a6b9f5c2b81614512796afa7000',
  indexName: 'pre-commit',
  inputSelector: '### REPLACE ME ####',
  debug: false // Set debug to true if you want to inspect the dropdown
});
</script>

• Add a search input if you don't have any yet, and update the inputSelector value in the code snippet to a CSS selector that targets your input field.
• Optionally customize the look and feel by following the DocSearch documentation (https://community.algolia.com/docsearch/documentation/)
• You can also check your configuration in the github repo (https://github.com/algolia/docsearch-configs/blob/master/configs/pre-commit.json). Feel free to open pull requests!

Feel free to get back to us if you have any issues or questions regarding the integration.
We'd also be happy to get your feedback and thoughts about DocSearch - so we can continue to improve it.

Let us know if you need anything

Site gives examples like "language_version: 2.1.5" e.g. here

cfgv checker expects string.

So if language_version starts with digit like

repos:
  - repo: https://
    rev: beef
    hooks:
      - id: some-id
        language_version: 3.7

it causes errors like this

An error has occurred: InvalidConfigError: 
...
==> At key: hooks
==> At Hook(id='some-id')
==> At key: language_version
=====> Expected string got float
Check the log at /home/.../.cache/pre-commit/pre-commit.log

Hi,

The readme for https://github.com/pre-commit/mirrors-isort lists the hook as deprecated, as isort itself now has its own pre-commit hook. However, on https://pre-commit.com/hooks.html the hook is not indicated as being deprecated. Should it be?

Perhaps like

or

@Lucas-C either I can get to this or you can take a first stab

Some callouts:

• pre-commit migrate-config
• now a map instead of a list so ~*~*new features*~*~ can be implemented
• fail_fast: ... and global exclude: ...

right now it is hardcoded, I don't really want to update it all the time -- plus we have pre-commit available when we run it

this might (?) be easy to implement -- not sure

We should add the bootstrap hamburger menu to the frontend of the site for mobile support

Plz include the following pre-commit hook for prettier

https://github.com/awebdeveloper/pre-commit-prettier/

test

We should purchase a domain for pre-commit.github.io and link to that site

Make sure the position with scroll module on the documentation page works correctly

It may be a bit late for a change, but I wanted to point out that as someone getting started with pre-commit, the project name is very hard to use.

Since pre-commit is the name of the git feature that this framework exercises, most searches for "pre-commit" will only return references to the underlying git feature, and not this framework. In particular, this makes it hard to find example configuration files, or other peoples' plugins that are designed to provide hooks for the framework. It's hard to even talk to the uninitiated in e.g. a blog post -- "I'm using pre-commit to manage pre-commit hooks, and here's why it's great."

Other projects have faced this issue and developed conventions for talking about the project online (e.g. "golang" for "go"). I don't know if it's possible to come up with some convention like that to make references to the project more semantically unique.

Opening this as a "pre-commit.com" issue, since it seems that the public facing website for the project is the place that would suggest and promote such a convention if one could be found.

It would be really handy to have the hooks grouped by what it specified in the types field in the JSON data. That way if I'm looking to see what hooks apply to Python I can look in that section. I would assume this would be its own <h2> section after the current by-repository list.

Two tasks in here:

• Update the demo repo with screenshots
• Update the frontend to link to the demo

In your documentation and perhaps also in your code, you use "sha" when you appear to mean "hash", or more likely "commit".

Using the wrong word causes potential for confusion, and is also - in this case - a hostage to fortune, because there is no guarantee that future (versions of) version control repositories will use hashes from the Secure Hash Algorithm ("SHA") family of hashing algorithms to refer to commits.

This may be a minor bug, but it is still a bug.

It would be great if you could refactor your code and documentation to fix it in the next patch release, and stop supporting the incorrect term (e.g. where it appears in .pre-commit-config.yaml) in the next major release.

The documentation could use with more links to some examples. (Adding issue on behalf of @ivanlei)

today after running the installation command the script fails silently

curl https://pre-commit.com/install-local.py | python3 -

here's the command's output (user name replaced with ***):

$ curl https://pre-commit.com/install-local.py | python3 -
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload   Total   Spent    Left  Speed
100  3250  100  3250    0     0  26422      0 --:--:-- --:--:-- --:--:-- 26422
Using base prefix '/usr'
New python executable in /home/***/.pre-commit-venv/bin/python3
Also creating executable in /home/***/.pre-commit-venv/bin/python
Installing setuptools, pip, wheel...
done.
Downloading 
https://files.pythonhosted.org/packages/a4/e3/1f067de470e3a86875ed915438dc3bd781fb0346254f541190a09472b677/virtualenv-16.7.10.tar.gz
Done.

it seems to exit silently on line 98 of the install-local.py script:

if not virtualenv(venv_path):
    return 1

The invite link from https://pre-commit.com/#getting-help doesn't work.

The Creating new hooks section in the docs does not mention the stages property that is used by some of the pre-commit hooks such as trailing-whitespace.

It's somewhat confusing that pre-commit install actually only installs the pre-commit hook type, and that if you want other hook types you need to install those with a separate invocation of pre-commit install --hook-type {type}.

Neither the pre-commit install docs, nor the CLI output of pre-commit install --help are very helpful:

usage: pre-commit install [-h] [--color {auto,always,never}] [-c CONFIG] [-f]
                          [--install-hooks]
                          [-t {pre-commit,pre-push,prepare-commit-msg,commit-msg}]
                          [--allow-missing-config]

optional arguments:
  -h, --help            show this help message and exit
  --color {auto,always,never}
                        Whether to use color in output. Defaults to `auto`.
  -c CONFIG, --config CONFIG
                        Path to alternate config file
  -f, --overwrite       Overwrite existing hooks / remove migration mode.
  --install-hooks       Whether to install hook environments for all
                        environments in the config file.
  -t {pre-commit,pre-push,prepare-commit-msg,commit-msg}, --hook-type {pre-commit,pre-push,prepare-commit-msg,commit-msg}
  --allow-missing-config
                        Whether to allow a missing `pre-commit` configuration
                        file or exit with a failure code.

At the moment there is this heading on the start-page:

4. (optional) Run against all the files

I think running it against all files is too much at the beginning.

Why not like this?

4. (optional) Run against one file

5. (optional) Run against all the files

I think this would improve the first-time-user-experience.

Thank you for this great tool!

I couldn't figure out how to pass arguments to a pre-commit hook, and looking at the table of configuration options I did not see the args option listed.

After digging deeper I did find it buried in the Advanced Features section, but this seems like a common enough parameter that it should be called out with the rest of the API.

At a minimum it could just link to this section, ie:

I'm happy to add this to the docs, but I don't see where to do that in the repo.

I've been wanting to do this for a while since the homepage is getting pretty long.

Basically what I want the homepage to be is a quickstart guide and have there be separate pages that go more in-depth

Here is the result of installing hooks with pre-commit:

$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

Would it now be a good idea to have it return a list of the hooks installed and in what stages?

For instance for the following .pre-commit-config.yaml file:

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.1.0
    hooks:
    -   id: trailing-whitespace
    -   id: end-of-file-fixer
    -   id: check-yaml
    -   id: debug-statements

one would get the following messages:

$ pre-commit install
pre-commit installed the following hooks at .git/hooks/commit-msg:
    -   id: trailing-whitespace
    -   id: end-of-file-fixer
    -   id: check-yaml
    -   id: debug-statements

pre-commit should have its own badge with the pre-commit logo.

Badge creation libraries

https://github.com/badges/shields
https://github.com/google/pybadges

I'm happy to create a few.
My main questions would be, does pre-commit "host" it?
Should I use the pybadges library and commit the code for generating badges to this repo?

Hi,

Those are just ideas on ways to improve pre-commit documentation / ergonomy:

• I think there is an empty bullet in http://pre-commit.com#filtering-files-with-types
  That's because the closing <li> there is missing a backslash: https://github.com/pre-commit/pre-commit.github.io/blob/real_master/index.mako#L801

• maybe document additional_dependencies format for each language that support it

• it could be handy on the hooks.html page to include the hooks languages

• maybe explain that pre-commit install writes in .git/hooks/pre-commit

• I think fail_fast isn't documented yet ;)

• and finally, just a thought : shouldn't the script & system hooks be merged ?
  Maybe we could simply require that scripts paths start with ./ ?

https://github.com/codingjoe/relint
https://github.com/codingjoe/relint/blob/master/.pre-commit-hooks.yaml

Thanks!

CC @codingjoe

It would be great to have a GitHub bot that could execute pre-commit run ... on a PR then add a commit to the PR with the formatting changes, if there are any.

This would act as a last resort, ensuring that both maintainers and contributors don't need to care about formatting code.

Does this exist? If not, is there any interest in collaborating on something like this?

Prior discussions

• This same idea was suggested for prettier it was never implemented AFAICT: prettier/prettier#238
• This project runs black and adds a commit. I suggested supporting pre-commit: Mariatta/black_out#47

• pre-commit install: default install invocation will run existing hook scripts alongside pre-commit.
• pre-commit install -f --install-hooks: idempotently replace git hook scripts with pre-commit and also install hooks.

I'm having difficulty assuring myself that I'm parsing this correctly. Possibly related to #239. The addition of -f in the second example is notably unhelpful when trying to use this example to understand the contrast between install vs install --install-hooks. The docs for -f say it will "overwrite existing hooks / remove migration mode", which (plus the convention of what -f means in general) suggests that any operation with this switch should not be idempotent.

Could someone help explain the difference in more detail?

There's also this:

$ pre-commit --help install
usage: pre-commit [-h] [-V]
                  {autoupdate,clean,gc,init-templatedir,install,install-hooks,migrate-config,run,sample-config,try-repo,uninstall,help}
[...]
    install             Install the pre-commit script.
    install-hooks       Install hook environments for all environments in the
                        config file. You may find `pre-commit install
                        --install-hooks` more useful.

When would I find it more useful? Always? Should I consider install --install-hooks the default for initial setup?

• produce an error message in install-local.py if it is unlikely to work as expected (missing os.symlink, paths in virtualenvs are not bin but instead Scripts
• Call out that pip should be used on windows to install pre-commit in the documentation

Originally from pre-commit/pre-commit#620

Originally reported as pre-commit/pre-commit#1553

I'm running pytest using the following definition:

-   repo: local
    hooks:
    -   id: simple-pytest
        description: run pytest
        name: simple-pytest
        entry: pytest
        language: system
        types: [python]
        pass_filenames: false
        stages: [push]
        log_file: pytest.log

and I see pre-commit list pytest during the git push after I make a change to a .py source file and git add and git commit. But I cannot find a pytest.log file anywhere.

When I run pytest manually:

pytest > manual-pytest.log

The manual-pytest.log file is created in the current working directory.

This is on Ubuntu 18.04.4, with python 3.6.9, pytest 5.4.3

Conclusion: pytest is not failing -- that is why log file is created.

it would be nice to be able to copy and paste the code with a button or auto-select the code when clicking

I've got error below and failed to install pre-commit. Probably install-local.py would have a syntax error. Does anyone know how to avoid the error?

$ curl https://pre-commit.com/install-local.py | python -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3212  100  3212    0     0   4549      0 --:--:-- --:--:-- --:--:--  4549
  File "<stdin>", line 61
    file=sys.stderr,
        ^
SyntaxError: invalid syntax

My python version is:

$ python --version
Python 2.7.17

I am raising this improvement request about updating pre-commit.com main page in order to make it clear that pre-commit tool is not a git-hook, thins being only one more or less important feature of the product and clearly a fully optional one.

While presenting the tool to others in the last ~2 years I was almost always asked about this subject with vart majority of audience being confused because they assumed that the tool is yet-another-git-hook. Most of them already had previous experience with a git-hook, which was not always the best of them.

pre-commit is a great tool and like one of my collegues nailed it it may happen to have one of the misleading product naming know. Obviously the product rename would be insane, but this does not mean that we should not advertise it for what it is and present exactly its benefits and use-cases, especially for someone visiting the first time pre-commit.com which may not know much about the tool.

Issues identified in homepage:

• the tagline contains "pre-commit hooks", not sure if hooks are desirable mention, or if even pre-commit would be mandatory, I personally try to find a way to avoid repeating the tool name there an use something regerign to: linters, quick sanity checking tools,.... ?
• first screenshot is at https://pre-commit.com/#usage and exemplifies installation of hooks (optional feature), not the manual execution pre-commit run -a, which is likely to be less controversial.
• If we manage toinclude a screenshot example that even contains a linting failure that would be in the first page screen (so people would not need to scroll considerably to see it), it could help with early adopters as its friendly output is a big selling point -- clearly installation is less important than seeing how it looks.
• Side-by-side comparison with tox which would explain people why pre-commit plays well with tox and is not a replacement, as it is addressing (or avoiding) few design limitations presetn in tox. This would be a huge selling point for lots of python developers which can usually find hard to understand what would be the benefit of using pre-commit when they have one or several tox environments that are ralready running linters (likely most of them already supported by pre-commit).

We should have more prominent attribution to Yelp

Release is blocked on the new release that makes error messages better

Looking for a GitLab CI snippet, I stumbled upon #343 and wondered why the cache directory cannot be set in the .pre-commit-config.yaml file or even default to the current project's top-level directory. Environment variables could be used to override that if desired.

My thinking behind this is that I might have multiple projects using pre-commit with wildly different repo versions. Now, imagine running pre-commit gc in one project wiping repos that are used by another project. I don't know if/how pre-commit handles this under the covers, but I think keeping project specific things within each project's checkout would solve this.

Putting everything in a project's .cache/ by default and allowing project's to set a different value in their .pre-commit-config.yaml would nicely solve this and make dealing with caches during CI a bit easier to deal with too.

The regular caveats of running pip with sudo apply, including (but not limited to) breaking the user's installation of pip.

https://stackoverflow.com/a/37104948/1931274

With this PR: hugovk/tinytext#59
With this config: https://github.com/hugovk/tinytext/blob/master/.pre-commit-config.yaml

The Prettier hook failed:

pyupgrade................................................................Passed
black....................................................................Passed
isort....................................................................Passed
flake8...................................................................Passed
check blanket noqa.......................................................Passed
Check for merge conflicts................................................Passed
Check Toml...............................................................Passed
Check Yaml...............................................................Passed
mypy.....................................................................Passed
prettier.................................................................Failed
- hook id: prettier
- exit code: 1

internal/modules/cjs/loader.js:883
  throw err;
  ^

Error: Cannot find module 'please-upgrade-node'
Require stack:
- /pc/clone/89rCdSwwReu-UQrdqlPxWw/src/cli/index.js
- /pc/clone/89rCdSwwReu-UQrdqlPxWw/bin/prettier.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
    at Function.Module._load (internal/modules/cjs/loader.js:725:27)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/pc/clone/89rCdSwwReu-UQrdqlPxWw/src/cli/index.js:4:1)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/pc/clone/89rCdSwwReu-UQrdqlPxWw/src/cli/index.js',
    '/pc/clone/89rCdSwwReu-UQrdqlPxWw/bin/prettier.js'
  ]
}

https://results.pre-commit.ci/run/github/89922502/1603910359.7titBuVPQISl6WxqA7LTkA