Open james-nesbitt opened 7 years ago
Reasoning: The current CLI is a pretty thin wrapper over the API runtime operations. It really just lists all operations by machine name, and all parameters for an operation by machine name. This makes it a little heavier in typing. To be clear, the machine names of these operations are unique values, and all of the metadata about the operations comes directly from the operations defined by the loaded handlers.
It is a longer term goal to develop the UI for the CLI to be more hardcoded for certain operations, and to do more work to present specific operations and interpret them into machine names. This is something that makes sense to do when the usage patterns are more stable.
In reality, it is possible that it makes sense to use different CLIs, per common usecase for the CLI, each using it's own handlers, and perhaps handling operations and parameters differently. This would also allow each CLI to use only handler libraries that it needs, making the binaries smaller.
Anybody who wants to know more about how this CLI does it's magic should know:
The CLI can basically be divided into 2 pieces:
1) building the runtime API from the various handlers and configuration in the project (usually the yaml) 2) converting global arguments and executing the handlers to get lists of operations, and turning those operations into CLI commands
Part 1 is mainly https://github.com/wunderkraut/radi-cli/blob/master/local/api.go#L32 , wheras #2 is primarily in https://github.com/wunderkraut/radi-cli/tree/master/main. If you wanted to fork the CLI, to build a better UI, you could simple re-use part #1, and run your own interpretation of the operations.
In fact, even #1 is heavier than needed, if you don't need the security authorization aspect (which isn't complete at the moment anyway)
The typical CLI commands are really long, and are annoying to type.
Some shorter names would be nice, and maybe some autocomplete would be handy.