this downloads tools at runtime rather than at build time so it's not a good fit for the framework -- perhaps you can chime in on pre-commit/pre-commit#1453 and pre-commit/pre-commit#3020 which are trying to solve this more generically (and correctly)

wrun works for its intended purposes and I think it's correct enough for what it's meant for. Of course there's room for some improvement always though. Anyway, it also works with pre-commit as it stands, the only thing I'm aware of where it does not work is pre-commit.ci. BTW pre-commit.ci's runtime network prohibition also runs at odds with other tools, such as dprint, as well as whatever would need to access the network for other reasons besides installing something (hypothetical, haven't come across anything, but easily imaginable).

Good to hear that a pre-commit solution to this problem is in the works, but I'm not really that interested in one that solves it only within pre-commit. Will drop a note about wrun to the mentioned issues in case the authors of those implementations wish to borrow some from there.

the problem is more that there's no write protection to the pre-commit cache at runtime (intentionally) and so writes in general break the cache integrity and at worst concurrent writes permanently poison the cache and so writing at runtime is unsupported

A workaround for that could be if pre-commit.ci provided a way to cache additional paths, not just the pre-commit cache. Whatever happens in them would be the responsibility of something else besides pre-commit. Can imagine that this would likely make sharing such additional caches pretty much a no go, as well as their retention suboptimal.

it's not a pre-commit.ci issue -- it's a pre-commit issue. writes to pre-commit's cache at runtime are unsafe

With regards to wrun, the cache dir is naturally configurable. As it sounds unlikely that pre-commit.ci would become supported for this tool, I'll likely remove the helper option to (ab)use a subdir in pre-commit's cache. Other CI systems that I'm aware of have the ability to cache pretty much arbitrary paths, should be no problem to configure the wrun cache if one is using it.

I'll likely remove the helper option to (ab)use a subdir in pre-commit's cache.

FTR, this option has been removed since, wrun no longer helps or recommends the user in any way to touch pre-commit's cache.

So in that sense I suppose that side of the blocker against adding this in pre-commit's supported hooks list is now gone, and the addition could be reconsidered. The build time vs runtime distinction still exists though, but that's not something wrun can affect alone. I suppose pre-commit could, if it provided more flexibility to configure what happens in each of those phases. wrun's --dry-run mode could be then used in a hypothetical "build" stage to do the downloads