d-e-s-o
commented
5 years ago Thanks for bringing this topic up for discussion.
I agree that structopt provides a nicer model to work with and I would be in favor of moving more towards that. But at the same time: I don't think that is a must. The degree of "pain" (for lack of a word with less negative connotations) of using argparse directly depends on how many things you need it for. For small programs the existing model is fine, I would argue. And even for a program with a good amount of parameters and subcommands it's not the worst (some getopt style solution is probably much worse). It's a compromise as so many things (which is also what I was getting at when saying that "it fills a niche") :-)
In nitrocli, a project we currently use the crate in, we've gone through some effort to generate things such as enums used by argparse and descriptions of parameters. Right now that is only happening through the usage of declarative macros and very limited. I plan to look into this a bit more and perhaps the results of that investigation could be of benefit here (although I should mention that this is not a priority of mine right now and I have limited time available for the project to begin with; I also don't necessarily want to go down the procedural macro route unless I see a big need).
That being said, I don't think points 1. and 2. are necessarily mutually exclusive. As you said 2. could easily be an addon, if, say, it was procedural macro based. As for point 3., it may be worthwhile getting in contact with the authors of clap and structopt to understand whether that is a concern of theirs, if they have done anything to do about that, and to see if the root causes are understood. Perhaps we should also first check if structopt incurs the same binary bloat, which I assumed but did not verify (if the compiler is unable to eliminate much code for clap for a simple project it appears unlikely that it will do so in the context of another crate built on top; but we should be sure).
As for clap I am fairly confident that the author is interested in getting the size down as there are multiple articles on the subject (this one that I linked in the pull request already, for example). However, given what I have read so far I am cautiously pessimistic about the outcome. I shall inform myself some more on what has been done and where things are, though.
My suggestion would be as follows:
1) Check whether structopt is as bloated as clap (I would probably be able to report something on that front unless you want to look into that @tailhook)
2) Read up on clap's optimization attempts and see if
2.1) The root cause of the bloat is fully understood
2.2) We can do anything about that
I plan on reading what the author of clap has written up in full. Of course, it doesn't hurt if multiple people have that background.
3) At the same time (mainly for the reason that I don't think moving closer to the structopt model is a must) I do think that https://github.com/tailhook/rust-argparse/pull/50 should be merged and a new version released, as it is a bug fix. Okay, that one is driven by my need for the fix :)
tailhook
cronokirby
ijackson
sunshowers
I was used to thinking that this library is not needed anymore because clap and structopt do the job just well. But there are valid points by @d-e-s-o, the most important of it is that clap is very large in size.
On the other hand, I very much like the model structopt provides (i.e. parse in the structure instead of complex borrows). The actual semantics of structopt annotations are sometimes ugly though because it is a thin wrapper around clap (with different actual syntax).
So we have a few options: