pre-commit autoupdate should not change rev fields like master or stable

[lucatrv]

I set most of my hooks' rev fields to master, or stable for black, see instructions. If I run pre-commit autoupdate, all rev fields are set explicitly to the latest version number, and I need to revert all them back manually. pre-commit autoupdate should update only those rev fields that are set to an explicit version number.

[asottile]

you should not do that -- it does not do what you expect -- and will eventually produce an appropriate warning

[asottile]

black's directions are wrong and will be changed eventually: psf/black#420

[lucatrv]

I'm ashamed I didn't notice that documentation section... But now my issue becomes that every time a hook is updated to a new version, the .pre-commit-config.yaml file is changed, and since I use conventional commits, every time I would need to create a new "build: [...]" commit.
What is the suggested solution to this?

[asottile]

what is the problem?

[lucatrv]

Well... to pollute my git history. Do you suggest to ignore the .pre-commit-config.yaml file or to check it in?

[asottile]

wait, what are you polluting?

[lucatrv]

I mean, I configured several hooks. Maybe every other day there could be an update, after a few years I would have hundreds of "build: [...]" commits just for .pre-commit-config.yaml. I wanted to avoid that.

[asottile]

if you read the docs above, the goals are for reproducibility and repeatability. without checking in the file and picking consistent versions you really have no idea what versions you're running and no way to validate

in other words, the world you're describing your repository will (not can) break without changes to the code in the repository

updating the versions of linters is a conscious decision and has a commit associated with it (instead of mysteriously broken builds due to some upstream changing)

you don't have to do it every day unless you want to (but then that would be your decision) -- the stability without updating is very good

I'd encourage you to read up on why repeatability is a desirable quality in software :)

[lucatrv]

I agree that reproducibility and repeatability is a very important concept when considering dependencies and build tools configuration, but (at least in my case) I'm using pre-commit for linting code, in case a linter is updated maybe I would get some new or different lint message, or even an error when committing, but my code would not really break. Or am I mistaken?

[asottile]

presumably your build is broken if your linters aren't passing

but also code formatters

[lucatrv]

OK, I found this solution: I installed all required packages locally, and configured all hook repos as local, using the specific hook configuration for each package. For instance for black now I have:

repos:
-   repo: local
    hooks:
    -   id: black
        name: black
        description: "Black: The uncompromising Python code formatter"
        entry: black
        language: python
        language_version: python3
        require_serial: true
        types: [python]

Now all packages are managed outside pre-commit, so the .pre-commit-config.yaml does not change anymore.

Are there any drawbacks with this solution?

[asottile]

yes that has exactly the same problems, except now you're using the less supported escape hatch

[asottile]

plus your contributors need to install things manually instead of having it automatically managed

[lucatrv]

I also added all linters to my setup.py file:

setup({
    extras_require={
        'dev': [
            'pre-commit',
            'pre-commit-hooks',
            'isort',
            'black',
            'flake8',
            'pylint',
            ...
        ]
    }
})

[asottile]

yeah, kind of the whole point of pre-commit is that it manages the installs for you so you don't have some bespoke setup for contributors to try and learn

[lucatrv]

OK, you convinced me, thanks.