Let's clarify what the supports relationship means.

[pjf]

The spec has a pretty short explanation for the supports relationship, which came out of #11.
It looks like we need this to be clarified, as KSP-CKAN/NetKAN#1565 shows there's at least two interpretations.

So, I'd like to clarify just what we mean when we use the supports relationship. To me, it's always meant "X works with Y" and in particular "X gives consideration to Y". Using the example which has just come up a mod might "support" the Community Tech Tree, meaning the author has specifically coded their mod to use the extra nodes if it's found to be installed.

At the same time, I think it's reasonable to say that the "Community Tech Supports X". Even though all the effort may have been done in X to ensure compatibility, if it was done in consultation with with the Community Tech Tree, then we'd expect the CTT not to change in a way that causes X to break.

Finally, I'd like to express a very strong preference for supports to remain an information-only relationship. Indeed, I can't imagine how it would work as anything else, since all our other bases are already covered in our relationship model (depends - you must install this mod; recommends - you should install this mod; suggests - you might consider installing this mod, supports - hey look, a mod!).

Discussion very much welcome. Tagging @dbent in particular, who's very much been in the front-line here.

[pjf]

For the record, I would also like to say that I think being able to show inverse relationships is a great idea, and may make some uses of supports redundant (although I would still argue it's not an error to see bi-directional supports relationships declared).

[dbent]

My main concern with supports bidirectionality is the expression of redundant information that will make metadata harder to keep on top on. If AwesomeMod is made to work with CommunityTechTree then when AwesomeMod gets added it will have a depends, recommends, suggests, or even just supports on CommunityTechTree. But then we'd also have to remember to update CommunityTechTree to keep that information useful; since the proposed use-case is that users will go to CommunityTechTree to see which mods work well with it.

To me that's not a metadata problem, since the relationship is already expressed, just in the opposite direction. Then it just becomes a UI problem about presenting it to the user, from which #1100 arises.

As for a non-informational (aka semantic) version of supports, here's my idea:

Quite a few mods will support another mod, but only if some third mod is also installed. A common situation in which this arises is with ModuleManager. A part pack may be perfectly fine to install without ModuleManager on its own. But if it wants to support a life support mod it needs ModuleManager installed. Typically this will be declared as the first mod, depends or recommends ModuleManager, but that relationship only exists for the sake of an optional support. With a semantic supports we could do something like:

{
    "spec_version": "v1.x",
    "identifier": "AwesomeMod",
    "supports": [
        {
            "name": "AmazingLifeSupport",
            "depends": [
                { "name": "ModuleManager" }
            ]
        }
    ]
}

That way, AwesomeMod can be installed just fine without ModuleManager. But here's the magic, now that CKAN knows about dependent supports relationships, upon installing AmazingLifeSupport, CKAN can also offer to (or automatically) say "Hey, we notice you're adding AmazingLifeSupport, AwesomeMod happens to support it, but we'd need to add ModuleManager is that OK?

[lOmicronl]

Throwing my two cents in, since it's kind of my 'fault' that this got started :P

I've described my interpretation of things in a bit more detail here, for documentation's sake: http://forum.kerbalspaceprogram.com/threads/52042-1-02-Near-Future-Technologies-%28All-packs-updated-to-1-02-Finally!%29?p=1998489&viewfull=1#post1998489

Note that while I'd like to have a field in which to do this, it doesn't absolutely have to be the 'supports' field if there's a good reason to do something else with it. It's just that, as I explained in the above link, the user cannot really collect the information 'what mods work well with this tech tree' by examining an arbitrary number of mods individually. By all logic and usability considerations, the tech tree itself should be able to provide that sort of information somewhere, and the 'supports' field as a purely informational field currently fills that role the best. Community Tech Tree is actually a very special case in that it expects other mods to set up support, but all other tech tree mods that exist or have existed actually do the part assignment themselves. For them, providing this information is even more important. Of course, this can be done by pointing the user towards the forum thread, which the CKAN client already does. But if there was a way to display it directly in the client, why not do that? Plus, CTT has another very special idiosyncracy in that regard... namely, I cannot use the forum thread to provide this information. The first post is Nertea's, I cannot edit it, and he's a super busy guy between all of his mods and RL. Maintaining the CKAN metadata, however, is something that I can do for him.

Regarding the 'makes relationships harder to maintain' part, that's kind of a non-argument from my point of view. It implies that relationships are perfectly tracked right now, which is not the case. A lot of mods are added by CKAN team members or bulk contributors, not the original mod authors, and while the contributors can make educated guesses about what the relationships should look like, they obviously cannot read the mod author's mind. Case in point, the metadata for Nertea's mods, which I set out to update, only had a small fraction of the relationships that Nertea and I thought they should have. Not something you can fault the contributor for, but it's incomplete nontheless. And then there are mods added to CKAN by the original mod authors that don't make use of any of the relationship fields at all, even though they easily could. Additionally, new mods get added to CAN all the time, and occasionally one will show up that makes sense to include in a relationship after the initial posting. For example, just today I came across a new contract pack that adds its own tech tree, thereby conflicting with CTT. This pack isn't on CKAN yet, but as there's a huge number of other ContractConfigurator packs already present, it's highly likely that it'll eventually make its way into the repository. If I notice, then I can update the relationship; if I don't notice, then I won't.

All of this implies that you cannot have the expectation that all relationships are ever fully complete or fully reliable. The only relationship field that is always guaranteed to be complete is the 'depends' relationship. For all others, you should in fact make the assumption that they are always incomplete, and the only way to move them towards a state of quasi-completeness is by actively maintaining the relationships (ideally done by the mod authors themselves). Therefore, having an information field where tech trees reference other mods does not intrinsically make the relationship metadata less reliable. It'll be just another optional field like all the others - probably includes some useful information, but also probably incomplete. If a tech tree does not properly fill out the information field, then that's not a problem of the CKAN specification... it's an optional field, after all! Like all the other relationships except 'depends'. As a purely informational field, it even does less damage (namely none) than when certain other fields (namely 'conflicts') are incomplete.

[pjf]

My day is crazy, so apologies for my very brief response.

Semantic Supports / Conditional relationships

This is a hard problem. We had something like it back in October 2014, but we removed in #209 because it's very hard to have "dependent installs" to act consistently, and we no longer had a guarantee that the same mods would install the same way every time. That was back in the days when a mod could contain optional components within itself, and luckily we're not doing that any more. :)

@dbent's suggestion here is different to and better than our old dependent installs, but it's still a tricky problem. If X recommends Z if Y is installed, then we can absolutely do the right thing if the user is installing both X and Y, or if the user is installing X and Y is already installed. The question is what we should do if the user has X installed, and later installs Y? In this case I think the answer is clear: we should recommend the user installs Z. In other words, if the user installs any mod we scan through all the existing relationships and see if any conditional relationships are now satisfied.

In this case, I'd suggest we'd expand the relationship syntax itself in general:

"depends" : [
    {
        "name" : "ModuleManager",
        "condition" : "AmazingLifeSupport"
    }
]

By having a conditions keyword (which we may give a better name to) that can apply to any relationship (conflicts,recommends,suggests,depends,supports). We can have two mods conflict if a third is installed, or a mod be a dependency if a third is installed, or even just recommend/suggest a mod if we spot a particular configuration. (I would have used @dbent's depends keyword, but I didn't want to use the same word twice. We definitely do want a richer syntax as per @bdent's example, so conditional relationships may depend upon versions, etc.)

That's pretty darn powerful. We'd need to hash out the syntax and details, but having dependencies on any relationship is going to give us a lot more power going forward than only having them available on the supports field, and potentially gives us extra goodness if and when we implement warnings (#211) and other relationship types.

Relationships and accuracy

All of this implies that you cannot have the expectation that all relationships are ever fully complete or fully reliable. The only relationship field that is always guaranteed to be complete is the 'depends' relationship. For all others, you should in fact make the assumption that they are always incomplete, and the only way to move them towards a state of quasi-completeness is by actively maintaining the relationships (ideally done by the mod authors themselves).

I'm totally out of time, but @lOmicronl pretty much hit my thoughts on the head here. Our metadata is always going to be in a state of flux, and we should be very generous in what we accept for informational and human-oriented fields such as supports and everything in resources.

Suggestions:

• We explore more fully the idea of having conditional relationships, in the form of @dbent's suggestions on steroids.
• We encourage the use of "supports" as being a human-oriented field. I'm expecting to see some variation in meaning of how that's used across mods.
• We implement the ability to show reverse relationships, because that provides rich information that would otherwise need to be imperfectly provided by hand.

Further discussion and telling me that I'm wrong absolutely encouraged. :)

[dbent]

Aye, I like the conditions idea and I'm fine with supports being human-oriented. But, I'm still wary of this bidirectionality, since it just means we've doubled the opportunity for the metadata to be incorrect or out of date.

To me, a bidirectional supports is the metadata equivalent of:

i++; // increment index by one

That is, redundant and extremely prone to decay once the actual behavior changes:

i+=2; // increment index by one

It's not that I'm unaware that metadata requires constant updates to keep accurate, it's that bidirectional supports makes it harder to accomplish that goal, and I don't see the utility after #1100 is implemented.

To be clear: I don't think bidirectional supports should be an erroneous condition, worthy of checking and breaking the build in CI, but I don't think its use should be encouraged.

[HebaruSan]

I think supports should mean "inverse suggests."

Any stronger relationship (i.e., install-by-default) belongs in the depending mod, but in the case where I do some dev in my mod to support RasterPropMonitor, it would be nice if my mod came up as a suggestion when RPM is installed. I'd say it makes sense for that relationship to live in my mod's metadata, since my mod is where the relevant code change happened; and RPM shouldn't have to know every single mod out there that works with it.

For a tech tree, same deal. ModX supports Tech Tree Y, so when you install TTY, you get the option to install ModX.

[7ranceaddic7]

10 cents from a non-technical, common-user, logophile view ...

depends = required
This mod contains parts, components or functionality which are controlled or determined by parts, components or functionality explicitly provided by OtherMod and will not function properly without.
Simply: Installing the other mod is required; I do not play nicely without.
Example: Back In Black depends on ModuleManager to function properly.

recommends = moar
This mod contains parts, components or functionality which are enhanced by parts, components or functionality provided by OtherMod but will function properly without.
Simply: Installing the other mod is suggested because it means this mod will be moar.
Example: TundraExplorer suggests RPM because it makes TE moar.

suggests = nice
This mod contains parts, components or functionality which complement parts, components or functionality provided by OtherMod.
Simply: Installing the other mod is nice; we play well together.
Example: RPM suggests VesselViewer because it makes RPM nicer.

supports = meh
This mod contains parts, components or functionality which are compatible with parts, components or functionality provided by OtherMod.
Simply: Installing the other mod is meh; whatever.
Example: TACLS supports Community Category Kit because, well, meh; whatever.

conflicts = fuhgeddaboudit
This mod contains parts, components or functionality which are incompatible with parts, components or functionality provided by OtherMod and will result in a total collapse of the Kerbverse, fuhgeddaboudit.

To me, suggests and supports are two sides of the same coin. Taken together they provide that bi-directional information. Suggests implies "I know they play nicely with me." Supports implies "I know I play nicely with them."

I think recommends, suggests and supports remain information-only fields and require explicit (select/deselect) user action. Additionally, the depends and conflicts should be the only fields that generate an action by CKAN.

The conditions idea is a good way to extend a required CKAN action into a user explicit action and it should also be an immediate prompt. (Kinda like installing RSS prompts for RSS textures.) This would force user action and they'd know that something is going to fail if they don't take action.

I'll leave y'all to herding the cats into using these they way you intend.

[politas]

It sounds like it might be good to have a "supporting mods" selection screen, similar to the "recommends" screen, but based on a reverse relationship lookup.
Maybe we could add some settings options to suppress those selection screens for people who know exactly what mods they want, thank you very much.

[HebaruSan]

I was thinking we could mix them into the existing suggestions/recommendations screens, defaulting to not install. Those lists are usually short enough, a few more unchecked checkboxes won't hurt anyone, and fewer steps/screens is generally better.

[politas]

Sure, with suitable descriptions of the relationships. We'd have to replace the "Recommended by" column with a "Why" column and prepend "recommended by/suggested by/supports" to the related mod name.

[HebaruSan]

After #2744, these are two distinct sections of one screen. We could easily add "Supports" or "Supported By" as a new section on the same screen, with no wasted UI space or confusion. 👍