Plugins that add command-line commands

[doc-hex]

I'd like to make a plugin that defines a new command-line command. At this point, that doesn't seem possible, and existing plugins are only adding support for hardware wallets so they can interact with standard command-line commands.

Challenges include:

• plugins are not initialized before lib.commands.get_parser is called, so they are not listed in known_commands when the command-line parser is constructed.
• not clear if we are allowed to use lib.commands.command decorator outside of that file.
• there is an unknown command: error message hacked into URI handling for the GUI: electrum:310
• when the command arguments are parsed, we do not yet know if starting the GUI or running in command-line mode
• the configuration is not fully-defined while parsing arguments, so not clear if a plugin is enabled.

My proposed changes (which I would make and submit as a PR for further review):

step 1:

• define a custom argparse.Action() handler for url argument so it's only set if starts with bitcoin:
• remove/replace the "unknown command" error message associated with URI
• do not start the GUI if unparsed command line remains; print error instead (ie. unknown command)
• AFAIK this will preserve the existing behaviour of entering the GUI on: electrum bitcoin:1foo

step 2A:

• add a new "type" of plugin that is used only to define command line stuff: perhaps argparser
• like qt, cmdline are now, plugins may define plugins/FOO/argparser.py and it gets hooked into the argument processing stuff, based on the available_for value defined in plugins/FOO/__init__.py
• plugins of the new type would be loaded very early before the command line is parsed
• a new base class would be used to expose an interface (wouldn't use BasePlugin)
• they can define new commands and existing optparser code would detect them in knowncommands

OR a different approach: step 2B:

• new plugin type, perhaps called early
• this type of plugin gets loaded very early, before the command-line parser is setup
• add some new hooks for updating the arg parser (maybe)
• new plugin type could do almost anything, but I would use it just to register new commands into known_commands

From my point of view, approach 2A is better, but 2B is more general purpose and flexible. The only real difference is that 2A is "more objected oriented".

What do you think of these changes? Other ideas?

[doc-hex]

Just had a much better idea, call it Option 3:

• new global command-line option that enables a (cmdline type) plugin by name: --plugin foobar
• the plugins selected get loaded as early as possible
• they can change the command line parsing of following options (hopefully, not sure if possible)
• no need to wonder if the plugin is enabled or not, because it's explicit
• probably don't need any new hooks
• no need for a new plugin type

[ecdsa]

why not add a hook in the command line parser?