slap
slap copied to clipboard
Dynamically generate subcommands list
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:
.
└── compute
├── instances
│ ├── create
│ │ └── slap.yaml
│ ├── delete
│ │ └── slap.yaml
│ ├── describe
│ │ └── slap.yaml
│ └── slap.yaml
└── slap.yaml
Then:
# when running `gcloud compute`
cat ./compute/slap.yaml | slap parse bash _ --subcommand_config_path=./compute/instances/slap.yaml -- "$@"
# when running `gcloud compute instances`
cat ./compute/instances/slap.yaml | slap parse bash _ --subcommand_config_path=./compute/instances/{create,delete,describe}/slap.yaml -- "$@"
So that high-level commands would be simply "routers", looking as simple as:
name: mycommand
version: "1.0"
author: Kevin K. <[email protected]>
about: Does awesome things
global_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 removed
name: mysubcommand
version: "1.0"
author: Kevin K. <[email protected]>
about: Does awesome things
global_settings:
- ColoredHelp
args:
- config:
short: c
long: config
value_name: FILE
help: Sets a custom config file
takes_value: true
- INPUT:
help: Sets the input file to use
required: true
index: 1
- verbose:
short: v
multiple: true
help: Sets the level of verbosity