Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Provide a button (or option) to delete non-latest versions of mods from cache #3882

Closed
JonnyOThan opened this issue Aug 16, 2023 · 7 comments
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Enhancement New features or functionality

Comments

@JonnyOThan
Copy link
Contributor

Problem

I just realized that I have the 1.3 version of parallax textures sitting in my cache, which is pretty hefty. Who knows how many other intermediate versions of things are in there that I'll never install again?

Suggestion

Either a button in the settings window to clear non-latest versions of mods, or just do it automatically when a new version is downloaded.

Alternatives

No response

Additional context

No response

@HebaruSan HebaruSan added Enhancement New features or functionality Core (ckan.dll) Issues affecting the core part of CKAN labels Aug 16, 2023
@HebaruSan
Copy link
Member

How about #2536?

image

@JonnyOThan
Copy link
Contributor Author

JonnyOThan commented Aug 16, 2023

That doesn't quite cover it, because I want an unlimited cache but only keep the latest version of each mod. That would be a good place for another option, like "purge old versions." Ideally this would just happen automatically behind the scenes, but I could see a case where people want to keep a couple different versions of a mod.

@HebaruSan
Copy link
Member

HebaruSan commented Aug 16, 2023

OK, just to give some idea of the considerations here...

  • I'm assuming that this suggestion would want to preserve your installed mods in the cache, given that sometimes the "Hold" "Held" label is used to hold back when you don't want to install the actual "latest" version of a mod
    • I would expect that a mod that you decided to uninstall completely would be even less desirable to keep than an older version of a mod you still have installed (also tilting the focus away from "latest" and toward "installed")
    • Similarly, for those users who run older game versions (I continue to see mentions of KSP 1.3.1, as bizarre as that sounds), the "latest" version of a mod is not significant if they can't install it anyway due to a requirement for a newer game version
  • It's common for users to have multiple game instances
  • The download cache is shared across all game instances
  • Each game instance has its own list of installed modules, stored in the registry
  • The KSP1 registry is 30+ MiB of JSON at this point and takes several seconds to load

Suppose you have multiple game instances, with RP-1 installed in one, and you switch to your stock-alike instance where none of RP-1 is installed and install a new mod. Should the RP-1 downloads be purged at the end of that? I'm going to assume they shouldn't, so we would need to retrieve the list of installed mods from the registries of all game instances. This may take tens of seconds to complete, given the need to chug through loading all registries, so it's probably not something we could add to the end of the install flow.

The current overall cache size limit sidesteps this problem by simply deleting the oldest files first when the cache exceeds the user-configured maximum size, FIFO style. Fortunately the compatible game versions for an instance are stored separately and therefore can be loaded much faster than the full registry, so it's also able to prefer keeping mods that are still compatible with any game instance.

@JonnyOThan
Copy link
Contributor Author

I'm not quite sure what the "hold" label is.

I would expect that a mod that you decided to uninstall completely would be even less desirable to keep than an older version of a mod you still have installed (also tilting the focus away from "latest" and toward "installed")

Strong disagree here. I'm often installing and uninstalling mods and virtually always want to be on the latest version of things. Just because I remove something for now doesn't mean I don't want it back again soon, or on a different instance.

Similarly, for those users who run older game versions (I continue to see mentions of KSP 1.3.1, as bizarre as that sounds), the "latest" version of a mod is not significant if they can't install it anyway due to a requirement for a newer game version

Sure, I guess what I mean is "latest version that is compatible with my game instances."

If it's too expensive to figure out what versions need to be kept because they're installed on other instances, then so be it. Maybe I just need to set a limit on the cache size, because it does sound like it removes things in the correct order already.

@HebaruSan
Copy link
Member

HebaruSan commented Aug 16, 2023

I'm not quite sure what the "hold" label is.

See #3220. This suggestion would negatively impact one of those use cases, in which there is an advantage to keeping older versions, at least for some time:

  1. I install a mod
  2. I upgrade to a new version of that mod
    This change would cause the previous version to be purged at this point
  3. I run the game and find that version of the mod is broken
  4. I revert to the previous version of the mod and mark it with the "Held" label pending a fix release
    This change would require re-downloading the older release of the mod at this point

@JonnyOThan
Copy link
Contributor Author

Yeah I certainly wouldn’t want to make any caching logic more complex either, so feel free to “won’t fix” this one.

@HebaruSan
Copy link
Member

Let's stick with the existing cache size limit for now.

@HebaruSan HebaruSan closed this as not planned Won't fix, can't repro, duplicate, stale Dec 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Enhancement New features or functionality
Projects
None yet
Development

No branches or pull requests

2 participants