Chain of subcommands

[aurelien-naldi]

I would like to provide an CLI with a succession of subcommands instead of a single one, and it looks like clap does not handle this case (it's more than adding a subcommand to another subcommand). The following is a bit long and verbose to clarify what I would like to do and why.

In summary, I am designing a tool with a collection of data analysis features. It needs to specify which data to load and then which analysis to perform. Up to this point, I'm fine with what clap provides: I use global arguments to specify the data to load and one subcommand for each type of analysis. However, it gets a bit more complicated now that I want to be able to transform the data before performing the analysis. To support this, I would like to provide several layers of subcommands, organized as follows:

• The first layer is data loading or generation with two subcommands (load and generate). Exactly one of these subcommands must be specified.
• Then, I want a set of data transformation subcommands (lets call then transform, change, update). The user could skip this group entirely, or use one or several of them. He could even use the same one several times. Different transform could be applied sometimes in an order and sometimes in a different order.
• Once the data has been loaded and transformed (if needed), we can specify an analysis subcommand (lets call them display, export, study, whatever). I expect that exactly one of these subcommand is specified at the end of the command. I could also imagine performing several analysis or even performing one right after data loading, repeating it after a first transformation and again after a couple more transformations.

It would lead to relatively natural commands. For example in the simplest case:
tool load data.txt *study* -k

And when including some transform:
tool generate data.txt transform -n update param1 param2 export -o output.txt

Or more complex chains:
tool data.txt study -k transform -n display update param1 param2 export -o output.txt study -k

It can be abstracted out by defining input/output types for subcommands:

• the first layer has no input and the data type as output
• the second (transform) layer has the data type as input and output
• the last (analysis) layer has the data type as input. We can consider that it also has it as output if we want to apply several analysis or possibly different types for analysis which could be fed to yet another "post analysis" layer.

In this setup, the available commands depend on the current type (none when the program is launched) and evolves along the chain of commands.

Coming back to clap:

I am currently abusing the common parameters to encode the transformations, but it gets ugly to implement and to use. I am considering to do a first analysis of parameters to split subcommands and then use separate clap "programs" to parse them separately, but I will end up having to implement a wrapper for the help command (which is OK if I can delegate to clap for individual subcommands) and do a lot of parsing myself (which I would rather avoid). Can clap perform partial parsing to make it smoother? I mean calling clap to parse the first layer (load and generate subcommands), retrieve the first subcommand and its arguments and being able to call clap again to parse the next subcommand and so on until all command line parameters are consumed. It would still mean having to deal with the help command myself but it would be a nice solution for me. If a subcommand can take a list of random words as arguments, it would have to avoid consuming the next subcommand, for example by using the "--" trick or something similar.

• did I miss something and is this type of pattern already supported?
• Do you have suggestions or well known methods for handling this?
• Otherwise, would it make sense to add some helper code to facilitate this or it it completely out of scope?

Thanks!

[pksunkara]

I don't think this is easy to implement and such a rare case that I am afraid the maintainers would be hard pressed to work on this. If someone can make a PR, we will be happy to help.

[aurelien-naldi]

That's pretty much the answer I was expecting, but I thought it was worth asking: I'm often surprised how some "corner cases" end up being well studied if you dig a bit.
I will experiment with successive rounds of seemingly separate commands: it may be hard to do something generic, but for my use case it should remain fairly simple.

[CreepySkeleton]

I'll conduct a proper analysis a bit later, but at the first glance it looks a lot like #1407

[aurelien-naldi]

It seems similar indeed, but maybe a bit more general as I would like to let a set of commands be subcommands of themselves.