Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Support nested subcommands or groups of commands or #10

Closed
szaghi opened this issue Apr 14, 2015 · 1 comment
Closed

Support nested subcommands or groups of commands or #10

szaghi opened this issue Apr 14, 2015 · 1 comment

Comments

@szaghi
Copy link
Owner

szaghi commented Apr 14, 2015

Support arbitrarily nesting command line utilities: many CLI tools (e.g. git) has mode or group of commands, e.g. git commit [commit-options], git tag [tag-options] ...

Python module argparse has subparsers (used in FoBiS.py for example).

Python module click (see) has group of commands.

FLAP should implement on of these (or similar) paradigms.

@szaghi
Copy link
Owner Author

szaghi commented Apr 17, 2015

After writing to Victor, the plan for this feature design is:

  • touch the CLI public signature (that is the only one public thing) as less as possible, ideally I want to push a fully backward compatible release; in other words, I want to add the new feature without broken the present usage API; this means that Type_Command_Line_Interface is now being changed, but only it internal, private definition: the public methods signature (init, get, add, parse...) should be untouched;
  • to achieve the previous goal and in the meanwhile support the new feature, I am going to introduce a new private type, Type_Command_Line_Arguments_Group, that is just a grouped collections of Type_Command_Line_Argument (that should remain untouched also internally) with some "facilities" to handle the group itself;
  • modify the internal definition of Type_Command_Line_Interface in order that is behaves as following:
    • if the user defines a "standard" CLI without nested/grouped CLAs or the CLAs under defining is not associated to a specific group, these CLAs are stored into a default group that is automatically created always; the user interaction remains as it is now;
    • if the user defines that the CLAs under defining must be associated to a particular group, the default group is changed (on the fly) to an array of groups (indeed it is always an array: only its dimension changes): the group number 0 is always devoted to CLAs that are not grouped, while other groups (>=1) are the other grouped CLAs.

Questions to be answered:

  • how different CLAs-groups must interact?
  • how mixed grouped CLAs/non grouped CLAs should interact?

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant