NuGet command to purge/clean cache

[clairernovotny]

The shared package cache right in v3 is more hidden than the solution-based location in previous versions. This can make it much easier to accumulate older cruft over time. Selectively cleaning the cache is painful too because of how many folders there are.

NuGet could be smarter about this and provide options for pruning the main package cache. Some ideas:

• Delete by download date (on the assumption that older ones are less likely to be used)
• NuGet could touch a file in each version's dir upon each restore operation (literally the equiv of touch on unix, race conditions don't matter here, just use latest). Then a prune could easily have a "not used in the past month" switch
• Just nuke the whole directory, totally clean
• Other selective options?

[yishaigalatzer]

This is already supported: nuget.exe locals -clean all (and more goodies https://docs.nuget.org/consume/command-line-reference#locals-command)

We will also add it to xplat/.net cli eventually

[clairernovotny]

I know there's a clear command. This was to sta suggest ways to make it more selective than a full purge.

For many users, downloading everything is expensive and slow. Now they need to reclaim disk too.

[yishaigalatzer]

Just nuke the whole directory, totally clean

I was reading this as an option

NuGet could touch a file in each version's dir upon each restore operation (literally the equiv of touch on unix, race conditions don't matter here, just use latest). Then a prune could easily have a "not used in the past month" switch

Touching is a bad idea, build systems rely on the dates not to change, so nuget can start managing a separate cache here

Delete by download date (on the assumption that older ones are less likely to be used)

That's a bit of an unreasonable assumption, I don't see the relationship, this will for example delete the .NET packages which is one of the biggest package sets.

So I'm open to more discussion here, and if something can be done to make it better, all for it.

But I don't want to add unnecessary complexity and tooling for something relatively trivial like this with a clear strong benefit that can be explained.

[clairernovotny]

Good point about the delete all - I didn't realize 3.3 had that.

I supposed the real potential gain is selective cache trimming. That would help those with slower and/or metered connections the most.

For my second idea, how would touching a file in the cache dir affect a build system? I would propose adding a lastupdated file into the cache structure alongside the .sha512 file. On nuget restore, that file would simply be "touched." A build agent/system shouldn't care about timestamps on those files because they're outside the build root. If you do that, then a selective delete based on MRU would be pretty easy.

[yishaigalatzer]

That's works. Will need to validate that this doesn't slow things down.

This could be a nice addition when we break the surface of the water we are under or a cool pr

[csharpfritz]

The cache management is currently only accessible from the command-line. Can we add this feature into the powershell console and a button in the NuGet settings dialog?

[yishaigalatzer]

@csharpfritz that's ready tracked as a separate issue

[nandersen674]

Hi Yishai

I would not raise this as an issue, if there was an easy workaround , but I really hate misbehaved applications.

If you set readonly attributes on a server, it is usually because you want to preserve something .

Now n a DevOps environment it is not uncommon to maintain fusions or even hundreds of builds, and the current nugget behaviour is a hindrance of that, and it costs us many hours of download time every day.

Honestly I find your dismissal of my request offensive. I want to use your software, it can help my organisation a lot, but I'm asking for a way to solve what I would consider a serious misbehaviour.

Kind regards
Niels Andersen
BNP Paribas CIB

[yishaigalatzer]

I'm suggesting that there is a new mechanism to use nuget that resolves your issue (or most of it) and that this current old mechanism is an area we don't want to keep evolving. Because it has numerous limitations and by investing in it we delay progress in the area where we see the most benefit to the bulk of the community. This is why I linked to an issue that covers a very similar ask.

At the same time we would be glad to help you tweak your existing process and optimize it so you don't lose time/effort. If you'd like please email us on feedback@nuget.org and we will work with you on making your process better.

[rrelyea]

closing this one...in favor of the similar #4980