Proposals/Mahara Shell

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 currently working items also 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.