Allow non-mod dependencies (references)

[janbrohl]

It seems like there are some mods (Principia at least) that only work on special platforms (like windows) which could be referenced like mods.

Also targetted KSP version ranges could be unified with other dependencies.

For backwards compatibility non-mod dependencies could be added to the index as metapackages.

Example for KSP 1.1.2

{
"spec_version": "v1.16",
"identifier": "KSP",
"version": "1.1.2",
"license": "restricted",
"name": "Kerbal Space Program",
"abstract": "The main game of KSP",
"ksp_version": "1.1.2",
"ksp_version_strict":true,
"kind": "metapackage",
"depends": []
}

[politas]

Principia works on all platforms, though it has separate downloads, like AFBW. The important thing is that it needs supporting libraries to be installed that CKAN can't control. (Which is what you're talking about, of course)

Not sure how we'd check that a user has libraries installed. (Principia on linux requires libc++ and libc++abi for instance)

[janbrohl]

Although CKAN cannot (and propably should not) change which stuff is installed on the computer in general it should be possible to find out which stuff is available.

I am not very firm with Linux but most distributions use package(?) managers like apt for example which could be queried for installed packages.

[politas]

Yep, though several different package managers, depending on distro. apt, deb, rpm, ...

And then there are the distros that don't use any package manager, like good old Slackware (and we have at least one user on Slackware, apparently)

[janbrohl]

Users which do not need package managers, do not need actual system-dependency checkin - I guess.

If there is no easy way to find out if a dependency is satisfied automatically just notify the user. Either he knows what to do or has a look at the manual/homepage of the dep.

[mheguy]

Ref #489

[HebaruSan]

This is of dubious value for game versions as shown in the OP (since game version compatibility essentially is a completely solved problem at this point with very mature solutions for every concern that might come up), but could allow us to index mods with platform-specific dependencies like Principia.

It could take a strategy similar to #2326: define an identifier like CPP-Runtime and associate it with a class that checks for it, presumably using Platform.IsWindows, Platform.IsUnix, and Platform.IsMac to determine the specifics. The wrinkle here is that it may or may not be possible for a given dependency to be determined in a version-independent way for all time; if Principia's specific requirements change from one version to the next (imagine they make changes that require a newer C++ library), the CPP-Runtime would either have to change (and break old versions), not-change (and break new versions), or be forked somehow (proliferating identifiers for this stuff).

This has the potential to become a very tight coupling between a mod and CKAN. I don't have any great ideas about how to handle that.

[HebaruSan]

Details on Principia's requirements summarized at: https://github.com/KSP-CKAN/NetKAN/pull/5643#issuecomment-1223000906

One idea would be to make one identifier (and custom checker class) per platform and use any_of to combine them, and then map the special modules' version property to the version we find in the user's system, as in:

depends:
  - any_of:
    - name: CPP-Runtime-Windows
      min_version: 2015
    - name: CPP-Runtime-Linux
      min_version: 8
    - name: Platform-MacOS
      min_version: 10.12

This would still be pretty complex and potentially a lot of maintenance, but it would at least address the concern about updates over time in a stable way.

[HebaruSan]

The next missing piece of this would be the logic to scan the system for the C++ runtime packages. Naturally this has to be platform-specific.

Somewhat unsurprisingly, the API for this in Windows is horrible. You can't simply specify a package and ask for the installed version; instead, you have to hard-code dozens of GUIDs and query every single one of them using MsiQueryProductState, with the fun side effect that if Microsoft releases a new version, detecting it would require a code change and a new release:

https://pingfu.net/how-to-detect-which-version-of-visual-c-runtime-is-installed

Fortunately there's a library in Nuget to help with managing all the GUIDs, but even that would still fail to detect any versions newer than the build of CKAN itself:

https://github.com/enclave-networks/MscVersion/

(Out of date, see https://github.com/enclave-networks/mscversion/pull/4#issuecomment-1694518148)

But again even with GUIDs handled there's an obscure mapping from the numbers we can retrieve to the product numbers we want.

    - name: CPP-Runtime-Windows
      min_version: 1900

[HebaruSan]

We might be able to do this on Linux with some combination of scanning files, running commands, and parsing filenames:

$ ldconfig -p | grep libstdc++
    libstdc++.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libstdc++.so.6

(Ubuntu 22.04 LTS seems to only have dev packages for newer versions.)

... browsing the Principia thread, it looks like the requirements are libc++.so.1 and libc++abi.so.1, not libstdc++. They want version 8 of those packages, which is not reflected anywhere in their filenames. So it might actually be impossible to check this dependency programmatically.

https://forum.kerbalspaceprogram.com/topic/162200-*?do=findComment&comment=4134016

The Debian packages might be libc++-dev and libc++abi-dev? But usually I'd expect a dev package to be used at compilation, not runtime.

[HebaruSan]

Mac might be easiest! Environment.OSVersion.Version gives the Darwin kernel version (supposedly, can't test myself), which can be mapped to the desired OS versions (looks like Mac OS v10.12.0 corresponds to Darwin kernel version 16.0.0), or we could use the Darwin kernel versions directly in the metadata:

    - name: Platform-DarwinKernel
      min_version: 16.0.0

https://stackoverflow.com/questions/28070089/get-mac-os-x-version-number

[HebaruSan]

The validation scripts are a concern; to successfully install a mod with one of these dependencies, either we'd need to be able to fake them, or we'd need to install the CPP runtime in our containers. I guess that would be done with:

sudo apt install libstdc++-dev libstdc++abi-dev