Hey @CreepySkeleton It's me.
That’s a cool handle!
Hi there! I'll be monitoring this thread for the next six hours, feel free to ask
So, I saw your message on one of the github issues that we want to combine the efforts for clap_derive and structopt. I completely agree with that. Let's consider it clap v3 release. Do you have any things you want to add to roadmap?
And also is there any document where we can tell people why clap_derive is better than structopt?
yes, there are some thing I would like to change
no_version. It's like fifth leg for a dog, I really regret we've come up with this decision. I would love to replace it with "no version bu default" behavior along with explicit
#[clap(version)] if user wants it to be derived from
Just like #[structopt(about/author)] work
The second thing is - structopt uses one big trait for everything. It involves it's own drawbacks, like it is possible to flatten an enum (erroneously) , see https://github.com/TeXitoi/structopt/issues/328
This is how I would like it to work https://github.com/TeXitoi/structopt/issues/328#issuecomment-574188743
The third thing - structopt desperately needs refactoring. The current code is nothing more than a big batch of function calling each other is non-obvious ways, I would very much like it to build a parse tree, transform it to AST and then generate the result.
It would also allow us to organize the code in passes, like "parsing", "transforming", "generic stuff", "generation". The passes are isolated from each other, each pass does well-defined set of things, producing the result. Right now, when you want to change something you have double check whether it can possibly interfere with some other part of code.
It would also allow use to report error not just one-by-run, but a bunch of errors simultaneously
I really hate this unfamiliar keyboard, lots of types :frown:
About the documenting part - well, we need two things here
First - we need to proofread the existing documentation, it's organized quite poorly
The second thing is obvious - "Moving from StructOpt to Clap_derive" guide, it has yet to be written. I would really love some help at this part since my English is far from perfect
Well, that's about it. Everything else can be done after the release, I guesss
End we will need to import the recent commits from structopt too :slight_smile:
It looks like @kbknapp supports my "few separate traits" approach https://github.com/clap-rs/clap_derive/issues/1#issuecomment-343762115
(I know, 2 years old, but still)
Oh yes, I have some concerns about
parse_* functions being
inherent. This is quite a footgun loaded and ready to go off since users may want to add such a methods for themselves. It would clash with the generated ones. Maybe some sort of
Also, we will need to settle down the organizational stuff with
wg-cli? Who's gonna maintain the
clap_derive repo (I would volunteer , maybe @TexIToi would too).
Also, what do you think about https://github.com/TeXitoi/structopt/issues/79 ?
OK, it's getting late, so I'm out. I'll try to be there tomorrow at 8AM UTC
I am readying a PR to get clap_derive merged into clap using cargo workspaces. So, we will have one big monorepo and all of us would maintain the single repo.
Regarding https://github.com/TeXitoi/structopt/issues/79, IMO we should implement
HashMap<K, V> support in Clap for arguments.
parse_*, can't we create something like
#[clap(parse = "from_str") for all the inherent functions? That way, they won't clash with user generated ones. I think a
Parse trait is too much here.
I am not seriously thrilled about the idea of separate traits. I made comments on the issue you linked.
Regarding passes, Absolutely. We can actually do it once we merge clap_derive into clap. I will help with that. Let's talk about this when we chat on call.
Also, look at this issue, https://github.com/clap-rs/clap/issues/1634
Just caught up with this conversation. Just waiting on a few things and will get clap 3.0 beta out after that. So try and if possible get your changes in before that :slight_smile: Thnaks
Sure, just a little question - when is exactly "before that"? :slight_smile:
The problem with
#[structopt(parse)] is that there's already such magical method with different semantics. Could you please elaborate on why
Parse trait is not good? AFAIK, it's just an extra
use clap::Parse; from user perspective?
@CreepySkeleton i could give a timeframe, but then I already gave a timeframe 3-4 times and it is hard to meet timeframes in OSS world :P So preferably, let's strive for a beta by the end of this month :slight_smile: thanks
@DPC Sounds good