Dynamically generate subcommands list

[macunha1]

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. <kbknapp@gmail.com>
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. <kbknapp@gmail.com>
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