split manifest and use asyncio
- Split the manifest and let ci merge it when update (so people should not face the conflict)
- Use asyncio as #270
Script to split is simple
let plugins = open "plugins.json"
for plugin in $plugins {
let name = $plugin.Name
let id = $plugin.ID
$plugin | to json -i 4 | save $"plugins\\($name)-($id).json" -f
}
@jjw24 want to check?
What's the performance gain from this change?
And what have we tested with these changes?
If deleting the plugin file, will it remove it from plugin.json?
Would it be better to just allow dropping the plugin's json file into the plugin folder and then the script picks out the fields to form the plugins.json and test + validate the plugins?
Would it be better to just allow dropping the plugin's json file into the plugin folder and then the script picks out the fields to form the plugins.json and test + validate the plugins?
That's almost the case. Instead we just test and validate before forming the plugins.json
What's the performance gain from this change?
Almost proportional to the number of plugins
And what have we tested with these changes?
If deleting the plugin file, will it remove it from plugin.json?
CI should periodically generate plugins.json from the directory
Hmm if the plugin.json is merged from all individual plugin entries should we create a release for the plugins.json?
Instead of committing it to the repository.
Are we sure we are not just complicating things unnecessarily?
Because instead of editing a single json file now will have to create a seperate file, which is a different process as well. I'm sure editing json isn't that difficult, and the CI isnt running for too long.
Are we sure we are not just complicating things unnecessarily?
I wouldn't say editing a huge file is less complex than adding a new file specifically. Almost all plugin manifests uses a dedicated file/folder for each plugin.
The merge conflict is really complicating things and annoying.
Are we sure we are not just complicating things unnecessarily?
I am not sure. Maybe that's good? Though what's the difference.
Would it be better to just allow dropping the plugin's json file into the plugin folder and then the script picks out the fields to form the plugins.json and test + validate the plugins?
That's almost the case. Instead we just test and validate before forming the plugins.json
So would the test validation fail if the file has extra fields like "Actionkeyword"? If doesn't fail will plugin.json still form properly with only the required fields?
We still need extra information. Like the repo position and the icon. But yes I agree it's not a big difference.
Would it be better to just allow dropping the plugin's json file into the plugin folder and then the script picks out the fields to form the plugins.json and test + validate the plugins?
That's almost the case. Instead we just test and validate before forming the plugins.json
So would the test validation fail if the file has extra fields like "Actionkeyword"? If doesn't fail will plugin.json still form properly with only the required fields?
I use the same ci. So probably not.
Are we ready to push this a bit further?
Sure, let's get the latest plugin files in and I will take another look.
@jjw24 done