Mod compatibility state changed after updating CKAN

[4x4cheesecake]

Background

CKAN Version:
1.26.0

KSP Version:
1.6.1

Operating System:
Win 10 x64

Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
No

Problem

What steps did you take in CKAN?
Updated CKAN to 1.26.0 and selected a KSP install which was previously managed by CKAN 1.25.4.
KSP 1.4, 1.5 and 1.6 are set to be compatible KSP versions (first three checkboxes in the list)
I use the same settings for my career game and a testing game (both are KSP 1.6.1)

What happened
I've noticed a difference in the number of compatible, cached and incompatible mods between different KSP instances. For my career game, CKAN shows 987 compatible mods, the testing install shows 994 instead.
The career game was previously managed by CKAN 1.25.4 and the testing install was re-added to CKAN after updating to CKAN 1.26.0 (I removed the testing install from the list of managed KSP instances and deleted the CKAN folder from the KSP install directory, then readded the install)

How to replicate the issue
This can be replicated on fresh KSP installs and with default CKAN settings (no additional compatible KSP versions):

• Get two fresh copies of KSP 1.6.1
• Run CKAN 1.25.4 on one of these installs and check the number of compatible mods (at this time, it shows 526)
• Run CKAN 1.26.0 on the other KSP install and check the number of compatible mods as well (at this time, it shows 529)

Screenshots:

Fresh KSP 1.6.1 install with CKAN 1.25.4 (default settings):

Fresh KSP 1.6.1 install with CKAN 1.26.0 (default settings):

KSP 1.6.1, previously managed by CKAN 1.25.4, 1.4, 1.5, 1.6 are set to be compatible KSP versions, after updating to CKAN 1.26.0:

KSP 1.6.1, 1.4, 1.5, 1.6 are set to be compatible KSP versions, re-added to CKAN after updating to 1.26.0:

[DasSkelett]

This is probably due to our new replaced_by relationship.
CKAN v1.25(.4) can't handle it, so it just hides those mod versions (see KSP-CKAN/NetKAN#7027 (comment)). v1.26 can handle them and thus reports a higher number of compatible mods.
Scratch that, that can't be the problem.
Or it could be.

[DasSkelett]

If I run CKAN v1.25.4 first and v1.26 afterwards (with repo update!), I get a difference of 4 mods (I think this depends on the other mods installed), marked as incompatible in v1.25 and compatible in v1.26:

All of those four mods have a v1.26 spec version in their metadata, the first one for the replaced_by property, the other three because of depends any_of.

Those four are marked as incompatible because that's what CKAN does if the spec version is 'too high' .
Just refresh once in CKAN v1.26 and you should get the higher, correct number.

[4x4cheesecake]

Those four are marked as incompatible because that's what CKAn does if the spec version is 'too high' .
Just refresh once in CKAN v1.26 and you should get the higher, correct number.

So this is an intended behaviour caused by these new properties?
But still, updating the repository does not changes anything on a install which was previously managed by CKAN 1.25.4. I've tried to describe and replicate the issue in a general way but I've also describe a specific case about AVP in the forum thread:
https://forum.kerbalspaceprogram.com/index.php?/topic/154922-ckan-the-comprehensive-kerbal-archive-network-v1260-baikonur/&page=67

Yes, I know that I've told some other poeple that this is caused by EVE but in this case, it doesn't show up even though 1.4, 1.5 and 1.6 are set to be compatible versions:

Refreshing the repository does not fix this issue, just reinstalling/reinitializing CKAN helps but every installed mod will be marked as 'AD' in this case.

[DasSkelett]

To reinstall, follow the 'Clean and reinstall process', this saves you from getting your mods marked as AD.

It's strange that refreshing in v1.26 doesn't fix the counter, it always does so on my system.
Regarding AVP, do you have another mod installed that conflicts with any of AVP's dependencies?

[4x4cheesecake]

Ok, I did a clean reinstall by following the instructions and after uninstalling every mod, AVP became compatible. So I've tried some stuff and you are actually right, there is a mod conflict with scatterer but it is still a little bit odd.

With scatterer installed, the relationships tab doesn't show a conflict:

Without scatterer installed, it is possible to extend the list:

Well, scatterer depends on "scatterer - sunflare" and "scatterer - default config", so basically: AVP depends on scatterer, which depends on some configs, which conflict with AVP.
This brings up the question, why the conflict is not displayed in CKAN and a KSP version incompatibility is displayed instead of a mod conflict while trying to install the AVP textures, which depend on AVP:

Also, it is weird that this mod conflict doesn't appear with CKAN 1.25.4. Even while scatterer is installed, AVP is still displayed as compatible and installs fine. As far as I can tell, neither AVP nor scatterer uses one of the new properties in their metadata. Please, check it on your own, just to be sure.
(KSP 1.4, 1.5 and 1.6 are always set as compatible KSP versions.)

[DasSkelett]

Okay, thanks for the investigation. This really looks a bit weird.
Needs looking into it.

[HebaruSan]

The sunflare/sunflare conflict is a red herring. That's just how the metadata indicates that you should only have one module providing that virtual module (other modules can provide a sunflare for Scatterer, and you have to pick only one).

[HebaruSan]

updating the repository does not changes anything

If updating the registry does nothing, it's possible that #2682 is confusing things. 1.26.0 won't re-download the registry if it thinks there haven't been any changes since the last time. It would be easy to run into that unless you knew about that change and were very careful about the order in which you did things.

[HebaruSan]

So this is an intended behaviour caused by these new properties?

Most likely, yes. Versions of CKAN prior to 1.26.0 cannot install modules with any_of dependencies or a replaced_by property. For the four modules highlighted by @DasSkelett, their only other versions (i.e., without any_of or replaced_by) are for KSP 1.3 or earlier. So yes, if your compatibility is set for KSP 1.4 and later, those mods would appear and disappear depending on the version of CKAN you used.

So is there a problem remaining to fix here, or does the above explain it?

[4x4cheesecake]

If updating the registry does nothing, it's possible that #2682 is confusing things. 1.26.0 won't re-download the registry if it thinks there haven't been any changes since the last time.

After setting 1.3 and later to be compatible KSP versions, I'm no longer getting different results for the number of compatible mods so I assume #2682 works fine and it is just caused by the new properties.

So is there a problem remaining to fix here, or does the above explain it?

I'm still a bit confused by the conflict between scatterer and AVP. It is not displayed as a conflict but if you install just scatterer, AVP becomes unavailable/conflicting while it is fine to install scatterer as a dependency together with AVP. The sunflares and default config of scatterer are also installed automatically if you select just AVP for installation. There shouldn't be any difference between "install scatterer + AVP" and "install AVP + dependencies", or am I still missing something?

[HebaruSan]

if you install just scatterer, AVP becomes unavailable/conflicting while it is fine to install scatterer as a dependency

Yeah you're right, there's something odd going on there. Thanks for explaining it again; I think I interpreted this as just being about the self conflict relationships shown in the tree.

[HebaruSan]

Scatterer's self-conflict relationship trips this check:

CKAN/Core/Registry/AvailableModule.cs

Lines 123 to 133 in 2119b58

	if (module.conflicts != null)
	{
	foreach (RelationshipDescriptor rel in module.conflicts)
	{
	// If any of the conflicts are present, fail
	if (rel.MatchesAny(others, null, null))
	{
	return false;
	}
	}
	}

... but only when it's installed, via this block:

CKAN/Core/Registry/AvailableModule.cs

Lines 99 to 102 in 2119b58

	if (installed != null)
	{
	modules = modules.Where(m => DependsAndConflictsOK(m, installed));
	}

... passed from here:

CKAN/Core/Registry/Registry.cs

Lines 708 to 713 in 2119b58

	.Select(am => am.Latest(
	ksp_version,
	relationship_descriptor,
	InstalledModules.Select(im => im.Module),
	toInstall
	))

... while checking dependencies for compatibility here:

CKAN/Core/Registry/Registry.cs

Lines 537 to 541 in 2119b58

	if (!dependency.MatchesAny(null, InstalledDlls.ToHashSet(), InstalledDlc)
	&& !dependency.LatestAvailableWithProvides(this, ksp_version).Any())
	{
	return false;
	}

So the self conflict is the proximate cause, and we need to be a bit smarter somewhere in the above trace.