proposal: seq types for repeated options
shaunc opened this issue · comments
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?
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!
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
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.
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.
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.
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.