Use class factories to generate new subcommands where appropriate within the CLI. There are several locations where this could be done. Some examples include:
geoips list families <interface_name>
geoips get family <interface_name> <family_name>
geoips list plugins <interface_name>
geoips get plugin <interface_name> <plugin_name>
Where the interface_name would become a new set of dynamically created subcommands.
Background and Motivation
Currently there are several locations where we call add_arguments with choices to handle the various interfaces. Commands like geoips list interface <interface_name> set add_argument(choices=<list_of_interface_names>). Making these into subcommands rather than an argument with choices will make the CLI function more cleanly and consistently and will help with exposing information about the available commands from the CLI. It will also simplify usage messages.
Alternative Solutions
Wait until we have made a decision about whether to change to an inheritance-based model for these classes. I'd prefer to do it now, though.
Checklist for Completion
[ ] Develop a class factory that can generically be used for adding subcommands to any parent command. At minimum, it should accept the parent command instance, a list of the subcommand names, and a function that will act as the add_arguments function on the new classes. Please implement any other required arguments to the class factory (e.g. other properties or functions that should be added via the factory.
[ ] Find and list all locations where a class factory would be appropriate for generating subcommands.
[ ] Run the unit tests to ensure that everything still works as before. This shouldn't really change behavior except in the help and usage messages.
Blocking issues
This is likely blocked by #576 or vice versa.
Requested Update
Description
Use class factories to generate new subcommands where appropriate within the CLI. There are several locations where this could be done. Some examples include:
geoips list families <interface_name>geoips get family <interface_name> <family_name>geoips list plugins <interface_name>geoips get plugin <interface_name> <plugin_name>Where the interface_name would become a new set of dynamically created subcommands.
Background and Motivation
Currently there are several locations where we call
add_argumentswithchoicesto handle the various interfaces. Commands likegeoips list interface <interface_name>setadd_argument(choices=<list_of_interface_names>). Making these into subcommands rather than an argument with choices will make the CLI function more cleanly and consistently and will help with exposing information about the available commands from the CLI. It will also simplify usage messages.Alternative Solutions
Wait until we have made a decision about whether to change to an inheritance-based model for these classes. I'd prefer to do it now, though.
Checklist for Completion
add_argumentsfunction on the new classes. Please implement any other required arguments to the class factory (e.g. other properties or functions that should be added via the factory.