Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a command line option parser package #33

Open
alexrp opened this issue Nov 28, 2021 · 6 comments
Open

Provide a command line option parser package #33

alexrp opened this issue Nov 28, 2021 · 6 comments
Assignees
Labels
area: build Issues related to the build system. area: documentation Issues related to the documentation. area: options Issues related to the options parser. area: samples Issues related to the sample projects. state: approved Enhancements and tasks that have been approved.
Milestone

Comments

@alexrp
Copy link
Member

alexrp commented Nov 28, 2021

Some kind of compromise between Mono.Options (too simple) and System.CommandLine (way too complex).

@alexrp alexrp added type: feature state: approved Enhancements and tasks that have been approved. area: documentation Issues related to the documentation. area: samples Issues related to the sample projects. area: capabilities Issues related to the Terminfo capabilities API. labels Nov 28, 2021
@alexrp alexrp self-assigned this Nov 28, 2021
@alexrp alexrp added area: options Issues related to the options parser. and removed area: capabilities Issues related to the Terminfo capabilities API. labels Nov 28, 2021
@alexrp alexrp added this to the v1.0 milestone Dec 20, 2021
@alexrp alexrp added the area: build Issues related to the build system. label Dec 30, 2021
@scottbilas
Copy link
Contributor

Might I humbly suggest something inspired by Docopt.net? (This particular library impl has serious problems, but the spec-as-docs concept gets my kudos.)

@alexrp
Copy link
Member Author

alexrp commented May 22, 2022

I do like the idea behind docopt, but I'm not exactly sure yet what form this API will take. I'm thinking something vaguely along the lines of Spectre.Console.Cli, but a bit simpler.

My gut feeling is that a docopt-like implementation should sit at a higher level, essentially as a wrapper around such APIs. It could even be made AOT-friendly by using source generators to generate the relevant classes during compilation.

@scottbilas
Copy link
Contributor

Agreed on source generators - runtime parse- (docopt, mono.options) or reflection- (spectre, powerargs) based approaches add unnecessary startup cost, and move some problems from the compiler to the debugger. Docopt used an older T4-based method to generate static types, but removed it due to maintenance cost in favor of a source generator-based approach..which is still just in the idea phase.. (docopt/docopt.net#119).

My gut feeling is that a docopt-like implementation should sit at a higher level, essentially as a wrapper around such APIs.

Maybe I lack imagination, but I can't picture an API that would benefit docopt. All it needs is a string[]. I'd expect that any lower level processing would just be redundant or interfere with the work a docopt state machine is needing to do anyway. And a sourcegen-based docopt would be statically generating all the config types from the doc spec, so the spectre style user-defined types+attributes would have no place.

(That all said, I guess most C# users will expect a config API more like Spectre.Console.Cli, and it's got to be a lot simpler to implement.)

@alexrp
Copy link
Member Author

alexrp commented May 23, 2022

I'm not super familiar with docopt but a quick skim of the page you linked made me think that a docopt library could just take a help string as input and generate (at compile time) Command/CommandSettings classes to match the specification (if we're assuming a Spectre.Console.Cli-like lower-level API). Maybe there are nuances I'm not aware of though.

@scottbilas
Copy link
Contributor

True, it can be codegen'd from the help string, and I think the Command system would be at least one place that would make it beneficial for a docopt type library built on top of a lower level API.

But that lower API still needs to be told how parameters and aliases map onto class members and so on. Spectre.Console.Cli-type API's do this with attributes:

image

This is what I meant by redundancy - the lower-level API has to walk types and attributes and do some string parsing (as in the above example) in order to construct its in-memory spec. Yet the docopt library would have already done all that work at compile-time. It gets thrown away..

Now, if this lower level API provided a way to feed it the specification, without requiring attribute-scanning, then a docopt system could codegen that part and maintain zero-overhead startup.

@alexrp
Copy link
Member Author

alexrp commented May 23, 2022

Now, if this lower level API provided a way to feed it the specification

Hmm, it would probably have to, at least if it's based on source generators as well, which is what I'd prefer. So in such a world order, both the class/attribute-based API and a docopt-like API could build on top of that low-level model API.

@alexrp alexrp modified the milestones: v1.0, v2.0 Oct 28, 2022
@alexrp alexrp modified the milestones: v2.0, v3.0 Dec 14, 2023
@alexrp alexrp modified the milestones: v3.0, v2.0 Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: build Issues related to the build system. area: documentation Issues related to the documentation. area: options Issues related to the options parser. area: samples Issues related to the sample projects. state: approved Enhancements and tasks that have been approved.
Development

No branches or pull requests

2 participants