Add support for commands

[mmihic]

Allows applications to register additional commands that can be run
directly from the jar, typically used for utility commands. For example,
an application might register commands allowing for interaction with the
service from the command line, supporting scripting of administrative or
operational tasks.

If no command is specified on the command line, the service is started
and blocks until terminated (consistent with the prior behavior of
running the jar)

[nbroyles]

Very cool.

Might be worth nothing somewhere that you don't want to run commands in environments like Kubernetes as it will just cause the command to be run repeatedly, since Kubernetes expects whatever's running in its container to never terminate and will attempt to restart.

[mmihic]

Yeah the point of this is to make it easier to provide administrative commands that you'd either run interactively on a VM, or would put into an admin script / cronjob

[ryanhall07]

I always found the "split mode" for the SQ service container error prone. Every Component had to be careful what to install during UTILITY mode. For example, the initial version of the feeds module would spin up real feed consumers when somebody would run a command.

Do you plan on recreating the same thing in Misk?

[ryanhall07]

is info the right level?

[mmihic]

Definitely not - this is intentionally designed to avoid that confusion. The problem in SC land is that the lifecycle of the application is controlled by the container, and the set of modules/services installed is global to the application rather than being specific to the command, so there was a) no way for a command to avoid starting services (the container did it automatically), b) no way for a command to control which services were installed (any dependencies declared on the application got installed, even if some weren't used by the command), and c) no way for a service to know whether it should let itself be started (a binary UTILITY mode is insufficient, since some commands might want some services and the service has no way of knowing).

The PR doesn't have any of that complexity - there are no modes, no enforced lifecycle, no automatic module/service installation, really no "container" per-se. There are just named commands that have parameters and a run method, with MiskApplication.run() being just a shell that parses the arguments to main() to determine which command to run and to populate that command's parameters with the values from the command line. Nothing is automatically installed by the container - if a command wants dependencies injected, it needs to explicitly specify the full set of modules/services to install. And nothing is automatically started - if a command wants to start services, it needs to explicitly do so in its run method. If no commands are installed or no arguments are passed, the application runs a default command that starts the server and waits for termination.

[ryanhall07]

if a command wants dependencies injected, it needs to explicitly specify the full set of modules/services to install.

nice! thanks for the thorough explanation!