You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context: (If I got it right) the current implementation expects a centralized definition of commands and subcommands. When implementing CLI with multiple nested commands; like these AWS or GCP CLI tools (e.g.: gcloud compute instances describe [...]), that file can become HUGE.
I would love to have each command defined in its own configuration YAML file and then feed these configurations back to slap parse through some multi-valued option like --subcommand_config_path. Giving me the opportunity of structuring the repository according to commands and sub-commands like:
So that high-level commands would be simply "routers", looking as simple as:
name: mycommandversion: "1.0"author: Kevin K. <kbknapp@gmail.com>about: Does awesome thingsglobal_settings:
- ColoredHelp
and each nested command would have its own small and concise configuration:
# Example taken from: https://github.com/agnipau/slap/blob/74219a0/examples/simple.yml# Sub-commands field removedname: mysubcommandversion: "1.0"author: Kevin K. <kbknapp@gmail.com>about: Does awesome thingsglobal_settings:
- ColoredHelpargs:
- config:
short: clong: configvalue_name: FILEhelp: Sets a custom config filetakes_value: true
- INPUT:
help: Sets the input file to userequired: trueindex: 1
- verbose:
short: vmultiple: truehelp: Sets the level of verbosity
The text was updated successfully, but these errors were encountered:
Context: (If I got it right) the current implementation expects a centralized definition of commands and subcommands. When implementing CLI with multiple nested commands; like these AWS or GCP CLI tools (e.g.:
gcloud compute instances describe [...]
), that file can become HUGE.I would love to have each command defined in its own configuration YAML file and then feed these configurations back to
slap parse
through some multi-valued option like--subcommand_config_path
. Giving me the opportunity of structuring the repository according to commands and sub-commands like:Then:
So that high-level commands would be simply "routers", looking as simple as:
and each nested command would have its own small and concise configuration:
The text was updated successfully, but these errors were encountered: