Pinned versions compete at different scopes

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

[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.