Discuss and document python/CLI interface designs

[benfitzpatrick]

Discuss and document:

• should we pass in cubes into python in any order? (e.g. Abstract base class for plugins that need to unpack lists of input cubes #1754)
• can we simplify the clize handling?
• how do we handle ancillary file inputs? (e.g. Update CLI ordering #1553)
• how does this evolve with more Python-based multiprocessing execution of improver?

[cpelley]

Thanks for raising @benfitzpatrick

Passing cubes in any order is something I have been pushing since coming to the area (using metadata rather than relying on index). To that end, #1754 is one method which works towards this goal. I'm not 100% that the use of clize and of the existing plugin framework is the simplest and most transparent approach for improver but perhaps #1754 is a reasonable approach for the existing framework at least for now given that it is self contained.

Since python execution, we needn't necessarily go via the CLI (clize). So it begs the question whether we need clize or a CLI for that matter. paraflow task_runner might potentially become responsible for calling our 'plugins' directly.
I think plugins could be handled via a simple factory class where you register your plugins (inc. a register decorator). This would allow registering external plugins easily too - one might want non-improver plugins perhaps in paraflow which do python based system equivalents like copying files, creating symbolic links etc. (something I have been thinking about in https://github.com/MetOffice/improver_suite/issues/1220).

Just running thoughts off the top of my head :p