Review how "help" works

[jenstopp]

Initially, the idea was to print the help text of the main module of a command.

Alternative proposal:
Print the command's description followed by the help messages of all used modules.
The help messages of the modules should dynamically include the module configuration.

Maybe there should be two methods in the module interface instead of "help": "info" and "usage".
In the mentioned proposal, the "info" method is called on all modules of a command, except from the main module. For the main module, the "usage" function is called.

The "info" functions prints module information including configured settings, whereas the "usage" function gives information on what cmd line arguments can be used.

[RiSKeD]

I think we need to differentiate between the user and developer experience.
Users of the configured dutagent will only care about one thing when executing help on a cmd: What is this command, and what are the options? The underlying modules and usage of those is not of any significance IMO. This is why i would propose just printing out the description of the command.

Concerning your proposal: If we include the "info" method of all used modules we drown the user in not-relevant information IMO. Now, it might make sense to include the "usage" part of the main/interactive module. But the tricky part is that it needs to be contextualized with the goal of the entire cmd. So IMO it makes sense to print both description + "usage" if a main module is specified? What do you think?

[RiSKeD]

Now if we want to have also have the possibility to see how the cmd is exactly configured. So what modules are part of it and how are they configured themselves. Maybe we can add a separate command "info/config", which prints out this information?
So we would have to separate "help" cmds, one concerned with user help and one more techincal for developers.

[RiSKeD]

The goal should be to provide short, useful help text what a user might expect the command to do and what input is expected.
My suggested help text examples if we go on with command level templating and making main optional:

• Case 1: Config has set a module to interactive(main) -> Args are passed 1:1 to the module. When calling help show the usage + description of this module.
• Case 2: Config is using templating -> Show usage by displaying the named args in a convenient way. Also show description of comand.
• Case 3: Both are not set, meaning no user input will be recognized -> just print description of the command.

So essential always print out a command description. The usage information will be context dependent if it is templated, interactive or non-interactive.

[RiSKeD]

Additionally i would propose another help-like cmd -> config, doc, ... which prints all the information of the command very verbose: command description + templates, module description + usage + args, etc.