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

Support partial dependency version in manifest #1067

Open
Californ1a opened this issue Oct 3, 2024 · 0 comments
Open

Support partial dependency version in manifest #1067

Californ1a opened this issue Oct 3, 2024 · 0 comments

Comments

@Californ1a
Copy link

This seems to be an inconsistency between Thunderstore's manifest validation and r2modman's manifest validation. In r2 (and Thunderstore app), I'm able to locally load a mod zip package with a manifest like so:

{
    "name": "MainMod",
    "author": "Californ1a",
    "version_number": "1.0.0",
    "website_url": "",
    "description": "Description",
    "dependencies": [
        "BepInEx-BepInExPack-5.x"
    ]
}

with a second mod dependent on any version of this first one, like so:

{
    "name": "SubMod",
    "author": "OtherAuthor",
    "version_number": "1.0.0",
    "website_url": "",
    "description": "Description",
    "dependencies": [
        "Californ1a-MainMod-x"
    ]
}

The association is properly displayed and accounted for in r2:

  • Clicking "Associated" shows the dependencies and dependants.
  • Trying to uninstall the main mod displays the notice about other mods depending on it.
  • Installing the second mod without having the main one installed will show the "issue with the dependencies" icon.
    • And it properly goes away after installing the main mod.

However, the dependency versions don't seem to pass validation when trying the manifest in Thunderstore's manifest validator (assuming the name of a package that exists is used, and just the version number is changed).

I'm not sure whether this is just an issue with the manifest validator page specifically, or if it also affects uploaded mods and would reject a mod with an "invalid" dependency version. I haven't tried to upload anything yet.

The only thing that doesn't seem to work in r2 when using partial versions like this is the "Download Dependency" button for the main mod, to download BepInEx. Is this potentially why it's currently "invalid" in the manifest validator - it can't resolve which package to download, even though it can match locally if it is already downloaded?


The crux of this issue being the Distance modding community is trying to start migrating from an older custom modloader to BepInEx and Thunderstore instead, and the most widely-used mod is CustomCar which adds the ability to import custom car models to race with. All the custom car models are made by various different authors and have historically just been dumped into this single repo, with or without attribution.

We'd like the car model authors to be able to publish their own cars as individual packages on Thunderstore, so they get their own attribution, each with a dependency on the main CustomCar mod in their manifest, but if the CustomCar mod updates and changes version, then it would require all the car model authors to update potentially hundreds of packages with the only change to them being the main mod's version in their manifests. That just doesn't seem sustainable long-term without partial version dependencies, especially if a car model author disappears and doesn't/can't update their package so it becomes unusable even though the car is still going to be loaded by the mod just fine.

The only workaround I'm seeing right now is to have all our car authors just not list the main mod as a dependency, which would get around having to keep the main mod's version in all their manifests updated, but that would also be confusing for users who might just grab a bunch of car models without realizing they need the core mod installed to actually load them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant