type definition and structure proposal

[JanThomasUP]

a package type to support non github based mods as well as source branch released ones

also an optional .mods where a list of mods contained inside the package.
e.g.
{
"Spice_Cameraflight":"https://raw.githubusercontent.com/anno-mods/Spice-it-Up/master/%5BAddon%5D%20Cape%20Trelawney%20Camera%20Flight/modinfo.Json"
}
this way mod (not only packages) could be checked for updates and it would be platform agnostic

[jakobharder]

I would not do auto discovery within a GitHub repository.
There should be a single top-level json file with all the information.

1 request per repository is already expensive enough.

We currently have name and id for the collection as well.
name is for fast browsing without requests to the individual repositories.
download is only a fallback and not recommended. We only use it now because the rest is not properly defined yet.

[JanThomasUP]

"There should be a single top-level json file with all the information."
=> a new package.json maintained by the modder
I'm absolutely for it! But I'd require this to be a seperate file per release or in the branch to be checked out without the requirement of downloading the full package.zip

I'd like to keep backwards compatibility for my manager and this would require the possibility to add repos/packages not maintained anymore or even without modinfo.json. I could host the meta information in a separate fork of this repo but it would make sense to keep it all together.

That's why i made .mods optional - this would create a way for old/unmaintained mods to be included as well (without any meta repo/forked trough "hackydêhack")

[jakobharder]

But I'd require this to be a seperate file per release or in the branch to be checked out without the requirement of downloading the full package.zip

The package.json is supposed to tell you what files you can download. So, it's obviously separate ;-)
It should be an accessible URL at a pre-defined or in the modindex configured location, hence 1 request per repo.

I'd use the same json for external mods as well and not create another .mods.
If you already specify the downloads, there's nothing stopping you from pointing to other locations.

[JanThomasUP]

I'd use the same json for external mods as well and not create another .mods.
If you already specify the downloads, there's nothing stopping you from pointing to other locations.
I'm not so sure if we are on the same page right now, could you elaborate the management workflow for me. My Understanding till now was:

Program journey:

• build an list of mods from local mods folder
• build index of packages from remote (get anno-mods/Packages/pagages.json)
• get info regarding all mods & packages from modder generated data (modinfo.json, packages, releases,....)
  • we are currently here in our discussion (as i understand)
• match versioning
• ...

and if I understood your package.json correct it would require each and every modder to change her/his current mod/pack to be compliant. This would result, in my opinion, in an incomplete index where we aren't able to list many mods (e.g. mostly mods where the creators aren't going to change "just to be listed" on a currently unknown platform)
I've experienced more acceptance by creators if the system "just works" and invites to extend (getting a better representation by generating a modinfo.json, adding images, be autoupdateable by providing a package.json etc...) but this requires the system to be able to support "unformated" systems but provide the ability for a stricter but better experience.

I'd understand if you or the imya team would like to follow the more strict approach (and require changes by creators/modders to be compliant) - in that case I'd need to branch of to get the user and creator -experiance I'm after.

[jakobharder]

@taubenangriff any thoughts?

[taubenangriff]

With mod.io upcoming, most of the "just works" concerns are out of the way I guess? Can add our mods here, but it's mostly just for lulz. mod.io will be the way to go forward.

[jakobharder]

Fair enough. Then merge and deprecate the whole repo? Cleaning up is not a bad idea either.

[taubenangriff]

Why deprecate? still need it for imya I guess. If imya deletes the feature, we can close the repo though. But that's another discussion.

[jakobharder]

Ah, I thought you meant the whole feature ;-)