Type Support Beyond Primitives about argu HOT 6 CLOSED

I'd be in favor of implementing something like that, but the design certainly needs polish.
Why not just use interfaces, i.e.

type ICustomParser = interface end

type ICustomParser<'T> =
    inherit ICustomPrimitive
    abstract Parse : string -> 'T
    abstract UnParse : 'T -> string

Then just have the argparser take a list of the base interface. The UnParse implementation is needed in order to fully support the PrintCommandLine method. Thoughts?

from argu.

I used string for the unparse in

let inline mkComplexParser< ^a when ^a:(static member Parse:string -> ^a)>() = 
    (typeof< ^a>, ParserInfo.Create< ^a> (typeof< ^a>.Name) (fun str -> 
        (^a:(static member Parse:string -> ^a) str)) string)

I used the static method for parse as it seemed like that was the common contract you were already using, and there are a bunch of other types (Guids, Uids, TimeSpans, IP Addresses, enums, etc) that share that signature.

If you've going to deviate from that I think you should go even further and make parser combinators. At the very least to support verbs and subparsers, they're the most important feature Argu is missing. Ideally the functionality of the combinators could extend into formatting transformations, different modes of execution, more nuanced help displays, color modulation, minor animation, etc. (or maybe I love FParsec a bit too much)

Are you open to supporting file formats besides XML for config files? It'd to be able to use Argu with Toml configs..

Just out of curiosity, do you think it'd be feasible to modify Argu so that it could generate a CLI for cmd as well as a posh (powershell) cmdlet with similar usage conventions? I'm not in love with posh, but I don't mind writing out cmdlets in F#, and it might be fun to use on some Nano Servers.

I'm down to help you take the implementation/functionality as far as you want to run with it.

from argu.

There are many features missing from Argu and the codebase is arguably stale. I'm currently not very motivated in contributing improvements to the library, so I'd be positive to someone else taking over development. Perhaps this would be facilitated by a move to fsprojects.

from argu.

probably, I've talked to a bunch of people who were interested in it, but wished it had a fuller feature set.

from argu.

@eiriktsarpalis have you decided whether you want to move it to fsprojects?

from argu.

Yeah, we're up for it. We just need to find a couple of maintainer outside of nessos and make the move.

from argu.