Bug 28498 - Add CLI counterpart for plugin actions
Summary: Add CLI counterpart for plugin actions
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Plugin architecture (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Tomás Cohen Arazi
QA Contact: Testopia
URL:
Keywords:
: 25671 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-06-01 14:47 UTC by Nick Clemens (kidclamp)
Modified: 2022-07-27 04:02 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2021-06-01 14:47:19 UTC
We need a CLI counterpart for plugin actions:
 - Install (from a URL, from a .kpz)
 - Upgrade (from a URL, from a .kpz)
 - Uninstall
 - Configure based on some file format
Comment 1 David Cook 2021-06-02 02:40:30 UTC
+1000000

I opened Bug 25671 a while ago for this, but I ran out of time/energy for it, as we don't really use plugins much at this point. I'm happy for that bug report to be marked as a duplicate of this one, if Tomas is going to work on this. 

Really really looking forward to progress on this.
Comment 2 David Cook 2021-06-02 02:46:14 UTC
*** Bug 25671 has been marked as a duplicate of this bug. ***
Comment 3 David Cook 2021-06-02 02:53:57 UTC
Btw, it could be interesting after installing/upgrading a plugin to do a graceful restart on Starman using HUP as per https://metacpan.org/pod/Starman.
Comment 4 David Cook 2021-12-09 03:30:18 UTC
(In reply to Nick Clemens from comment #0)
> We need a CLI counterpart for plugin actions:
>  - Install (from a URL, from a .kpz)
>  - Upgrade (from a URL, from a .kpz)
>  - Uninstall
>  - Configure based on some file format

I actually had another thought about this...

What if we had an instance-level configuration file that defined the plugin, the plugin version, and the plugin configuration?

We could even re-use that configuration file across multiple Koha instances which would help with the logistical challenges of managing plugins. (We could use symlinks to point to a central file, or point to a central file from koha-conf.xml for instance.)
Comment 5 Martin Renvoize 2022-04-11 10:05:55 UTC
This would be great.. we do have https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/devel/install_plugins.pl of course.. but having a package friendly debian script with all the options described here would be much nicer.
Comment 6 Tomás Cohen Arazi 2022-04-11 13:08:55 UTC
(In reply to David Cook from comment #4)
> (In reply to Nick Clemens from comment #0)
> > We need a CLI counterpart for plugin actions:
> >  - Install (from a URL, from a .kpz)
> >  - Upgrade (from a URL, from a .kpz)
> >  - Uninstall
> >  - Configure based on some file format
> 
> I actually had another thought about this...
> 
> What if we had an instance-level configuration file that defined the plugin,
> the plugin version, and the plugin configuration?

I like baby steps. We should add the features to some script(s) and then we teach them to read from a config file.
Comment 7 David Cook 2022-04-11 23:21:50 UTC
(In reply to Tomás Cohen Arazi from comment #6)
> I like baby steps. We should add the features to some script(s) and then we
> teach them to read from a config file.

Sounds like a plan to me. If the logic is in a module, then it should be trivial  controlling the module from either CLI args or a config file I reckon. 

I've been revising my TODO list, and while this functionality has fallen down the list, it's still something I would still like to have. Happy to test patches on this one.
Comment 8 David Cook 2022-04-11 23:42:23 UTC
(In reply to Martin Renvoize from comment #5)
> This would be great.. we do have
> https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/
> devel/install_plugins.pl of course.. but having a package friendly debian
> script with all the options described here would be much nicer.

I didn't used to understand this script, but I think I understand it better now...

I suppose a person could add a "pluginsdir" that points to a central location of curated plugins and then run this script to install them across the board. Or symlink from /var/lib/koha/<instance>/plugins/Koha/Plugins/<plugin>.

We don't really use plugins except for one or two here or there, but I wonder sometimes if we would use them more if it were easier to install en masse. And maybe it has been and I just haven't been creative enough... ;)
Comment 9 David Cook 2022-07-27 04:02:41 UTC
(In reply to Nick Clemens from comment #0)
> We need a CLI counterpart for plugin actions:
>  - Install (from a URL, from a .kpz)
>  - Upgrade (from a URL, from a .kpz)
>  - Uninstall
>  - Configure based on some file format

I'm still keen on this one.

I would love to turn on plugins for all my Koha instances while disabling the Plugin web upload. This feature would be a bit more convenient than using install_plugins.pl.

Actually I was most of the way with Bug 25671, although that code didn't take into account that you could have multiple "plugin_dir" entries. That's a gotcha with this CLI feature. I suppose you could always assume a default path and override or fail as necessary. (Using a "default" attribute on the main plugin_dir path would be handy...)

I don't know. I keep wanting to use plugins more, but it's just not been quite convenient enough. 

I'm still thinking a bit about my "Plugin Manager" Koha plugin which would provide a list of curated plugins that would let library staff install plugins with a click of a button. 

And then deploy that "Plugin Manager" Koha plugin using a centralized "plugin dir" and just run 'koha-foreach perl /usr/share/koha/bin/devel/install_plugins.pl' for install/upgrade of those centralized plugins that I want to enforce on all instances...