Pinned versions compete at different scopes

[jaraco]

In #863, I reported an issue where stable of black didn't work as expected. That issue is biting me again today.

Somewhere in a cryptic cache, pre-commit has cached that stable is something other than what Github has as stable for the same repo. Is there any way to tell what commit pre-commit has associated with stable?

The recommendation is to "just use autoupdate". However, that recommendation requires committing the updated version to the current project's repo, irrespective of what version that project might be using in the test suite or what version of black may be installed in the development environment.

Moreover, because autoupdate writes to a SCM-managed file, running that command alters the state of the environment, demanding additional manual steps (config), and diverging that file from its previous state. For example, I manage this pre-commit config that's shared across hundreds of projects, so if black needs updating, I need to update it in that root repository before merging it with the hundred projects.

I'd like to find a way to eliminate the toil and noise of keeping pinned versions updated across hundreds of projects.

I'd rather there be a way to specify "latest" for each of the plugins and while pre-commit should continue to cache those values for performance, there should be a way to say, "please check" and ideally that could happen periodically (~daily or weekly) for a given repo.

Maybe the best thing to do for now is to just rm -r ~/.cache/pre-commit each time I get divergent results from what black produces from other updated sources?

[asottile]

don't use rev: stable

[asottile]

by the way, I'd recommend using https://pre-commit.ci -- it'll keep your configurations autoupdated for you

[jaraco]

I acknowledged that that was the recommended approach. What I was expressing was problems with that recommendation and suggesting why some means to automatically update without committing to a repo would be helpful.

[asottile]

sorry but you're missing the point of the configuration and the tool in general. the point is to have a repeatable and versioned way to run tools such that you don't have version skew. that's why there are versions in the file. that's why that bit is there in the docs. that's why autoupdate exists. that's why the next version will produce a warning for things like rev: stable

if you use rev: stable this means that any particular contributor to your repository may be at some skewed version of reality which is incompatible with your repository's linting. it also means that as black makes changes / releases your repository will bitrot and not pass linting (even though it did when you made the commit). this breaks the fundamental goal of repeatability and is therefore not supported

[jaraco]

Yes, that makes sense. I guess I'll try keeping the pinned versions up-to-date in jaraco/skeleton and see how that goes. Thanks for clarifying!

[asottile]

in case you missed it above -- you might want to check out pre-commit.ci -- it has a periodic autoupdater so you don't have to think about it

[jaraco]

in case you missed it above -- you might want to check out pre-commit.ci -- it has a periodic autoupdater so you don't have to think about it

I'll check that out, thanks.