-
Notifications
You must be signed in to change notification settings - Fork 519
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
Be consistent with command line parsing by standardizing on clap
or argh
#2373
Comments
I would like to take this. Does this concern with the testsys repo as well? bottlerocket-os/bottlerocket-test-system#535 |
Awesome, that would be great @alok-sin! I'm not 100% on the If you could start in this repo that would be ideal. Then we can hopefully have a little better understanding if anything should be updated in the other repo once that is done. Thanks a lot! |
How did you arrive at standardizing on argh instead of clap? I think clap is becoming the de-facto standard crate for this. |
@bcressey had expressed a desire to go with argh over clap. If clap is becoming the standard for this, then perhaps we should reevaluate that position. I am fine either way - I would just like to see us using one or the other. |
I don't feel as strongly about "only one" but I definitely don't want to add That's primarily for reasons of code size. It's not a huge factor for existing builds, but there are some use cases (like a microVM guest) where size is a concern. I don't like the idea of spending 10+ MiB of space for arg parsing that no one will ever see. |
I also don't feel strongly about "only one" and would hate to see us go from clap -> argh in places where we are using clap now. Have you checked the size of the compiled code of clap vs argh? Just curious if it's a big contributor to binary size. |
argh
crate.clap
or argh
|
I looked into this last time it was brought up and while |
What I'd like:
Most of our CLIs use the
argh
crate for parsing command line input. But some are usingclap
instead.It would be good to convert these over to
argh
so we are consistent across our code and avoid importing two different crates that provide the same functionality.Any alternatives you've considered:
Could keep them as is since there is no conflict between using the mix of the two, but not a real reason not to just use one or the other.
The text was updated successfully, but these errors were encountered: