https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890
--- Comment #6 from David Cook <[email protected]> --- (In reply to Kyle M Hall from comment #4) > 3 is what I keep coming back to in my mind. What I imagine is an interface > in Koha to define plugin repositories. I think we could leverage the release > systems in GitHub and GitLab to power such a system. > > So, for example, if I want to be able to search and install plugins from > ByWater Solutions, I'd add https://github.com/bywatersolutions/ to my plugin > source targets. Koha would then search for repos prefixed with "koha-plugin" > ( which seems to be a general convention followed by most plugin developers > ). At this point it would be trivial for Koha to pull data about the plugin > from GitHub. One addition to plugins that would facilitate this is to add a > package.json file with contents similar to what is in the metadata of the > plugin file removing the need to download the plugin to know metadata about > it like the supported Koha versions. Indeed, it would allow Koha to skip > over plugins that are known to not work with that version of Koha! > > The same could be done for GitLab I'm sure. > > Thoughts? I don't really like the sound of that, as it seems hacky and too Git-specific. Maybe we should look around at other examples before we re-invent the wheel? I will just note that I envision a system where we have a list of public keys and a list of repositories (quite like APT really). You search the repository and when you try to install a plugin, you check the plugin file's signature against the public key, and only verified plugins are installed. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
