Replies: 2 comments 2 replies
-
|
I'm not sure we need a disable plugin option, the only plugins it would actually apply to are archiver plugins |
Beta Was this translation helpful? Give feedback.
-
|
When it comes to creating the plugin list I wondering on the best idea:
[
{"name": "Metron", "id": "metron", "update_api_url": "https://api.github.com/repos/comictagger/metron_talker/releases/latest," "last_known_version": 0.2.1},
{"GCD"},
{"ComicInfoXML"}
{"etc."}
]
The only "problem" I see with 1 is it's a manually curated list. It would also enable people to be aware of available (official and semi-official plugins). With 2 it requires the plugin to load, the only time I see a plugin not loading but not being broken is with an incompatible CT version which would mean the plugin info could still be grabbed. (Even not using this for info, it could be used to trigger an update prompt.) 3 seems like the only way to be aware of all plugins (including broken ones). Currently, some level of file scanning is going to be required as the plugins themselves don't offer a version number (need to buy a regex license). I'm leaning towards the JSON list. Any preference or something I've missed? |
Beta Was this translation helpful? Give feedback.
-
|
2 It wouldn't need to "load" it would just need to compile, so as long as they aren't trying anything weird and keep their imports simple it should compile with any version of CT. 3 There's no reason to try and parse info from the filenames. When we update we can attempt to load the new plugin and if it fails leave it somewhere else or delete it. I'm ok with including a default list of plugins but I'd rather create a simple repo manifest with links instead of parsing github's api. I don't want to lock-in automatic updating of plugins to github only. The plugins can just supply the url for the manifest Something along the lines of this is all it would need: {
"latest": "0.2.1",
"downloads": [
{
"version": "0.2.1",
"download": "https://github.com/comictagger/metron_talker/releases/download/0.2.1/metron_talker-plugin-0.2.1.zip"
}
]
}Since we already depend on yaml I would parse it as yaml since it's much more forgiving latest: 0.2.1
downloads:
- version: 0.2.1
download: https://github.com/comictagger/metron_talker/releases/download/0.2.1/metron_talker-plugin-0.2.1.zip |
Beta Was this translation helpful? Give feedback.
-
With the manifest I would presume a github action could generate the manifest with the info (and anyone else doing theirs elsewhere would have to solve it themselves). I'll have to look into it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I think for basics it should enable/disable and check for updates.
For disabling, I've made a
disableddir inpluginsand using that for testing which seems like the simplest solution.For updating the plugin itself could have a URL/owner/repo (for GitHub API) or there could be a JSON file?
So far, all the plugins are on GitHub so the API could be used for updating.
Gitlab has an API too, I'm not sure where else people would tend to host them? (If anyone ever does write one.)
Being able to revert would be useful, so adding an
olddir to drop the old plugins in might be easiest.The GUI could check on open and display the management window if any action is needed.
Not sure on the best way to handle the CLI. Maybe
--plugin-update <all|ID>,--plugin-disable <ID>/--plugin-enable <ID>and nothing happens automatically?Beta Was this translation helpful? Give feedback.
All reactions