gc: Determine CLI design for manual cleaning

[ehuss]

The current implementation from #12634 exposes a cargo clean gc subcommand to handle manually cleaning cache data. It is not clear what the final CLI design should be (and it is not clear exactly what the user scenarios are for when they would want to take manual control). This issue is tracking for determining what the CLI should look like. There are few different considerations:

• What should the actual subcommand be called? There were a few different considerations:
  • cargo cache is already in use by a third-party command
  • cargo gc (reserved by a third-party, but unused), was part of early proposals (cargo doesn't handle unstable top-level subcommands very well)
  • cargo clean gc — the current implementation
  • cargo clean — just fold the functionality into a single command which handles cleaning caches. @epage has concerns that this is overloading a subcommand used for different types of caches (local vs global, etc.).
  • cargo maintenance — just an idea stolen from git
• How does this evolve with cleaning target directories, global build caches, etc.?
• Which flags should be exposed? Currently it exposes a large number of low-level flags. Ideally I would like to only stabilize a small number of higher-level flags. But I don't know what the high-level user scenarios might be, so I'm uncertain exactly what to expose.
  • For example, one idea is to have a flag for "things that can be recreated" and another for "things that require downloading".
  • Also bikeshed the names of the options.

[epage]

Potential sources of prior of other tools with cache management

• poetry
• docker
• git
• nix, zig
• dune, etc)

Apparently buck2 and Turborepo grow unbounded

[epage]

Quick scan of brew

• autoremove
• cleanup
  • "Removes all downloads more than 120 days old. This can be adjusted with HOMEBREW_CLEANUP_MAX_AGE_DAYS."
• HOMEBREW_CLEANUP_PERIODIC_FULL_DAYS (default 30 days)

One complaint that came up was "brew cleanup has not been run in 30 days, running now" ... and then proceeds to run an interminable process in the middle of you attempting to do something else." (mastadon)

[epage]

We should probably step back and enumerate what the required use cases are and the "if it works" use cases.