Comments (7)
I'll light some examples, which would you prefer?
Geeh, don't really like any of them, but if we really wanted to pick one, then it should at least be the none breaking required
one. Most program parameters tend to be optional, so let's make that the none friction path.
I would love to have possibility to generate such help response with just custom struct parsing. Is there some plan for such feature?
Are you referring to something similar to what zig-args
does? Generate everything based on a struct? This is not something I have a need for, but if someone can come up with a good api for it and implements it, then I wouldn't be against it.
Also, I don't mind breaking changes if they are really an improvement over what was there before. Since Zig is not a stable language, I don't think it makes sense for libraries to care about stability yet either.
from zig-clap.
@voroskoi Yep, that looks good to me 👍
from zig-clap.
I'll expand on this a little. The current way you do this, is something like this:
const option = args.args.option orelse fatal("Missing argument `--option`");
I think this is perfectly reasonable, but I do understand that if clap
understood this concept, then the Diagnostic
could report this error like other clap
errors, and the args.args.option
would not be an optional type.
If we really want this it needs to be fleshed out. How would one then specify that the parameter is required using the recommended way of constructing parameters? This is the currently recommended way if you need nothing advanced:
const params = comptime clap.parseParamsComptime(
\\-h, --help Display this help and exit.
\\-n, --number <usize> An option parameter, which takes a value.
\\-s, --string <str>... An option parameter which can be specified multiple times.
\\<str>...
\\
);
from zig-clap.
Great question @Hejsil. I see we need something solid here.
I'll light some examples, which would you prefer?
\\-n, --number <usize> (r) An required parameter, which takes a value.
\\-n, --number <usize> [r] An required parameter, which takes a value.
\\-n, --number <usize> [required] An required parameter, which takes a value.
\\-n, --number <usize> (required) An required parameter, which takes a value.
\\-n, --number <usize> (R) An required parameter, which takes a value.
\\-n, --number <usize> <required> An required parameter, which takes a value.
\\<str> ...
\\
);
On the other hand maybe we could invert it?(breaking)
\\-n, --number <usize> (optional) An option parameter, which takes a value.
\\-n, --number <usize> [o] An option parameter, which takes a value.
\\-n, --number <usize> [optional] An option parameter, which takes a value.
.....
);
Side note:
I see that currently in clap-rs there is a pattern where required arguments are marked as <ARGUMENT>
whereas optional are marked as [ARGUMENT]
(similar to clap.usage(...)
. But I can't find any good looking, non-intrusive alternative with current approach.
TBH I have no good answer for such change. Is there any variation you like?
I would love to have possibility to generate such help response with just custom struct parsing. Is there some plan for such feature?
from zig-clap.
Are you referring to something similar to what zig-args does? Generate everything based on a struct? This is not something I have a need for, but if someone can come up with a good api for it and implements it, then I wouldn't be against it.
Yes, that's what I was looking for! Thanks @Hejsil
I'll dig into this, maybe there is some common ground.
from zig-clap.
Hi,
I would go with
\\-s, --switch [bool] An optional parameter without any value.
\\-n, --number [usize] An optional parameter, which takes a value.
\\-n, --number <usize> A mandatory parameter, which takes a value.
And I would even go further with this:
\\-s, --switch [bool=false] An optional parameter without any value. Off by default.
\\-n, --number [usize=33] An optional parameter, which takes a value, 33 by default.
\\-n, --number <usize> A mandatory parameter, which takes a value. (Default value makes no sense)
I would like an OK, before I start working on it.
It would be a breaking change, but [optional] and is the way everybody does this.
from zig-clap.
Aah, ok that accept might have been a little hasty. Looking into what tends to be done here I've found out the following.
Programs tends to define Usage
and Options
when running --help
. Options
tend to only describe the options available, but nothing about whether they are required or not.
Usage
describes optional/required things. So if we had Usage: program [OPTIONS]
then all options are optional, but Usage: program --option <v> [OPTIONS]
specifies that --option
is required. So only in Usage
does the []
specify if something is optional.
Also, thinking more about it, I really don't want to break anything existing here. Most arguments will be optional, so breaking the <>
syntax for something that is rarely used seems quite weird.
from zig-clap.
Related Issues (20)
- Create a release for 0.11 HOT 2
- Parse int larger than u8 HOT 4
- How to deal with InvalidaArgument error HOT 4
- Passing sensitive input HOT 2
- Create a tag to line up with zon version 0.7.0 HOT 2
- Argument parsing in function HOT 4
- Remove default allocator assignment in clap HOT 2
- infinite loop in parseEx, "while (try stream.next())" HOT 7
- Make `clap.HelpOptions.max_width` unicode aware
- zig-clap doesn't build with zig 0.9.1 HOT 5
- Enum parser
- No longer compiles against zig master
- Why the usage output is so simple? HOT 4
- A parameter without a long name crashes the `stage2` compiler HOT 3
- Seems you have crashed the compiler. A way to work around this is to use the stage1 compiler. This is done by either passing `-fstage1` to `zig build-exe` or setting the `exe.stage1` field to `true` in your `build.zig` file. HOT 2
- Supporting long options of more than one word HOT 1
- Whether subcommands are supported ? HOT 3
- Can't install it using the built-in package manager HOT 1
- Support for multiple positionals of different type HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zig-clap.