neos-modding-group / neos-mod-manifest Goto Github PK

Look's like @kawaiiamber has changed their github username to @astralchan. All the links need to changed.

some entries in the manifest don't use semver correctly (semver has exactly 3 parts, while some versions have 4 or even 2)

I think either the manifest schema on the website should be updated to mention that semver isn't really respected
or the incorrect semvers should be fixed up.
I have made a fork with all the semvers fixed up master...art0007i:neos-mod-manifest:patch-4

There's been quite a few PR's that had broken JSON or wrong indentation. Setting up GH actions to check for basic things like that and automatically request changes if there's issues should be done.

Also as a more complex possibility, since so many people use github links, we could do a regex check on the download/release urls and if they match Github urls but aren't pinned to a specific tag could leave a comment straight away about it on the PR.

Some of our actions are using deprecated things and soon to be disabled things. 2 warnings are shown on the action summary

• Validate EditorConfig: Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/
• Validate JSON: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

• The tutorial has issues
  • Needs updating in general, as it's slightly outdated
  • Readability is bad. There should be one main tutorial with good flow that links to more detail as necessary.
  • The flags need documenting
  • The non-obvious requirements (like leaving old versions in place) need documenting
  • Needs to be linked to from more places, like the readme on this repo, and maybe the PR template
  • Needs a better copy/pasta than the unusable one I've provided (the comments are the culprit here)
  • We might need a quick and dirty git tutorial...
  • A link to the relevant discord channel if people need more support
    • Create a discord channel for this!
• The schema page is outdated and in a very WIP stage
  • readability is awful
  • json property names are wrong/missing
  • the real json schema should be linked to
• The reasoning behind the manifest needs documentation. A lot of the stuff we're requiring is future-proofing with no use today. Without justification these seemingly arbitrary requirements are frustrating.

If anyone's got more tasks for the list toss them in this issue.

The format of the color property is not documented yet, and it's tracked at neos-modding-group/neos-modding-group.github.io#12

I think that we all can agree that it should be done with hex strings though. The mod release notification python script currently just uses the value of the field , whereas discord expects it to be the integer representation of the hex's value. A small hex -> int conversion utility method should be added to utils.py, and it should be used if the mod has a color instead of the raw value.

Add the current date to the mod list page on generation. This could be somewhere near the top and is when the page itself was last updated with any change.

Seems like there are quite a few mods on the mod list that are headless-specific. I think it would be nice to put these all under one 'Headless' category.

pretty simple

https://www.neosmodloader.com/mods

what are yalls general thoughts on adding a section to the website to easily edit the manifest?
maybe also an option to auto generate some fields from a github repo

thinking this would be implemented with github oauth

how should we handle situations where someone is deprecating someone else's mods,

i think we should not deprecate a mod author's listing with out their approval

seems quite a few mods have nugit dependencies, maybe we can improve our schema/automation to directly support them without needing to manualy review them.

https://github.com/neos-modding-group/neos-mod-manifest/actions/runs/3790202585/jobs/6444641922#step:6:1
https://github.com/neos-modding-group/neos-mod-manifest/actions/runs/3577158302/jobs/6015832575

basically the action calls curl with some data like

curl -d '{"description":"you're"}' '***'

which crashes because of the single quote inside the word "you're" ends the data part of the request specified by the -d flag

I think to fix this it would be as simple as replacing all ' with '\'' which seems to be the escape character for quotes in bash

It'd be neat to have a tool that automatically downloads the files that are being added in a PR and check the hashes, so that there's less copy-pasting different commands to check the things, so that the only manual step that'd remain is the actual DLL decompilation.

curios to hear what y'all's thoughts would be on turning the Conflicts array each version of a mod has into a dictionary of mod guid to semver version specifier

Hello there,
I was quite surprised that adding a mod involved directly adding an entry to a large JSON file.
Reason being that I was used to a more decentralized system with programs for a minecraft mod.
Of course that exact approach is not meeting the high security standards.

On the other hand I am not sure if multiple people editing the same file does perfectly scale with a higher rate of edits.
I can imagine having to resolve tiny but probably annoying conflicts when two or more pull requests for new mods are added at the same time.
Another advantage of a less monolithic approach would be that mod authors could setup CD pipelines that would automatically prepare a PR for a new version. (It is much easier to create a new file than it is to edit one.)

To ensure that the power over the data stays within the repository I suggest the following:

1. Every project gets its own directory.
2. Within each directory there is a main json file and auxiliary json files for each version.
3. As part of this repository's CI/CD pipeline the json files are individually checked for correctness and then combined to form the manifest.

Secondary advantages are that due to the CI/CD middle layer there are basically a lot of hooks where you can check semantic validity and styles in more detail. (#74)
Making the editing of mod entries file based may also ease the process of auxiliary tools. (#75)
The separate "playzones" should also prevent accidental changes to other mods.