Actions

Difference between revisions of "Proposals/Mahara Shell"

From Mahara Wiki

< Proposals
(→‎Progress: I think this is ready.)
m
 
(One intermediate revision by one other user not shown)
Line 48: Line 48:
  
 
At this point I'm using <code>cli</code> as a prefix to identify methods for the <code>mash</code> command. I'm considering changing this to <code>mash</code> to make it stand out a bit better.
 
At this point I'm using <code>cli</code> as a prefix to identify methods for the <code>mash</code> command. I'm considering changing this to <code>mash</code> to make it stand out a bit better.
 +
 +
Further details/discussion in the minutes from the [[Developer_Area/Developer_Meetings/87|Mahara Developer meeting on Tuesday, 18 Jan.]]

Latest revision as of 16:04, 18 January 2022

tl;dr;

  • add a mash command to the project root
  • for reasons we should move the existing CLI scripts out of the webroot.
  • create a single wrapper for all CLI commands
  • creates a consistent 'pattern' for CLI commands
  • moves the processing of these commands to the libraries they act on/from.

The issue & proposal

There are some reasons to move the CLI scripts out of the webroot. They are outlined on the linked bug.

The current way we build new 'commands' is to create a new one-shot script to do a task. All the logic for that lives in the script and is distinctly separate from the code that it may be using. This makes for potential issues when updates may alter the data structure being acted on. Bringing the actual command code into the class that it is acting on will remove that separation.

Command discovery is difficult. Unless you know 'there is a script for that' you are unlikely to check for it. The new approach will expose all commands available through a simple call to ./mash with no parameters.

Effort

The proposed approach would be to have a single script that examines the codebase looking for cli commands. This would start with walking over;

  • a stand-alone directory outside of the webroot for outlier commands (commands that don't really fit in existing libraries)
  • all plugins
  • all modules

These are currently discoverable and easily checked. Each class is included and checked for the command declaration method. This returns a simple array with the details to describe/execute the commands made available.

Progress

I've been working on the Elasticsearch 7 upgrade and found myself doing resets of things very frequently. This was more time consuming than I liked so I actually made a start on this.

Currently I have the following commands already working for me:

  • ./mash search-queue
  • ./mash search-reset-index
  • ./mash search-reset-cron-lock
  • ./mash cache-clear

The mash script currently does command discovery. I would like to refactor how this works already and add annotation based discovery rather than checking for the existence of the method. The discovery code is currently in the mash script and this should be moved to the cli class.

The items currently working are very basic from the perspective of how much of the cli class is used. More fully featured use of the class still needs to be tested.

Creating a mash command

Currently there are 2 methods you can add to a class to get a new command added.

cliGetCommands() : Returns an array defining any commands the class adds. This is an array of arrays and gives, at minimum, a title, name, and method. Title as the plain label of the command. Name is the name of the command. e.g. ./mash [name]. Method is the function in the class that is executed.

cliMyMashCommand : The method executed.

At this point I'm using cli as a prefix to identify methods for the mash command. I'm considering changing this to mash to make it stand out a bit better.

Further details/discussion in the minutes from the Mahara Developer meeting on Tuesday, 18 Jan.