Migrate to bpaf command line parsing and completions#239
Conversation
Coca162
force-pushed
the
bpaf
branch
3 times, most recently
from
5a9ea20 to
2659268
Compare
|
Changing the nix tests so that |
|
o/ Upstream here :)
Not happy with that either. Originally I had it generating native fish completions, turns out fish caches them between runs instead of asking for a new set every time leading to wrong completions being offered. There was a ticket open about this specific issue and it was closed with "well, nobody does dynamic completions like that so current behavior is fine". Duh. I wonder why nobody does it.... But that was in C++ days, maybe it behaves differently now. Will revisit at some point now that I have more robust testing system for completions in place.
You can make one yourself. To support stuff like
Kind of hard to do something about it at the moment. Slowly reworking some bits to make it easier to tweak it, but no ETA promises.
Same as with changing help formatting. There's something that works, but I'm planning to revisit most of the documentation. No ETA.
Some :)
❤️
Should become less cursed in the next major release (still no ETA)
Lax Monoidal Functors FWIW. |
| let normal = pure(Self::Normal); | ||
|
|
||
| construct!([full, partial, normal]) |
There was a problem hiding this comment.
This should give the same parsing behavior, but slightly better error messages if something goes wrong.
| let normal = pure(Self::Normal); | |
| construct!([full, partial, normal]) | |
| construct!([full, partial]).fallback(Self::Normal) |
| pub repository: String, | ||
|
|
||
| #[command(flatten)] | ||
| // #[command(flatten)] |
There was a problem hiding this comment.
if you want to use derive macro - it would be #[bpaf(external)]
| }) | ||
| }) | ||
| .fallback(GitForgeOpts::Auto) | ||
| .format_fallback(|_, f| f.write_str("auto")) |
There was a problem hiding this comment.
.display_fallback() will probably do the same if for GitForgeOpts::Auto std::fmt::Display says "auto".
There was a problem hiding this comment.
Yep yep, just went for the quickest route here but might as well
| let github = construct!(GitHubAddOpts { | ||
| more(GenericGitAddOpts::parser()), | ||
| owner(positional("OWNER")), | ||
| repository(positional("REPOSITORY")) |
There was a problem hiding this comment.
This syntax is going away in the next big release (no ETA), I think it's confusing after all.
| at(long("at").argument("VERSION").help("Use a specific release instead of the latest.").optional()), | ||
| version_upper_bound(long("upper-bound").argument("VERSION").help(r#"Bound the version resolution. For example, setting this to "2" will restrict updates to 1.X versions."#).optional()), | ||
| package_name(positional("PACKAGE").help("Name of the package at PyPi.org")) | ||
| }) |
There was a problem hiding this comment.
And that's the example why I don't like this syntax :)
Compact, but no rust-analyzer, no rust-fmt, etc. Having a few variables defined outside and referring them from the macro is cleaner
let at = long("at")...
...
let pypi = construct!(PyPiAddOpts { at, version_upper_bound, package_name });`There was a problem hiding this comment.
The temptation of trying to make it concise got to me! I definitely agree with your assessment that its a bit scuffed though, I have similar reasons as to why I don't like derive macros as well.
2 participants
Lots of cleanup needed, I'm also not happy with how there is some bugginess and differences in the completions compared to with the native fish completions. There is also no
helpsubcommands currently and the help formatting is different in ways I minorly dislike. All flags are global as well, though this is not indicated in help. Hopefully some of these can be dealt with upstream.Otherwise this was library was pretty fun to work with even including the relatively cursed way to share the lockfile to completions. Combinatorics are much nicer then what clap offers imo.