-
Notifications
You must be signed in to change notification settings - Fork 70
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
Use gumdrop or structopt for CLI option parsing #171
Comments
Note that structopt will get you a similar proc macro-based approach to declaring argument parsers and subcommands, although with many more dependencies. That said to me it's felt like a bit of a clunky add-on to I wrote up some of the tradeoffs between
That said, if you're looking for a powerful option parser with minimal dependencies, |
I came here to mirror the above suggestion that we consider holding off until we can determine if a clap v3 release is reasonably imminent. As part of my audit of our dependencies I intend to also make a list of crates that could "use help", e.g. tower-web and clap (for whom v3 is fairly overdue due to low (but not lapsed) activity). |
I also have a background goal right now of reducing compilation times in general, for which my first investigation is whether we can get away with using fewer macros (which is to say, we should be careful about adopting any new crate that provides a macro). |
@bstrie |
After reading issues regarding CLI arguments problem, it seems that no conclusion has been made.
There seems to be Clap 3 on What do you think? |
Investigating whether Clap 3 is ready sounds good to me. I don't think we have very unusual needs so I'd guess if it works at all, it'll work for us |
Alternatively, if we don't have unusual needs it may be that gumpdrop will suffice despite being less featureful, so it's worth at least a cursory investigation as well. That said I can believe that upgrading to Clap 3 would be less effort, so if it doesn't introduce tons of breaking changes then perhaps that will be the deciding factor (for now, anyway). |
If you want gumdrop++, you can always use just the command-line parsing bits of Abscissa, which more or less uses gumdrop as a library but handles the user-facing interactions and hopefully provides a more clap-like user experience. abscissa_core heavily leverages Cargo features, so you can shut off the bits you don't need. Worst case, migrating to clapv3 should be easy since they both use similar proc macro-based argument parsing attribute "DSLs". |
I'll do:
then we'll be able to talk about the choice. |
https://github.com/interledger-rs/cli-investigation I did some investigations on
So... let's go back to the original objective. The original objective was, AFAIK, "codes of CLI are so complex that Clippy warns it" (#169). We cannot adopt
hmmm... I'm not so in favor of
What do you think? |
Is there any downside to using |
It'd be nice if they started getting shipped with the Rust distribution or something. |
Signed-off-by: Taiga Nakayama <dora@dora-gt.jp> interledger#113, interledger#206, interledger#171, interledger#194
Every command accepts arguments, config file settings, env vars. `interledger` and `interledger-settlement-engines` are almost consistent. Signed-off-by: Taiga Nakayama <dora@dora-gt.jp> interledger#171, interledger#113, interledger#206, interledger#194, interledger#215
Every command accepts arguments, config file settings, env vars. `interledger` and `interledger-settlement-engines` are almost consistent. BREAKING CHANGE: Some arguments are now obsolete. On interledger package: server_secret -> secret_seed, btp_server -> btp_server_url, http_server -> http_server_url, redis_connection -> redis_url, http_address -> http_bind_address, settlement_address -> settlement_api_bind_address, btp_address -> btp_bind_address, btp_uri -> btp_server_url, http_url -> http_server_url. On interledger-settlement-engines package: http_address -> settlement_api_bind_address, ethereum_endpoint -> ethereum_url, redis_uri -> redis_url. Signed-off-by: Taiga Nakayama <dora@dora-gt.jp> interledger#171, interledger#113, interledger#206, interledger#194, interledger#215
Closed by #290 |
Instead of
clap
Based on suggestion from @tarcieri in #169
The text was updated successfully, but these errors were encountered: