Discussion: Solving CKAN dependencies for B9 Procedural Wings Fork

[Lisias]

[Moderator note:  This thread was split off from the B9 Procedural Wings Fork thread, due to a lengthy digression into a debate over the best technical way to solve certain problems with CKAN.  Since this discussion got off the topic of B9PW itself and more into CKAN and software engineering philosophy, it's been moved off into its own topic.]

On 12/15/2020 at 9:51 AM, Me1_base said:

Situation 1 : only B9PW installed >> success

Situation 2 : installed both B9PW and MJ >> fail

Situation 3 : installed FAR, MJ and B9PW >> success

So, in a nutshell, to solve something that affects MechJeb CKAN added a soft dependency to PW as it would be a hard one (FAR)? Even by FAR being not compatible with some other add'ons that would cope fine with PW?

No one ever considered a CKAN Plugin to handle these idiosyncrasies?

 

On 5/12/2021 at 9:46 PM, HebaruSan said:

@linuxgurugamerplease investigate the history of things before you change them. This was added because people were having problems without FAR with the current fork:

He did. And he took the most reasonable solution from the developer's point of view. We don't shove unneeded dependencies on a product to fix problems on another one!

I understand the problem CKAN had to solve at that time, but that solution created new problems for other people (otherwise LGG would not had did it). What suggests we need a better solution on the long run.

Edited May 15, 2021 by Snark
Split by moderator from another thread

[HebaruSan]

Quote

No one ever considered a CKAN Plugin to handle these idiosyncrasies?

Please don't throw out [suggestions] Users will think that some obvious solution exists and is not being pursued, when in fact there is no such thing and the thing you're referencing isn't even relevant.

Edited May 14, 2021 by Vanamonde

[Daniel Prates]

On 5/12/2021 at 6:53 PM, linuxgurugamer said:

Oh sorry.  I was going on the recent comments that FAR wasn't a dependency

 

Maybe it's ripe for an adoption?  I will look into creating the organization you suggested

 

The OP says it isn't a dependancy. [snip] I did remove FAR and it made no difference whatsoever.

Edited May 14, 2021 by Vanamonde

[Vanamonde]

Some comments have been removed. Please don't make it personal, guys. 

[Lisias]

9 hours ago, HebaruSan said:

Please don't throw out [suggestions] Users will think that some obvious solution exists and is not being pursued, when in fact there is no such thing and the thing you're referencing isn't even relevant.

Users SHOULD think that other solutions must exist and/or are being pursued. Otherwise they will ditch CKAN, as some (pretty good) Add'On authors did in the past.

If no such thing I referenced exists (and if it doesn't exists, how I referenced it?), I strongly suggest someone implement it.

FAR changes fundamental behaviours on KSP that the user willing to use PW probably don't want to have them changed (I'm one of them - I have one and only one instalment for toying with FAR, but many with PW).

Edited May 14, 2021 by Lisias
Hit "save" too soon.

[HebaruSan]

The long-term solution is a stable fork of this mod that doesn't have weird dependency quirks. The ball is rolling on that thanks to @linuxgurugamer. The rest is moot.

[Lisias]

21 hours ago, HebaruSan said:

The long-term solution is a stable fork of this mod that doesn't have weird dependency quirks. The ball is rolling on that thanks to @linuxgurugamer. The rest is moot.

But you can't just ignore the breakage you are promoting in the mean time - [snip]

FAR is not compatible with a lot of add'ons that would work fine with PW.

IGUIPlugin exists, it's working and can be used to add features to the main CKAN - so it's relevant.

And the code that does this trick is here. This is a Proof of Concept of something that can be implemented to check the current installment for the Add'Ons that triggers a problem (MechJeb2 and B9PW on this case), and so alert the user that he should install something else too (FAR, on this case). This solution would be WAY more sensible than just shoving FAR on everybody that installs B9PW - FAR changes the game physics in drastic ways, you are screwing up savegames from people that don't want to use FAR.

Edited May 15, 2021 by Vanamonde

[HebaruSan]

@Lisias, what you are suggesting would not even begin to address this problem at all. Firstly, your idea is that somehow, every CKAN user who wants to use B9 Procedural Wings Fork and MechJeb together, would first install a random CKAN plugin from somewhere else? How would any users know that they needed to do that? The answer is that they would not know, they would not install it, and their game would freeze. Then they would come to this thread, again, to report the problem, and in your hypothetical scenario, they would be told: install this plugin. What does it do, they ask? Does it patch the game so it won't freeze? No, it just shows a popup when you try to do the thing you've already done that froze your game. Oh, they say, that's not very helpful to me; it's too late and you just explained the dependency anyway. It's not a solution.

Second, your example code just displays a popup. It does not change the relationship resolver or the installer to alter the way that they handle dependencies. That code is pretty complicated, and I'm skeptical that it could be modified correctly and reliably with a plugin. Granted, reflection is a very powerful tool, but even it has its limits. At this level of complexity, it would be simpler to work on a patch for the core code instead of a plugin (but that would have a similar problem in that users would have to install a new CKAN version to get those changes).

I don't know why you're spending your time on this [snip]. A fork of a mod has a dependency quirk that froze the game for several users; we updated the dependencies in CKAN to prevent that from happening, with the expectation that the problem with the mod would be fixed (which is now in progress behind the scenes), and then the dependencies would be updated again in CKAN. Yes, some people don't want to use FAR, but many people do want to use MechJeb, and everyone is free to use or not use mods as per their own preference. [snip]

Edited May 15, 2021 by Snark
Redacted by moderator

[Lisias]

On 5/14/2021 at 10:30 AM, HebaruSan said:

@Lisias, what you are suggesting would not even begin to address this problem at all. Firstly, your idea is that somehow, every CKAN user who wants to use B9 Procedural Wings Fork and MechJeb together, would first install a random CKAN plugin from somewhere else?

 No, sir. I'm proposing a CKAN plugin to handle the current weakness of CKAN to be unable to handle the present situation - that it's not the only one, as I had to certify KSP-Recall to allow it to be installed on KSP versions it was not intended to run exactly because this weakness.

We have conditional dependencies that can or cannot be necessary depending of the current user's rig state. On this specific case, FAR is a workaround needed only when MechJeb is installed at the same time B9PW is (Recall have different rules - but that can be worked out similarly by using the KSP version as a "add'on" to be checked).

Given the current notoriously resistance on implementing new features on CKAN itself, writing a plugin for it would reach the same end-result.

 

On 5/14/2021 at 10:30 AM, HebaruSan said:

Second, your example code just displays a popup. It does not change the relationship resolver or the installer to alter the way that they handle dependencies. That code is pretty complicated, and I'm skeptical that it could be modified correctly and reliably with a plugin. Granted, reflection is very powerful tool, but even it has its limits. At this level of complexity, it would be simpler to work on a patch for the core code instead of a plugin (but that would have a similar problem in that users would have to install a new CKAN version to get those changes).

The PoC proves that you can change CKAN's behaviour using a plugin, so the IGUIPlugin is relevant to the question. What do  you expected, that I would solve the problem in a couple hours?  I was rebating your argument, where you wrongly stated that IGUIPlugin was not relevant.

No reflection was needed, the hooks that can be used to inspect what's happening are available to be used - [snip] no reflection was used at all.

 

On 5/14/2021 at 10:30 AM, HebaruSan said:

I don't know why you're spending your time on this

I'm being vocal and incisive about a terrible decision made by CKAN, injecting on everybody that uses B9PW unwanted and unneeded dependencies that changes critical behaviour of the game (with consequences on savegames) to workaround a temporary problem that affects only a few use cases.

Edited May 15, 2021 by Snark
Redacted by moderator

[HebaruSan]

On 5/14/2021 at 4:12 PM, Lisias said:

 No, sir. I'm proposing a CKAN plugin to handle the current weakness of CKAN to be unable to handle the present situation - that it's not the only one

Quote

We have conditional dependencies that can or cannot be necessary depending of the current user's rig state. On this specific case, FAR is a workaround needed only when MechJeb is installed at the same time B9PW is

OK, first, that's a "Yes", not a "No". Your suggestion would only help users who installed this CKAN plugin that you are imagining. It would do nothing for anyone else. So you would first have to solve the problem of how to get the right users to install it. The funny thing is, if you knew which users those were, you could forget the plugin: you could simply warn them in advance that if they want MechJeb, they also need to install FAR. A plugin just doesn't fit this use case.

Of course the dependency on FAR is a workaround, based on the problems people were having with this mod. It was stated that way up front, and no one has said otherwise. Sometimes a workaround is an appropriate solution when there is nothing better on the table.

Quote

The PoC proves that you can change CKAN's behaviour using a plugin, so the IGUIPlugin is relevant to the question. What do  you expected, that I would solve the problem in a couple hours?  I was rebating your argument, where you wrongly stated that IGUIPlugin was not relevant.

Quote

No reflection was needed, the hooks that can be used to inspect what's happening are available to be used - [snip] no reflection was used at all.

But you rebutted nothing. I know perfectly well that CKAN has a framework for client plugins. I did not need that proven to me. The question is whether that plugin framework could be used to solve the problem with this mod. I, as a person who has been up to my elbows in the guts of CKAN for three+ years at this point, think that it probably could not. You, as someone who just started looking at this, have opted to ignore [snip] my assessment and claim not only that it could, but that everyone else was negligent for failing to agree with you. Well, the only thing that will settle that is if someone does actually solve it that way. But as I already explained (and as I hope you are beginning to comprehend), there's no point in even attempting that, because even a technically perfectly written plugin would not address the problem of distributing the plugin to every CKAN user (or a somehow narrowly targeted group of just the CKAN users who need it, which is impossible to identify).

I mentioned reflection because in order to change how the relationship resolver and installer work, you would have to rip out and replace big chunks of CKAN. They are used from many places in many different ways, and just making a popup that says "Don't use these two mods together without this third mod, until an update comes out, we don't know when" would do nothing to actually stop the user from installing like that. When I was typing my reply about how this would be complicated to do, I could anticipate that you would [bring up] the powerful C# tools that you know about that would handily do the job, with reflection at the top of the list. So I decided to pre-emptively address the possibility of using reflection and the low likelihood of that attempt succeeding. Obviously your sample code doesn't use reflection, it's just showing a pop-up.

Finally, let's cover the achilles heels of CKAN plugins: compatibility and versioning. CKAN's internals change freely from one version to the next, so there is no guarantee that a plugin that works on one version will work on the next version. So you would spend all this effort developing a CKAN plugin, getting thousands of people to download it and install it, and then when a new CKAN release comes out and those users upgrade, it would either stop working or crash CKAN. (This is why there are currently no popular, widely used CKAN plugins; compatibility tracking was somehow left out when this feature was added, before I joined.) Again, knowledge of how CKAN plugins actually work goes against your suggestion.

Quote

I'm being vocal and incisive about a terrible decision made by CKAN, injecting on everybody that uses B9PW unwanted and unneeded dependencies that changes critical behaviour of the game (with consequences on savegames) to workaround a temporary problem that affects only a few use cases.

You are free to have whatever opinion you like about the choices that other people make in difficult no-win situations, but I am also free to ask you to please stop spreading misinformation and insinuating that there is some sinister plot or malfeasance under way. We are all just trying to make things work here, and frankly you are not helping those efforts.

Quote

, as I had to certify KSP-Recall to allow it to be installed on KSP versions it was not intended to run exactly because this weakness.

Quote

(Recall have different rules - but that can be worked out similarly by using the KSP version as a "add'on" to be checked).

(Fair enough, comment removed.) Yes, it's quite true that CKAN doesn't support conditional dependencies. But I don't know why you  characterize this as "notoriously resistance on implementing new features on CKAN". That's simply wrong. I personally have implemented many new features in CKAN (many more bug fixes, naturally), some in just this past month. The truth is that no one has attempted to implement this new feature yet. That's why it doesn't exist. With any given version of the CKAN client, we have some tools available to solve problems and not others. And since no one has implemented conditional dependencies yet, unconditional dependencies are one of the remaining tools in the toolbox for addressing problems. They exist, and they work.

Edited May 15, 2021 by Snark
Redacted by moderator

[DasSkelett]

44 minutes ago, Lisias said:

Given the current notoriously resistance on implementing new features on CKAN itself

This is simply not true. Fullstop.
We are implementing new features all the time in CKAN. And yes, we even discussed and thought about conditional dependencies again after our recent discussion with you. We might implement them at some point. But the relationship resolver is huge and complex, something like this can't be done from one day to another, it takes a lot of work. And somebody needs enough time and motivation to do it. YOU as a mod author should really know this.
Nobody every said that we won't implement this feature in CKAN, did we? Instead, we all agreed on adding the KSP-Recall dependency, and only afterwards you came to us, starting a discussion about new CKAN features and what not.
However we are here to discuss fixing B9PW, not KSP-Recall.

44 minutes ago, Lisias said:

What do  you expected, that I would solve the problem in a couple hours?

You talked like you, or we, could. But we can't.

44 minutes ago, Lisias said:

I was rebating your argument, where you wrongly stated that IGUIPlugin was not relevant.

It isn't. You don't fix the relationship resolver through a GUI plugin. At the very least because it could only be used by GUI users, and leave out all commandline and console UI users.
Dependencies resolving differently depending on which UI the user uses to interact with CKAN? That sounds like debug hell, you have to admit that.

44 minutes ago, Lisias said:

I'm being vocal and incisive about a terrible decision made by CKAN, injecting on everybody that uses B9PW unwanted and unneeded dependencies

It's been a long time ago, so I might misremember. But I don't think we knew that this only affected users who also had MechJeb installed. If you look at what @HebaruSan wrote back then:

On 12/14/2020 at 8:56 PM, HebaruSan said:

Regarding the current problems, it sounds like there is a consensus that the @tetraflon fork has a dependency on FAR. Unfortunately this was not disclosed in any form that the CKAN team could see, so it was not reflected in CKAN either. CKAN does not figure out dependencies automatically, but instead relies on mod authors to indicate them, and all we had was the linked pull request and SpaceDock entries you see above, which made no mention of FAR. I will go add in the FAR dependency now that it has been identified and communicated to us. Obviously some players prefer not to use FAR, but we can't leave a FAR-depending version listed without that dependency; we will remove it if there is a new release that doesn't need it.

For all the CKAN team knew and with the amount of users mentioning problems in this thread, it affected all of B9PW. Yes, going backwards I can see that we could've gotten the idea that it only affects MJ users, but we simply didn't understand it that way back then. Since there was no separate forum thread for this fork where we could have gotten clear information, and honestly the whole fork situation being a big mess (it still is, really), that's all we could do.

Edited May 14, 2021 by DasSkelett

[Lisias]

3 hours ago, DasSkelett said:

We are implementing new features all the time in CKAN. And yes, we even discussed and thought about conditional dependencies again after our recent discussion with you. We might implement them at some point. But the relationship resolver is huge and complex, something like this can't be done from one day to another, it takes a lot of work. And somebody needs enough time and motivation to do it. YOU as a mod author should really know this.

And exactly how do you intent to motivate people to work with you on this problem?

 

3 hours ago, DasSkelett said:

Nobody every said that we won't implement this feature in CKAN, did we? Instead, we all agreed on adding the KSP-Recall dependency, and only afterwards you came to us, starting a discussion about new CKAN features and what not.
However we are here to discuss fixing B9PW, not KSP-Recall.

KSP Recall was engineered since the inception to allow this, as I had foresaw people would take the easiest route to just install it on everything. But yet, a user complained about having it installed without needing it.

The present case of B9PW is different, FAR really changes significantly the game experience when installed. Living crafts on the savegame will not work as the user had designed it, this is going to break savegames.

[snip]

Edited May 15, 2021 by Snark
Redacted by moderator

[HebaruSan]

3 hours ago, Lisias said:

installed without needing it.

Frankly, you're creating unnecessary [snip] problems for other people there. When a mod of yours needs one of the workarounds from your workaround mod, on any game version, you could just say that the workaround mod is a dependency. No one needs to know about the version specific details, and the mental load of installing of your mods would be lower for manually installing users, since they would not have to worry about what game version they have or what your conditional dependency listing says for that version.

Edited May 15, 2021 by Snark
Redacted by moderator

[DasSkelett]

24 minutes ago, Lisias said:

And exactly how do you intent to motivate people to work with you on this problem?

I'm not sure how I should understand this question.
I don't think I could motivate anybody outside the CKAN core team to work on this feature. It is a huge effort, and requires deep knowledge of CKAN's relationship resolver. Anyone not already familiar with it would likely have to spend a lot of time figuring out how it works, before they could get to work. And no, this is not because the code is written badly or anything, it's just complex in its nature (I don't know any other package manager that has such an exhaustive resolver, and I've seen quite a lot, being a full-time Linux user).

I'm pretty sure this one's on us, me and/or @HebaruSan. And right now, you are doing your best to demotivate us from working on it.

24 minutes ago, Lisias said:

KSP Recall was engineered since the inception to allow this, as I had foresaw people would take the easiest route to just install it on everything. But yet, a user complained about having it installed without needing it.

I'm sorry for that user. But as a developer, you sometimes have to weigh the importance of user complaints. And frankly, a <100 KiB unnecessarily installed mod that does nothing when installed doesn't really warrant dropping everything else and spending days to weeks on a difficult new feature.
Don't take me wrong, this is still a feature I'd love to see in CKAN, but it's not enough to prioritize it over everything else.

24 minutes ago, Lisias said:

The present case of B9PW is different, FAR really changes significantly the game experience when installed. Living crafts on the savegame will not work as the user had designed it, this is going to break savegames.

Totally agree with that. And yes, this case makes such a new feature more valuable. But aside the fact that we didn't know that it only was a conditional dependency back then (as mentioned above), we hoped that this was just a temporary bug that would be resolved quickly in the next release of the mod. Nobody knew it would stay around that long. And truth is, I still hope that this gets fixed "upstream" rather soon, especially now that there's work on a unified repository where all interested devs can contribute to.

Edited May 14, 2021 by DasSkelett

[HebaruSan]

1 hour ago, DasSkelett said:

It is a huge effort, and requires deep knowledge of CKAN's relationship resolver. Anyone not already familiar with it would likely have to spend a lot of time figuring out how it works, before they could get to work.

I'm pretty sure this one's on us, me and/or @HebaruSan.

I wonder if we could get a GSoC intern. 

[Snark]

This thread has been split from the B9 Procedural Wings Fork thread, as the discussion about "what's the right way to solve this sort of dependency issue in CKAN" wandered far off topic for that thread and was derailing it.  It was split from here:

 

An important note:  Yet again we've had to go in and remove personal remarks, after Vanamonde's previous admonishment not to do that.

Look, folks, we understand that this is clearly a highly contentious thread, and that people (understandably) feel strongly about software that they've worked on, or which they use for their mods, or which affects many other users.  It's perfectly fine to have lively debate.  But, as Vanamonde already said above, please do not make things personal.  Debating technical points is fine, but making personal observations about other people's character, or their tone, or what you infer their motivations to be, or the like-- that's out of bounds, folks.  It's always been out of bounds here in the forums.

So please, don't do that.

Thank you for your understanding.

[EDIT] And to be clear... if you have any questions or concerns about moderating, please approach the moderator team privately about it.  Public discussion of moderation is out of bounds, per forum rules 3.3. and 3.4.  Thank you.

[linuxgurugamer]

15 hours ago, DasSkelett said:

15 hours ago, Lisias said:

KSP Recall was engineered since the inception to allow this, as I had foresaw people would take the easiest route to just install it on everything. But yet, a user complained about having it installed without needing it.

I'm sorry for that user. But as a developer, you sometimes have to weigh the importance of user complaints. And frankly, a <100 KiB unnecessarily installed mod that does nothing when installed doesn't really warrant dropping everything else and spending days to weeks on a difficult new feature

I’ve lost count of the complaints about the ToolbarController and ClickThroughBlocker.  Users don’t understand software development, these sorts of complaints just come with the territory

[Lisias]

Users only understand about their own problems, and we start to get problems when we are the source of their problems.

Users don't mind coping with some problems if they understand this is the best you can do at the moment, but they start to get really annoyed when they perceive it as a way to make your life easier at their expenses - you start creating problems for your users, they will replace you at the first opportunity they manage to find. It's simple like that.

(and keep in mind that for each user that complains, there're a lot that just give us the finger and go away).

Shoving unnecessary dependencies to make your life easier is not a good strategy to solve problems - it may be a valid last-resource/last-minute workaround, but you expand the surface of attack for problems that just would not happen otherwise.

Not to mention forcing the users to cope with things they don't need and don't want.

FAR changes drastically the way the game behaves, it's not even something that can be easily deactivated.

Forcing FAR as a dependency was a bad move. You are affecting negatively B9PW users, and B9PW itself.

Edited May 16, 2021 by Lisias
Grammars... (sigh)

[HebaruSan]

14 hours ago, Lisias said:

to make your life easier

This is an inaccurate characterization of the motivation behind that change.

[Lisias]

1 hour ago, HebaruSan said:

This is an inaccurate characterization of the motivation behind that change.

This is an utter misinterpretation about what I had said. Please read it again:

Quote

but they start to get really annoyed when they perceive it as a way to make your life easier at their expenses

(emphases are mine)

Users can get a lot of "abuse" when they believe you are doing the best you can. That fine white pieces of paper hits the turbo-fan when they start to believe you are not.

Perception, dude. It's about perception and empathy. (and perhaps a bit of text comprehension?)

Edited May 16, 2021 by Lisias
perhaps some text comprehension?

[HebaruSan]

1 minute ago, Lisias said:

Users can get a lot of "abuse" when they believe you are doing the best you can. That fine white pieces of write paper hits the turbo-fan when they start to believe you are not.

Perception, dude. It's about perception and empathy.

I hope you are trying to think of ways to help us with these problems.

[HebaruSan]

Hi everyone!

Since there has been a lot of discussion about CKAN and B9 Procedural Wings Fork lately, I thought it might help to provide more details about what went on. Let's call it "Transparency II"; you can read the first edition here to catch up:

First, some background. The CKAN team takes the integrity of our users' game installs very seriously. After all, we are users; we're a small group of fans of Kerbal Space Program like you who have chosen to dedicate a portion of our waking hours to maintaining and improving this tool for the benefit of others. Since we don't want some automated tool messing up our own games, we know no one else wants that either. As a general rule, a CKAN user ought to be able to feel safe to experiment and try whatever mods from the list that they think sound interesting, and their game should start up without crashing or freezing.

Most of the time, that means installing mods exactly as intended by mod authors. Some folks may not know that every time we add a new mod to CKAN, we review (if each exists) the SpaceDock page, the GitHub repository, the forum thread, the contents of the download ZIP itself, installation instructions wherever we can find them, and whatever other resources might be linked from any of those, trying to gather all the clues we can about the correct way to install that mod. That's why you sometimes see me posting "I'm reviewing this for addition to CKAN" in new mod threads; it generally means a mod author clicked "Add to CKAN" in SpaceDock, and we need to double check something before proceeding. Then we create or update a pull request on GitHub, which applies all of the automated checks that we have been able to think of to catch errors or questionable things, which may lead to further changes, and so on until it looks right, and only then does that metadata go out to users.

Less often, protecting the integrity of users' games may also mean working around problems with specific mods. If installing a mod as documented results in a crash because of something the mod author didn't notice or anticipate, it's really not cool to leave a hand grenade like that lying around in the CKAN mod list, waiting to be stepped on. Again, users should feel safe to experiment, so we try to identify and prevent invalid installations when we can. If it's a missing conflict or dependency, we can add it; if it's something with a file path, we can tweak it; if it's version compatibility or sequencing or whatever else, there are usually tools to solve it.

Unfortunately and to our dismay, beginning December 3, 2020, CKAN was not living up to that standard. On December 14, 2020, I was notified that there was a problem and read these posts describing it:

The pattern was clear: If you installed the currently indexed fork of B9 Procedural Wings Fork alongside MechJeb and without FAR, due to a coding quirk in that fork of the B9PW mod, the game would not load. (Fellow CKAN team member @DasSkelett has suggested elsewhere that we may not have known about MechJeb's role in the issue, but I think I did understand it.) CKAN was leading some users into a crash with no guard rails. This was unacceptable; something had to be done.

Ninety-one minutes after I was tagged in the mod thread, I announced and implemented a workaround intended to prevent users' games from freezing on load (the announcement was that first post I linked above). Since that change, reports of crashes and freezes on the B9 Procedural Wings Fork thread have dried up. In other words, the good news is that the workaround has been working.

Now on to the details of the problem and the workaround. The problematic combo of mods was:

• B9PW + MJ

The working combos were:

• B9PW
• B9PW + FAR
• B9PW + MJ + FAR

This is a severely thorny problem. It's not a simple conflict with MJ, because installing FAR makes it work again; it's not a simple dependency on FAR, because uninstalling MJ makes it work again. It's a hybrid between a dependency and a conflict, maybe better thought of a "conditional dependency", which cannot be represented by CKAN's data model. It's important to note here that this was unintentional; the maintainer of the affected B9PW fork did not mean for these combinations of mods to work and not-work, so they would never have come to us and requested a conditional dependency, and creating a conditional dependency was not the envisioned end-state for how it was all supposed to work. Even if conditional dependencies were supported by the current CKAN client, they would only have been used as a temporary workaround here, to be removed when the underlying problem in the mod was fixed. It was just the luck of the draw that it turned out that way (and a crack team of modders is working on fixing it in the mod's code right now).

Our choices were:

1. Do nothing - Unacceptable, users' games are freezing, and CKAN is partly to blame
2. Create a CKAN GUI plugin - This would not solve the problem, as previously explained
3. Create a conditional dependency that would pick out just the one problematic mod combo and block it - This is not supported by the CKAN client that our users are using, and adding it as a feature could be done, but not in time to help people whose games are crashing now or in the near future, and it would require all those users to upgrade their CKAN clients to get the new dependency handling logic
4. Add a conflict with MechJeb - Upsetting to MechJeb users
5. Add a dependency on FAR - Upsetting to users who don't want to use FAR

Options 1, 2, and 3 can be ruled out at a glance, as they either don't solve the problem or aren't possible to implement in a responsible amount of time (users' games are crashing right now, and more are likely to come along every day!). Which left us with the choice between option 4 and option 5.

Adding a conflict with MechJeb would allow these combos:

• B9PW
• B9PW + FAR

And disallow these combos:

• B9PW + MJ
• B9PW + MJ + FAR (bad)

Adding a dependency on FAR would allow these combos:

• B9PW + FAR
• B9PW + FAR + MJ

And disallow these combos:

• B9PW (bad)
• B9PW + MJ

Clearly neither of these options is perfect; you could debate whether either of them is even "good". Each of them blocks one mod combo that users might legitimately desire to install. But again, users' games were crashing, and it was partly CKAN's fault. CKAN should not be installing a combination of mods that crash the game. So we had to pick one or the other of these workarounds.

Ultimately it came down to a judgment call of which is worse: preventing B9PW from being installed alone, or preventing the B9PW + MJ + FAR combo. Which leads us out into the weeds of the modding scene. MechJeb is an extremely popular mod. Many users rely upon it entirely for their gameplay, for a great variety of reasons. And users who wanted to play with B9PW + MJ + FAR would likely be very upset that they weren't allowed to, since it would work fine. Users who don't want to use FAR (among whom I count myself, for what that's worth), would not like having to install it to use this mod.

So the CKAN team was compelled by circumstances to pick a group of users to upset, a situation none of us relishes. Ultimately I felt that temporarily depending on FAR was the less bad choice, since it would still allow the large cohort of MJ users to install B9PW. Others certainly will disagree with that choice, but then other others may disagree with their preferred solutions, and around and around we go. Some choice had to be made and nothing was going to satisfy everyone.

The good news is that an organization has been created on GitHub for a consolidated fork, so there's hope for the near term future:

• https://github.com/B9-Procedural-Wings/B9-PWings-Modified

I hope this gigantic wall of text helps to provide some further insight into what happened, what the reasons and motivations were, why it's like this now, and what's likely coming along in the future.

Edited May 16, 2021 by HebaruSan

[Lisias]

The problem, dear sir, is that the binary being distributed  by CKAN does not matches the B9 PWings Fork's  Forum Thread author.

The Current NetKan file says:

SpaceDock: https://spacedock.info/mod/2525/B9 Procedural Wings Modified Continued (authors  tetraflon, CarnationRED)

Forum Thread: https://forum.kerbalspaceprogram.com/index.php?/topic/175197-13x14x15x16x17x18x19x-b9-procedural-wings-fork-go-big-or-go-home-update-40-larger-wings/ (author Jebman82)

The Forum Thread pinpoints to B9 Procedural Wings Fork, from Jebman82 and where FAR is not a dependency. It explicilty pinpoints https://github.com/Rafterman82/B9-PWings-Fork as the authoritative source and the link https://github.com/Rafterman82/B9-PWings-Fork/releases/tag/1.0.0 as the latest version.

The SpaceDock link pinpoints to B9 Procedural Windows Modified Continued (from tetraflon and CarnationRED), where FAR is a dependency and the repository is https://github.com/tetraflon/B9-PWings-Modified .

And I will quote the netkan file:

    "identifier":       "B9-PWings-Fork",
    "name":             "B9 Aerospace Procedural Wings - Fork",

And I will quote the SpaceDock page:

Quote

B9 Procedural Wings Modified Continued CKAN

Please observe that Jebman82 is not listed as owner on the SpaceDock link.

The whole mess happened because CKAN since December 2020 is misrepresenting B9-PWings-Fork . Good thing this is licensed under the MIT, as I'm not sure if GPL (and others) would allow such a thing.

A new CKAN identifier "B9-PWings-Modified-Continued" would be a better (and probably safer) option.

It's also worth to mention that when you select FAR to be installed, a submenu appears asking you to select what fork you want (the original one or the continued). This would be a good solution for the dilema, I think.

Edited May 16, 2021 by Lisias
Hit "save" too soon.

[DasSkelett]

1 hour ago, Lisias said:

The problem, dear sir, is that the binary being distributed  by CKAN does not matches the B9 PWings Fork's  Forum Thread author.

See the following for why the forks ended up in CKAN as they are now:

On 12/14/2020 at 8:56 PM, HebaruSan said:

On September 14, the CKAN team received a request to index @tetraflon's fork (see https://github.com/KSP-CKAN/NetKAN/pull/8144 and https://spacedock.info/mod/2525). However, we knew there was already another fork indexed, so we spent an inordinate amount of time reviewing this thread and trying to figure out which maintainers were active, which forks people were using, etc. We reached out to the previous maintainers,  @jrodrigv and @Rafterman82, to encourage collaboration with @tetraflon, because one consolidated team effort would be better than several competing forks, both for CKAN users and non-CKAN users. We never heard from @jrodrigv, but @Rafterman82 replied quickly that this sounded good to him.

Then nothing happened for 80 days. No new releases or commits on the previous forks, no merged pull requests, no announcement by the previous maintainers of a shared GitHub organization to facilitate collaboration (as Kopernicus and KSP-RO have, for example). I don't say this to throw @jrodrigv or @Rafterman82 under the bus here—I understand that folks get busy or lose interest, and that's fine—but that is what happened, and the CKAN team had to make our decisions in that context.

During a review of old pending pull requests, I once again examined this thread to try to figure out what was going on with all the forks, and in my best estimation it looked like the @tetraflon fork was the active one. With no progress on our preferred solution of consolidation of efforts, and the most actively maintained fork not yet indexed despite a 3-month-old request by its author, I crossed my fingers and merged the pull request to switch over to it.

And how we suggested the situation to be solved:

On 12/14/2020 at 8:56 PM, HebaruSan said:

To avoid problems like this in the future, I would strongly encourage the creation of a GitHub organization at https://github.com/B9-Procedural-Wings with all active developers added as members (and possibly as administrators, so they can still add new members as old ones go inactive), all working on the same code and the same list of releases. This would end the musical-chairs game on CKAN by establishing the closest thing possible to an authoritative source for this mod. Clearly the current chaos isn't very good for anyone.

And see the following for where the forum thread link comes from:

We can remove the link from the netkan, then it will be filled in from SpaceDock. Not our fault the new author decided to not create a new forum thread, but instead hijack the existing one.

Edited May 16, 2021 by DasSkelett
Make intention of post more clear

[Snark]

Hi folks,

Some content has been removed due to overly personal / accusatory remarks.

Note that the CKAN maintainers have already posted a thorough explanation of what was done and why, with proposed solutions that haven't materialized yet, in large part because much of this depends on external factors that are outside the CKAN maintainers' control.  They've got some knobs they can turn, and they've been doing so, but a perfect solution has been elusive.

That doesn't mean one can't debate or discuss technical issues.  I'm an experienced software engineer myself, but personally, I'm disinclined to kibitz in cases like this, since I figure that someone like the CKAN maintainers (who have been working on a tool for years, and whose good faith is amply demonstrated by the countless hours of volunteer work they've put into it for the benefit of the community) will have considerably better judgment in the matter than someone else (such as myself) who hasn't walked that particular walk.  So, personally speaking, I'm inclined to stay out of their way and let them work on solving the issue as best they can.

That doesn't mean folks can't make suggestions.  More people = more ideas, and of course it's possible that someone will think of some useful technical solution that the CKAN authors haven't already thought of.  So there's nothing wrong with sharing such ideas, in general.  Please do so respectfully, however, and in non-accusatory fashion.  There's no call for pointing fingers.

Remember that nobody's obliged to use CKAN.  Remember that this tool is only available to you because unpaid volunteers are putting in years of effort to maintain and extend the tool over time, and to keep up with the ongoing welter of KSP mods that are always popping up and often need help in integrating because the mod authors aren't perfect.  Remember that there are plenty of factors outside the maintainers' control, and also that they're juggling this unpaid labor of love in addition to dealing with families and day jobs and so forth.

If you like using CKAN, therefore, leveling personal criticisms and accusations at the people who continue to bring you shiny toys for free is a pretty poor way to show your appreciation.  So please, don't do that.  If you don't like it, don't use it.  If you'd like to help improve it and can do so constructively, without pointing fingers, then feel free.

With regard to the current issue at hand-- the issues with CKAN metadata around the B9 Procedural Wings mod-- this thread appears to have pretty much run its course.  The nature of the technical problem has been explained, along with the rationale.  Some alternative ideas have been proposed and discussed over the past few days.  At this point, it would seem that further constructive suggestions have run out and things are starting to go in circles.  The authors have explained what's going on and what their intentions are, so we're basically done here.

Accordingly, closing the thread.  Thank you for your understanding.