Add dune cache clear command

[nojb]

Fixes #8971

Of course, if someone does DUNE_CACHE_ROOT=/ dune cache clear or similar they will zap their whole system...

[Alizter]

Maybe we should prompt the user saying:

This will delete ALL contents directory /foo/bar, are you sure? (yes/NO)

Saves anybody accidentally zapping something. I don't believe we have a precedent for user prompts but I think this is a good time to do that. As for people using this in scripts, I would argue they really shouldn't be using it so a prompt is OK.

[Alizter]

We could also perform a simple check to make sure it is Dune cache we are deleting and not some other files. I'm a bit worried about giving users a blanketed way to shoot themselves.

[rgrinberg]

What's the difference between clearing the cache and doing dune clean? I don't see a need for a prompt for either.

A nice improvement would be to see how many files were deleted, but it's not required for this PR.

@pmwhite could you review this one?

[emillon]

I find Path.rm_rf ~external:true a bit too unsafe. Is it possible to iterate on Dune_cache_storage.Layout.Versioned.list_*_entries instead?

[nojb]

Is it possible to iterate on Dune_cache_storage.Layout.Versioned.list_*_entries instead?

We could. An alternative could be to change the interpretation of DUNE_CACHE_ROOT as follows. Currently, DUNE_CACHE_ROOT is (by default) ~/.cache/dune/db and the cache creates a number of directories inside this directory. Instead we could consider that DUNE_CACHE_ROOT is ~/.cache/dune by default and the Dune cache will create all its directories inside $DUNE_CACHE_ROOT/db. The dune cache clear command could then just zap the $DUNE_CACHE_ROOT/db directory which would be safer than deleting $DUNE_CACHE_ROOT.

Opinions?

[pmwhite]

@nojb The most significant part of that alternative to me is that we require DUNE_CACHE_ROOT to contain a db sub-directory, thus providing a little bit of validation that the variable actually does point to a cache. Whether we delete the cache directory itself or just db is an orthogonal decision, I think; that is, we could check that there exists a db sub-directory before deleting the whole cache. Are there other bits of structure that we could check before deleting anything?

Separately, a few bikeshedding thoughts: dune cache clear does sound to me like we're removing the contents of the cache, rather than deleting the cache itself. So I would support either changing the behavior to delete just the contents, or renaming the command to dune cache delete. Maybe dune delete-cache is clearer because dune cache delete might seem like it lets you delete individual cache entries, but it's also a bit less discoverable. I don't have strong feelings about any of these naming things, to be clear; do what you think is best.

[Alizter]

On the topic of naming, both dune clean and dune cache clear sound very similar and might confuse future users trying to remember clean vs clear. I had to actually double check before writing this. dune cache clean sounds a bit funny so I don't have a good solution for this, so you can disregard this comment if you wish.

[nojb]

I find Path.rm_rf ~external:true a bit too unsafe. Is it possible to iterate on Dune_cache_storage.Layout.Versioned.list_*_entries instead?

I pushed a commit with this approach; I agree that it is an improvement.

[nojb]

Sorry, this one slipped through the cracks :) I rebased it, added a test and an entry to the changelog.

It's been already approved by @pmwhite, so am planning to merge it once the CI passes.

[emillon]

Thanks!