Skip to content

Use internal ckan and version file to install unrecognized ZIPs#4327

Merged
HebaruSan merged 6 commits into
KSP-CKAN:masterfrom
HebaruSan:feature/import-from-internal-ckan
Mar 16, 2025
Merged

Use internal ckan and version file to install unrecognized ZIPs#4327
HebaruSan merged 6 commits into
KSP-CKAN:masterfrom
HebaruSan:feature/import-from-internal-ckan

Conversation

@HebaruSan
Copy link
Copy Markdown
Member

@HebaruSan HebaruSan commented Mar 12, 2025

Motivation

To install a module, you need metadata for it, which currently comes from either a metadata repository (e.g., CKAN-meta) or a standalone .ckan file. It would be nice if a mod could be more self-contained, so the ZIP itself could provide all the info needed to install.

Internal .ckan files potentially could provide a mechanism for this, but they're currently only checked by NetKAN. Additionally, this usage would clash somewhat with the existing usage:

  • CkanModule.version is required, and while it technically could be added to an internal .ckan file, that would require additional manual maintenance for every release of a mod and would be redundant with the more reliable host APIs that usually provide this data. So we need another way of setting the mod version, preferably one that would work for at least some existing mods.
  • CkanModule.download isn't needed for downloading when you already have the ZIP, but it is required for cache management and also a bad idea to set in your internal .ckan file for the same reasons as version.

Changes

Now if you try to import a ZIP that isn't found in any of your configured metadata repositories, CKAN will scan it for internal .ckan files and "inflate" them if found, using a simplified version of what NetKAN does:

  • If the $vref property exists, we scan the ZIP for either a *.version file or a swinfo.json file (depending on the value of $vref), parse it, and import its version and compatibility properties into the module.
  • If the download property isn't set, we assign it a default value that contains both the mod's identifier and the name of the ZIP file, which should hopefully prevent two different mods accidentally sharing the same URL (and therefore cache hash).

If the inflated metadata satisfies all of CkanModule's required fields, then the file will be imported to the cache and can be installed during the importing process. (If you import without installing, you won't be able to install it later, because the inflated metadata is discarded after the importing is complete.)

To make this work, several things needed to be moved from NetKAN to Core:

  • YamlExtensions so we can parse the internal .ckan file in the client
  • AvcVersion so we can parse .version files
  • SpaceWarpInfo so we can parse swinfo.json files
  • ModuleService.ApplyVersions, which is now GameVersion.SetJsonCompatibility so we can set the game version compatibility properties correctly

Ideally, all of the inflation logic would be shared with NetKAN, but that has not been done at this point due to limitations of NetKAN's code structure and some subtle differences in how the inflation needs to be done in the two contexts.

Known limitations

  • Mods that use this method will miss out on all of the validation checks that the bot performs, plus the ones that run for NetKAN pull requests. Importing may error out if the internal .ckan file has a syntax error, missing properties, etc.
  • Setting the version based on the .version file may have some quirks. Suppose there's a mod that has a partially non-numeric version string on GitHub/SpaceDock, like v1.2.3; the v can't be represented in a .version file, so the above described importing logic would set version to 1.2.3. But now suppose the mod in question is in the metadata repo but you are importing a release of it that isn't indexed (yet?). The value of version then would not reflect the "correct" value that will eventually be generated by NetKAN (with the v prefix) for that release when it is indexed. The same goes for any mods using x_netkan_version_edit or x_netkan_epoch to massage version strings into consistency. This may even result in out-of-order version strings.
    For this reason, it's probably best to limit usage of this feature to mods that are not and never will be indexed.
  • The version file and swinfo handling doesn't check the remote copies of these files. The potential benefit from doing that is minimal and doesn't outweigh the added complexity and opportunity for errors.

@HebaruSan HebaruSan added Enhancement New features or functionality Core (ckan.dll) Issues affecting the core part of CKAN labels Mar 12, 2025
@HebaruSan
Copy link
Copy Markdown
Member Author

@JonnyOThan, this feature is ready for alpha testing with paid mods if you have time:

@HebaruSan HebaruSan force-pushed the feature/import-from-internal-ckan branch from cff0c3b to cc35312 Compare March 16, 2025 19:24
@HebaruSan HebaruSan merged commit 54d9077 into KSP-CKAN:master Mar 16, 2025
@HebaruSan HebaruSan deleted the feature/import-from-internal-ckan branch March 16, 2025 20:35
@HebaruSan HebaruSan mentioned this pull request Jun 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Core (ckan.dll) Issues affecting the core part of CKAN Enhancement New features or functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant