Consider renaming `[gc]` config table.

[ehuss]

In #14287 (comment), it was suggested to have a different name for the [gc] table. The intent is to make it something clearer to the user.

My intent is to have the frequency option affect all cache cleaning. That is, I think there should be one option for configuring the "once per day" cleaning of caches. I would be concerned that trying to define properties for various different kinds of caches could add complexity. To that end, I might suggest something like:

[cache]
auto-clean-frequency = "1 day"

I don't have a particular opinion about the other config options, since I don't know what those will ultimately look like (tracked in #13061). In the meantime, I would toss them in some sub-table until a more permanent solution is picked. Perhaps something like cache.global-clean or something like that.

Feel free to suggest other ideas, preferably with your reasons for what you suggest.

[weihanglo]

Maybe some sub-table like

[cache.global]
auto-clean-frequency = "1 day"

And someday later we got #5931 and #13061, we can expand to fine-grained control when needed.

[cache.global]
# The default for all cache. Overwritable.

[cache.index]
# for registry index cache

[cache.source]
# git or registry source

[cache.shared-artifacts]
# per-user cache

[cache.local-artifacts]
# workspace-local target dirs

[epage]

I was talking with someone about logging (tele metry). If we do that, we'd need log rotation / reclamation support.

I could see our options being

• See this as another form of GC and put it in the GC table (with a top-level name that is more general than cache)
  • auto would also cover log rotation
• Want to consolidate all logging config in .cargo/config.toml under one table, including log rotation
  • Should auto then not cover log rotation?

I don't want to block work on this on future possibilities but wanted to add to the conversation "there might be resources to reclaim besides caches". Do we want to limit auto to only caches? I can see both sides and wanted others thoughts.

[AustinHellerRepo]

I just wanted to add that I read that there was a proposal to "stabilize a minimal amount of garbage collection" and my heart sank. I said aloud "and this is the end of Rust". I forced myself to read further and realized that this is about file cleanup. Please reconsider using the phrase "garbage collection" as this strongly conflicts (on a verbiage-level) with one of the best features of the language.

[cessen]

I'll repost what I said in #14287, so people don't have to go searching for it:

Something that came up on the tracking issue is whether people will get confused with the gc name

I agree that this isn't likely to be an issue in practice.

However, I also feel like we might as well be more accurate and call it something like "cache cleaning", which is what it actually is. As I mentioned in the other thread, garbage collection is usually related to some concept of reachability and resultant high confidence that something is no longer used. This doesn't reflect how this feature actually works, or ever reasonably could work.

And unless I'm missing something here (which is always possible), I don't think there's any cost to simply naming this feature more accurately, aside from taking a bit of time to decide on that name.

[cessen]

I was talking with someone about logging (tele metry). If we do that, we'd need log rotation / reclamation support.

I don't feel strongly one way or the other. But I will say that as a user I wouldn't expect any aspect of log handling to be configured under the same namespace as the handling of artifacts that are actually functionally important to building. That doesn't mean it couldn't make sense, maybe? But it would at least be very unexpected to me. They feel like totally separate concerns.

[ranger-ross]

Please reconsider using the phrase "garbage collection" as this strongly conflicts (on a verbiage-level) with one of the best features of the language.

I think when most people hear garbage collection they think of language memory management gc, not cache clean up
So I would not be surprised if this caused confusion.

Maybe prune would be better than garbage collection.
This is verbiage that Docker uses for cleaning up unneeded containers/volumes/etc so there is some precedence for prune meaning "clean up unneeded stuff"

Also, although the CLI interface is still a ways off, cargo cache prune reads much nicer to me than cargo cache gc