fsprojects / Argu

A declarative CLI argument parser for F#
https://fsprojects.github.io/Argu
MIT License
447 stars 74 forks source link

Positional Arguments and "Raw" arguments #111

Open matthid opened 6 years ago

matthid commented 6 years ago

Description

Currently I'm trying to improve the FAKE 5 CLI even further by having multi-phase parameter parsing (at least I'm playing with the idea). This means I somehow need to be able to forward parameters from a given point to the next level (unprocessed by Argu). In POSIX we would use -- for this.

Examples: Assume that --conflictingArg is defined in the Argu type and you emulate a single positional argument via GatherUnrecognized:

example.exe build.fsx --unparsedUnknownArg --conflictingArg

In this scenario I'd like Argu to take all unrecognized arguments. This case works okish. The only thing I don't like is that once one argument is "Unrecognized", here --unparsedUnknownArg I'd like Argu to mark all following arguments as unrecognized as well. However adding this feature would break my usage of GateherUnrecognized because then I can no longer use it for the positional argument (build.fsx).

example.exe build.fsx --conflictingArg test -- --conflictingArg

In this situation I'd like to get all raw data after --. I tried to use string list arguments for this but it didn't work.

@eiriktsarpalis Can you sketch out an idea how you would integrate this feature into the Argu code-base? Or is this already possible?

My current thinking is that this needs two things:

Maybe this syntax is a bit ambiguous I haven't worked out the details yet. But my options in Argu are quite limited at this point so I'd try to extend them.

Known workarounds

Don't use a CLI like above.

bartelink commented 7 months ago

Looks like Eirik won't be answering this...

I'm hoping this issue can be converted into something actionable - right now it's half way between a feature desc and a question

106 seems to cover the -- feature, in terms of having a tracking issue

Would you consider fleshing out the overall feature idea and/or closing after making sure that your high level needs are covered in #85, #106

Alternately, this and @haf 's #107 seem like they have enough overlap to be worthwhile to merge?