Feature request: Ability to purge unused cache when building

[webdevred]

Description:
It would be very helpful to have a feature or command to easily remove unused cache. Currently, there doesn't seem to be a straightforward way to clear cache that is no longer in use, which can lead to unnecessary storage consumption over time.

Suggestion:

• A function in the CLI to clean up cache that hasn’t been accessed for a certain period or is no longer referenced.
• An option to manually trigger the cleanup of unused cache.

Rationale:
This would help users keep their environments clean and avoid wasting storage space, especially in projects with large amounts of cached data.

[mpilgrem]

@webdevred, to be clear, what you mean by the 'cache'? Are you referring to deleting the snapshots directory in the Stack root (https://docs.haskellstack.org/en/stable/topics/stack_root/#snapshots-directory)?

(At the project level, there is stack clean.)

[webdevred]

@webdevred, to be clear, what you mean by the 'cache'? Are you referring to deleting the snapshots directory in the Stack root (https://docs.haskellstack.org/en/stable/topics/stack_root/#snapshots-directory)?

(At the project level, there is stack clean.)
Thanks for the clarification.

To confirm, I understand that stack clean removes all build artifacts for the current project, and it does not try to detect or remove only unused modules. That makes sense.

What I am looking for is something more selective. Specifically, a way to safely remove only the cached or built data that is not used by my project. This includes snapshot data for resolver versions not used by the current project, packages that were downloaded or built but are no longer referenced, and leftover build artifacts from modules that have been removed.

The goal is to clean up only what is no longer needed by my project, without risking removal of data used by other projects. Since Stack has full knowledge of what the current project references, it should be much easier and safer to clean up unused project-specific data than global cache like resolver snapshots or shared packages, which may be in use by other projects.

Would it make sense to support a feature like this, possibly as a safe cleanup or garbage collection mechanism?

Best regards,
webdevred

[mpilgrem]

@webdevred, thanks for elaborating. I understand that you are looking for something both more discerning and more far-reaching than the current stack clean, namely:

• each project package in a Stack project has a dist directory, further organised by actual GHC version used (and platform). stack clean deletes the dist directory, but you want to preserve the dist subdirectory for the current actual GHC version used; and

• each Stack project has an install directory with a SQLite database and further organised by what distinguishes one reproducible build from another. stack clean does not touch the install directory, but you want to delete everything that does not relate to the current reproducible build. (stack clean --full or stack purge does, of course, delete this directory.)

I'll have to think about this carefully, as I do not know how that SQLite database is currently used.

However, may I ask why stack purge does not meet your needs, in practice? Admitedly, after its use, the project-specific 'cache' has been wiped clean, but that only affects the first stack build after that.

[webdevred]

thanks for elaborating. I understand that you are looking for something both more discerning and more far-reaching than the current stack clean, namely:

* each project package in a Stack project has a [`dist` directory](https://docs.haskellstack.org/en/stable/topics/stack_work/#project-package-stack-work-directory), further organised by actual GHC version used (and platform). `stack clean` deletes the `dist` directory, but you want to preserve the `dist` subdirectory for the current actual GHC version used; and

* each Stack project has an [`install` directory](https://docs.haskellstack.org/en/stable/topics/stack_work/#project-stack-work-directory) with a SQLite database and further organised by what distinguishes one reproducible build from another. `stack clean` does not touch the `install` directory, but you want to delete everything that does not relate to the current reproducible build. (`stack clean --full` or `stack purge` does, of course, delete this directory.)

I'll have to think about this carefully, as I do not know how that SQLite database is currently used.

However, may I ask why stack purge does not meet your needs, in practice? Admitedly, after its use, the project-specific 'cache' has been wiped clean, but that only affects the first stack build after that.

While stack purge does achieve a full cleanup, it is more aggressive than I would prefer for this use case. It removes all cached data, including items still relevant to the current project and resolver, which results in unnecessary rebuilds and downloads. In a CI/CD environment, determining an appropriate interval for running stack purge is challenging, running it too often significantly increases build times, while running it too infrequently can lead to excessive storage usage. A more selective cleanup that removes only unused data would allow for frequent, safe cleanups without incurring the rebuild penalty of a full purge.

[mpilgrem]

As a start, I have raised a pull request to add a --[no-]omit-this flag (disabled by default) to stack clean.

--omit-this was the tersest synonym for 'exclude the current Stack project configuration from cleaning' I could think of.

stack clean behaves as it always has. However stack clean --omit-this omits, from cleaning, the directories currently in use.