proposal: seq types for repeated options

[shaunc]

I have been using comandeer happily, but now need to collect multiple values of an argument. To support this, if an option is specified as:

option name, seq[type], long, short [, default]

Perhaps that could trigger the ability to receive multiple values of type?

[fenekku]

Hello! Sorry about the delay. My notifications were off for some reason 😕 .

This exists for the argument case and it is called via arguments. There is no equivalent for option but I don't think this is necessarily intentional. Let me look into it.

Thanks!

[fenekku]

So... after looking into this I remembered why I didn't implement this in the first place 😐 .

First, there is no convention (yet) on parsing multiple values for a single option in parseopt2 the standard library used to parse the command line. By that, I mean:

$ myCLI --option=arg1 arg2 arg3

is interpreted by parseopt2 as a cmdLongOption with key option and value arg1 followed by 2 cmdArgument with respective values arg2 and arg3.

Now, this is not too bad as we could build an interpretive scheme to read arg1 and arg2 as other cmdLongOption (or cmdShortOption whatever the case may be) manually. Unfortunately the code architecture I used doesn't allow me to do that because relative option to argument ordering is lost in my code (so I can't tell which argument should actually be interpreted as an option). A rewrite is necessary to be able to catch the right ordering. I have a better design in mind that will address this but it won't happen just now.

A good alternative for now is probably a combination of subcommand and arguments:

commandline:
  subcommand doSeq:
    arguments listOfArgs, int, false

[fenekku]

A quick update on this: although the just pushed version 0.11.0 doesn't allow multiple option à-la arguments yet. I did rewrite commandeer to preserve argument/option ordering and the implementation for arguments is easily portable to options.

All in all I can see options coming in future releases.

[genotrance]

I wanted to use commandeer for nimgen's CLI interface but cannot due to this limitation.

-I include1 -I include2 ... is what I want to do for n.include.

genotrance/nimgen#20

[fenekku]

What about the aforementioned options syntax which would be: --include include1 include2 in your case? You could even implement it by copying and tweaking arguments.

I am not too sure about the generalization of the expected semantic of -l include1 -l include2. I can see in one situation being composing a list for option -l like you are presenting and in another overriding -l so that more complex shell setups allow one to override options previously given. This will need more thought and research.

Thanks for letting me know options is something desirable.

[genotrance]

I'm fine with -l include1 include2 but will it be smart enough to know file1 -l include1 include2 -x exclude1 exclude2? Meanwhile, I have seen more instances of -i include1 -i include2 but am open either way.