[Feature]: Restore `auto-installed` state after installing exported mod list about ckan

[SunSerega]

All works in my case. What do you think about tracking the idea to somehow handle "auto-installed" with a particular "provides" choice in another issue?

[HebaruSan]

The .ckan file stores a CkanModule, with the mod list as relationships rather than InstalledModules, and this property lives in InstalledModule.auto_installed. There's no place to put this info in the data model.

One alternative would be to recalculate the auto_installed properties after installing by checking dependencies, but that is likely to run into difficulties with circular dependencies (both mods would think they're auto-installed because of the other depending mod, but if we marked both as such, then they'd be auto uninstalled).

[HebaruSan]

Another option is to exclude auto-installed mods from the .ckan file entirely. They'll have to be pulled in as dependencies anyway, and that would cause them to be marked as auto-installed the normal way. I think the reason we didn't do this was because it would be confusing and inconsistent if one of those relationships caused the user to be prompted to choose a provides mod and they made a different choice than the original modpack creator made. (And even for the same-user case, documenting such choices is a key part of making these files as reproducible as possible.)

[SunSerega]

Well, isn't it the case then that the data model doesn't serve its purpose here?

A mod (or mod-pack in this case) may need an indirect dependency but still require one specific choice from that possible provides list.

The simplest option I see is extending RelationshipDescriptor with an Indirect field.
Also had a more future-proof idea, but it left my head as fast as it appeared... Oh well.

And if it comes to this, I suggest changes to the export menu:

1. Auto-installed mods (or at least those with no provides alternatives at the moment) be initially put in Ignored rather than Depends. If provides alternatives appear later, the mod-pack author can just install their own mod-pack, make the choices, and re-export it;
2. Add checkmark column Indirect with values initially copied from the Auto-installed column.

[HebaruSan]

Well, isn't it the case then that the data model doesn't serve its purpose here?

No, not really. But that's not the point, either. The point was to explain why it is the way it is, that it's not a simple oversight or error but a structural limitation. Understanding that is the foundation for changing how a feature works.

The simplest option I see is extending RelationshipDescriptor with an Indirect field. Also had a more future-proof idea, but it left my head as fast as it appeared... Oh well.

I don't quite understand what you're going for there. There's nothing "indirect" about these relationships...? And it's not at all clear what that field would mean.

1. Auto-installed mods (or at least those with no provides alternatives at the moment) be initially put in Ignored rather than Depends. If provides alternatives appear later, the mod-pack author can just install their own mod-pack, make the choices, and re-export it;

Yeah, that's probably how we would do the second option I mentioned, rather than just omitting them completely. This still has the same complications, though.

2. Add checkmark column Indirect with values initially copied from the Auto-installed column.

Any particular reason to call it that, rather than using the same existing familiar name for the same info from the mod list?

[SunSerega]

I meant "indirect" as in "indirectly depends". In other words, a dependency that is required for another dependency, but not directly for the original mod/mod-pack.

Any particular reason to call it that, rather than using the same existing familiar name for the same info from the mod list?

Alright, I agree my naming sense is not very good, but "auto-installed" in this case would be even less meaningful, as the whole point of exporting a .ckan file is to install multiple mods in one move, automatically without manually re-iterating them every time.

[HebaruSan]

@SunSerega, if you'd like to test this out, there's a test build here under the Artifacts dropdown:

• https://github.com/KSP-CKAN/CKAN/pull/3978/checks