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

Discussion: configuration #2

Open
Lauriethefish opened this issue Jul 30, 2022 · 3 comments
Open

Discussion: configuration #2

Lauriethefish opened this issue Jul 30, 2022 · 3 comments

Comments

@Lauriethefish
Copy link

Lauriethefish commented Jul 30, 2022

Ideas list for configuration/package management:

  • Ability to specify minimum (or recommended) NDK version to be used. (QPM should be able to automatically download this if missing, in my opinion)
  • Instead of having a mod.template.json (which always seemed overkill to me), add additional fields to the package to specify that information. e.g. game version, description. It's useful for packages to have that info anyway, and it would make the template unncessary.
  • qpm.shared.json currently stores downloaded dependency versions if my understanding is correct. Could this be used as a lock file, for CI purposes? i.e. add a command qpm ci that will pull the restored dependencies in qpm.shared.json. This could be good for reproducible builds.
  • A bit "out there", but ability to restrict a package based upon your game version (or some kind of warning system if a package isn't compatible with your version. granted, this requires additional metadata on packages that we don't have right now).
@RedBrumbler
Copy link
Contributor

QPM downloading NDK has been an idea floating around already and that would be pretty useful, idk about specifying a specific NDK version though...

The idea behind the template json was mostly so you could use the values in the description if you wanted to, but yeah some of that stuff can just go in the package config file as a better place to be, but idk if I agree with description there

having differences in restoring where it uses exact versions from a shared json definitely sounds like a good idea, because that way building for older versions becomes easier, this is definitely something we can look into adding here

specifying a game version on the package could work, though it would require being able to edit later because most packages work on current and going forward till it breaks and currently there is no way of marking hte end of the lifetime of a mod, unless we want to do the thing where mods HAVE to be updated every version (pls no)

@Lauriethefish
Copy link
Author

Lauriethefish commented Jul 30, 2022

, idk about specifying a specific NDK version though...

I don't mean a specific version, I mean X version or up. Just to make sure that people don't use a version that's too old if newer features are needed.
Why wouldn't description go in the package? It'd be useful to see what a package does.

Agreed game versions would have to be customisable later on, which would require backend changes so perhaps not.

@RedBrumbler
Copy link
Contributor

I mean we might even make a new backend as a result of this more collaborative approach to qpm

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

2 participants