Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

Rusk85
Copy link

@Rusk85 Rusk85 commented Dec 24, 2016

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.

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.
@politas
Copy link
Member

politas commented Dec 24, 2016

Hi @Rusk85, Are you aware of recently merged PR #1957, which seems to be solving the same problem? If not, can you explain the use case and interface a little more?

@Rusk85
Copy link
Author

Rusk85 commented Jan 4, 2017

Hey sorry for the somewhat long downtime on my end. Holidays and all. ;)
Now first things first Happy New Year All Around!

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.

@politas
Copy link
Member

politas commented Jan 5, 2017

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)

@Rusk85
Copy link
Author

Rusk85 commented Jan 5, 2017

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.
Anyway you know now my motivation behind this. If you think it's worth the effort happy to expand on this code-wise or answer further questions. Otherwise time to bury the idea and move on.

@politas
Copy link
Member

politas commented Jan 5, 2017

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!

@politas politas closed this Jan 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants