Augmented cache control for PreIndexed sources.

[denelon]

In addition to better behavior when WinGet cannot refresh the cache, some users would prefer greater control of what to do in the event the cache is stale.

WinGet currently does have a TTL setting for the default SLA of the cache, but maybe there is a need for even more explicit control.

Users can run winget source update to force a cache update (assuming the network is functioning correctly), but there is no notion if running a command and explicitly avoiding the cache refresh.

From:

• #5834

@lkrms we have been discussing the logic used on a retry and the best way to proceed if we can't fetch an updated cache. In one case if we're not able to get the "initial" cache, it would be a complete failure. In the event of a stale cache we could proceed with that stale cache and some kind of informational message about how old the cache is.

It makes sense for winget to keep its cache in sync transparently; I'm coming at it from a Linux package management angle (I've already mentioned pacman, but apt and others are similar), where in the absence of optional tooling, the cache isn't refreshed from upstream unless you explicitly request it.

I'm not suggesting winget should do likewise--it's a different beast with a different audience--but the case for allowing users to "sync" and "install" as distinct operations if they choose to is arguably stronger for winget than for a typical Linux package manager, simply because its cache is, by definition, decoupled from the hosting platform of basically every package it services.

If I can't sync my pacman cache, I can't install packages either, because they all come from the same place; but winget doesn't suffer from this constraint 🙂. Its default behaviour when the cache is unreachable is important to get right, especially when you factor in bootstrapping scenarios, but perhaps it could be left as-is, albeit with improvements to how the failure is communicated to end-users. If a --no-sync option (and/or a no-implicit-cache-sync setting) were available, it could be suggested as a way to mitigate the issue temporarily, for example. And for users who would always enable --no-sync, I guess you'd need a standalone sync command. Best of both worlds?

Originally posted by @lkrms in #5834

[lkrms]

I hadn't picked up on the existing winget source update command; the only missing piece here seems to be a --no-sync option/setting pair (probably with a more consistent name, e.g. --no-update). 🙏🏻