-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Introducing IGameComparatorExemptions in order to waive checking version compatibility for select modules. (Take 2) #1965
Conversation
Updating fork of CKAN from original master.
…tibility by pronouncing them compatible to each and every KSP version. This was done due to Strategia missing from CKAN and its dependency CustomBarnKit officially not being supported by the latest build of KSP while in fact it is. The way this waving process selects eligible modules is hardcoded but can be easily made more dynamic.
… the new files won't be included by the IDE.
Hey sorry for the somewhat long downtime on my end. Holidays and all. ;) So after taking a look at PR 1957 It does appear it accomplishes pretty much what I am doing. The only difference really is that I am shooting more for specific packages that are deemed compatible with a user's current KSP installation when compared to either the GRAS or YOYO GameComparators. Or to put it in other terms in case whatever IGameComparator implementation evaluates a mod as incompatible you could toss in any of my IGameComparatorExemptions implementations to reevaluate the result and potentially mark it as compatible. Now this certainly could be accomplished elsewhere and I think you probably would plug that kind of logic right into a YoyoGameComparator instance or write a whole new GameComparator. End of the day in terms of use case It fills a potential solution gap when you are just looking to mark certain mods and their dependencies as compatible and for the remainder of the mod repository would like to sustain "objective/actual" compatibility checks. I certainly could go ahead do a rewrite and just create a new GameComparator if you guys feel its necessary. After all I really just wrote this to get a single mod and its dependencies to work with my KSP version without potentially breaking the rest of version checks. In case of going forward with this or my proposed rewrite it could potentially turn into a bit of a rabbit hole. Assume for instance a mod declaring new dependencies after the existing dependency chain was hardcoded to cater to said mod and that new dependency happens to also not be compatible with the current KSP version. Not sure how CKAN would handle such a scenario with GRAS or Strict. Haven't looked at those particular areas of the code base. Off the top of my head I'd say don't hardcode the mods that ought to pass any check. |
If you're talking about the CKAN project making determinations about which mods can have their compatibility ignored, well, that's exactly why we hadn't implemented any other systems to do this. And we especially don't want any specific mod info hard-coded into the CKAN. (other than our tests) |
Obviously you could ultimately pull the info for mods that pass any version check from just about anywhere. For my purpose hardcoding was the quick way to do it and my UI was my IDE but looking at the regular user one could work with simple text files where each line represents an exempted mod or make this choice integral to the UI. |
I think #1957 is a much easier method for users to understand and utilise, so I think we'll drop this. As far as allowing off-version installation of a specific mod, there is nothing preventing you from changing the KSP compatibility settings back to strict after installing a specific mod. The CKAN doesn't force uninstallation of incompatible mods or anything like that. Thanks for the submission, though, and I do hope you have some further ideas to improve the CKAN! |
Made it possible to specify certain modules which are exempt from version compatibility checks which makes them in CKAN for all intents and purposes compatible with every KSP version.
My motivation behind this was a mod with a dependency chain long enough so that I wasn't willing to manually check each and every item for compatibility with my current KSP version (all I knew was that people are playing the mod with the most recent KSP version so it has to be possible from a technical viewpoint).
The way I implemented it starts roughly with an IEnumerable which holds the exempt elements. This list is then checked against incoming mods by assigning GrasGameComparator an instance of GameComparatorExemptions which in turn holds the elements and implements IGameComparatorExemptions. The latter prescribes a method bool IsExempt(CkanModule module).
As a next step I could see filling this list from other more dynamic sources such as config files, webservices or from user input from within the UI. All this to allow a better control for cases where the regular version (range) comparison on both ends doesn't fit the bill.