Enable access to the Plugin Gallery via CLI

[ctgraham]

Describe the problem you would like to solve
Administrators need to be able to interact with the Plugin Gallery via CLI.

Describe the solution you'd like
Extract the Plugin Gallery functions into Services/API architecture, independent from the handlers, and expose Services/API to the CLI. (long term)

Mirror some functionality via dedicated script (short term).

Who is asking for this feature?
Administrators who are managing multiple instances of OJS/OMP/OPS and seeking to automate plugin installations/upgrades.

Additional information

From Slack:

Clinton Graham May 13th at 11:16 AM

Andrew Gearhart, did you investigate this further? It looks entirely enmeshed with the display logic to me, but it probably wouldn't take too much effort to create a CLI tool script which uses the PluginGalleryDAO to list, search, and install the latest version of a plugin.

Nate Wright 2 months ago

Yeah, so our long-running goal with the Services/API architecture is to separate functionality from the handlers (eg - the plugin grid), so that actions like adding/editing objects or installing/enabling/disabling a plugin can be performed outside of their handlers.
For the moment, we have tended to do this refactoring alongside UI/feature improvements. But we'd be very receptive to community contributions for this kind of refactoring in areas we haven't been able to prioritize.
There's a ton of potential to be realised here where actions overlap with admin functions: plugin install, activation, deactivation; user creation. password reset, disabling; journal creation; etc.
If anyone wants to explore some code refactoring for a particular use case, I'd be happy to help facilitate. This mostly involves moving code out of a grid handler and into a service class, but can sometimes get a bit tricky.

Clinton Graham 2 months ago

I know this doesn't address the actual desired work of abstracting this to the Services/API architecture, but trying to relieve a local pain-point led me to write a quick CLI tool stub: https://github.com/pkp/pkp-lib/compare/stable-3_1_2...ulsdevteam:pluginGalleryCLI?expand=1
https://gist.github.com/ctgraham/d21f4153dd95928c740b533a70b3ad94

Marc Bria 2 months ago

BTW... I'm sorry to ask but, is there any chance to extend the script to enable/disable the plugins? (edited)

Clinton Graham 2 months ago

So, actually, plugins can't be enabled properly via the CLI because LazyLoadPlugin::setEnabled() doesn't take a context id, and instead depends on the current request via LazyLoadPlugin::getCurrentContextId(). So, we'd have to mock a request to make this work. We did this in Barcelona for our CLI API testing (hoorah!), but fixing this or working around this is more than I'm willing to take on for this little tool (boo.). I think the correct step here is to build out a Service which allows for interaction with the plugin settings more generally, including enabling/disabling.

Nate Wright 2 months ago

I think the correct step here is to build out a Service which allows for interaction with the plugin settings more generally, including enabling/disabling.
I'm happy to help guide anyone who wants to work on this! A lot of it is just pulling code out of one place and putting it into another. But the deep integration with the Request object is one of the main problems that we're trying to avoid.

[NateWr]

👍 This sounds great, @ctgraham. Depending on what version you are targeting, you'll either use a Service class (3.3 or below) or our new Repository pattern (3.4 or above). If you did the work for a Service class, I think we could commit to forward-porting the code to the Repository pattern introduced in 3.4 -- however, beware that this might delay the final merge since we may not have the resources to put to this right away.

[ctgraham]

This tool can be used to automate plugin installs / upgrades as described here:
https://gist.github.com/ctgraham/d21f4153dd95928c740b533a70b3ad94

[NateWr]

@ctgraham is this in a condition to be merged to main or stable-3_3_0? The PR linked above is against 3_1_2.

[ctgraham]

I've only tested the PR in 3.1 and 3.2; but, it only depends on PluginGalleryDAO::getNewestCompatible() and Application::get(), so it should work correctly in 3.3. It would need to be reformatted for main for tabs to spaces and for swapping import() for use.

[NateWr]

Thanks @ctgraham! I've gone ahead and merged your tool to the main branch in 951c5c4. I changed the plugin file name and dropped plugins/ from the info command.

Call the script:

php lib/pkp/tools/plugins.php

List plugin updates/compatibility:

php lib/pkp/tools/plugins.php list [search]

Get info on one plugin:

php lib/pkp/tools/plugins.php info [path] # path = generic/pln

I'll leave this issue open, since we'd still like to extend the script to support plugin enable/disable/install commands. But this is a great start, thanks!

[ctgraham]

@NateWr , I've backported your implementation against:

• 3.2.1: Plugin gallery cli 3.2.1 #7329
• 3.1.2: #7204: Simple CLI tool to interact with Plugin Gallery #7205

And cleaned up the formatting for:

• 3.3: pkp#7204: PSR-12 whitespace and doc cleanup of plugins CLI tool #7328

[NateWr]

Woohoo! Thanks, @ctgraham! I've merged those in now. Do you have a sense of what further actions/commands we want to add? If so, I'll split those out into separate issues and close this one.

[ctgraham]

Beyond enable/disable/install, I would see value in:

• Running the Plugin Gallery queries without bootstrapping the database (that is, running pre-install)
  • This allows use of the tool for packaging versions
• CRUD on the Plugin Settings (this may be more aligned with the API CLI we mocked up in Barcelona)
  • This allows use of the tool for automating installs with plugin configurations

[NateWr]

Thanks @ctgraham, I've filed two issues at #7342 and #7343. Can you say more about running gallery queries pre-install? Is the goal to be able to download a plugin before install? Not sure what you mean about packaging versions.

[ctgraham]

For running pre-install, I'd like to be able to reference the CLI tool in, for example, buildpkg.sh so that a packaged version of OJS could be built with a set of version-appropriate plugins include in the build, without committing specific git submodules.

Similarly, a brand new install could use the CLI tool to add plugins before the install script is run, or an upgrade script could interact with the plugin gallery while config.inc.php specifies installed = Off.