Document benefit of using Clap 3.x.x over StructOpt

[danieleades]

I've been using Clap for some time now and I'm a big fan.

I've recently switched to using StructOpt because I prefer the declarative style.

I see that clap 3 is re-exporting StructOpt, so I guess it's nice to have all the functionality under one roof.

What I'm not clear on, is where the benefit lies for me to switch from StructOpt (which re-exports Clap functionality) to Clap (which re-exports StructOpt functionality) given that I'm exclusively using the declarative syntax.

What does a user gain by having Clap as the direct dependency? I don't feel this has been documented anywhere.

[CreepySkeleton]

I see that clap 3 is re-exporting StructOpt

Keep in mind that the structopt in question is a year-old version, 0.2.x, while the latest version is 0.3.3. clap_derive is not a replacement for the latest structopt (for now).

I guess it's nice to have all the functionality under one roof

That would be nice indeed, but it looks like the current maintainers do not agree.

What I'm not clear on, is where the benefit lies for me to switch from StructOpt (which re-exports Clap functionality) to Clap (which re-exports StructOpt functionality) given that I'm exclusively using the declarative syntax.

For now effectively none since you'd be moving from structopt 0.3 to 0.2. That's a move backward, not forward.

What does a user gain by having Clap as the direct dependency? I don't feel this has been documented anywhere.

The intention here (AFAIK) is to have them both [structopt and clap] under a single group of maintainers so they could be developed in sync. Some things cannot be done without tight integration.

[danieleades]

Thanks @CreepySkeleton, that's a really good summary of the current state of play. So for now, I'm better off using StructOpt. But then when (if) they reach parity it gets murky again...
Is that about right?

Kind of seems like a lot of overlap and a bit of bloat.

I'd really love to hear from one of the maintainers here. @kbknapp ?

[CreepySkeleton]

Is that about right?

If they do reach parity (and I really hope they would) structopt will likely become deprecated, I recall @TeXitoi (structopt's author) said something about that this has been his intention.

Kind of seems like a lot of overlap and a bit of bloat.

A lot of overlap indeed, but bot structopt and clap_derive are proc-macros, they don't end up in the final binary, no bloat involved.

I'd really love to hear from one of the maintainers here. @kbknapp ?

@kbknapp is unlikely to reply, he's kind of retired.
I believe @Dylan-DPC is maintainer here.

Also @Dylan-DPC what is your opinion on this matter? Is there any particular reason not to update to structopt 0.3? If it's about lack of manpower I would volunteer for the job, I'm pretty familiar with structopt codebase.

[Dylan-DPC-zz]

Give me some time i'll respond to this and the other issue later today. But please do not pass any statements on behalf of the team. Thanks

[Dylan-DPC-zz]

Also @CreepySkeleton if you want to go about updating structopt to 0.3 on clap-derive, you can go ahead and do it, we have no problem with that :)

[CreepySkeleton]

But please do not pass any statements on behalf of the team

I've never meant to, I'm terribly sorry if I left wrong impression

[jamestwebber]

Maybe this is a question more appropriate for the structopt repo, but is it generally true that structopt can not do anything that can't be done in plain clap because it is generating the same code?

[TeXitoi]

You can do almost everything. There is some exceptions as TeXitoi/structopt#130

[kbknapp]

The idea when the 3.0 branch started (seemingly forever ago) was exactly as you stated, to bring all the functionality under one roof and have a more cohesive product for users.

However, with my life events being what they've been over the past year (changed jobs, moved, had a baby) it has fallen behind. My dream goal was to move StructOpt into clap, but still have @TeXitoi as the owner of clap_derive with full creative and administrative control. Just with the idea that we could collaborate and present users less confusion. Of course the argument has been raised as to why can't that happen without clap absorbing StructOpt? It could, but the two different names alone causes confusion about relation between the projects and how to share functionality between them.

I'd still love for that dream to become a reality. But it's also totally understandable that there are valid arguments against this. The next step would be trying to update clap_derive to feature parity with StructOpt 0.3.x.

I guess it's TBD how this will all play out. It is open source after all 😄

What I'm not clear on, is where the benefit lies for me to switch from StructOpt (which re-exports Clap functionality) to Clap (which re-exports StructOpt functionality) given that I'm exclusively using the declarative syntax.

Small nit, clap_derive doesn't re-export StructOpt. It used the StructOpt v0.2.x code as a base and made some changes. (which I think provide some more flexibility and are more in line with clap such as the ability to split out derivable traits in order to be able to just use parts of the derive instead of all or nothing)

[CreepySkeleton]

@kbknapp It's good to have you back!

In fact, I am performing the transition in clap-rs/clap_derive#22 . Right now I'm short on time but I think I'll get clear in 3-4 days. Any specific deadline I should account for?

[Dylan-DPC-zz]

@CreepySkeleton 3-4 days sounds good

[danieleades]

I didn't anticipate the amount of interest this question would stir up!

I really appreciate the in depth responses, and I think I have a clear picture of where things are at. It sounds like there's not a totally coherent story for users now, but by the sounds of things it's not too far off.

I'll continue using StructOpt, and I'll be paying close attention as things develop!

[danieleades]

a year and a bit down the line, where are things at now?

[pksunkara]

We have decided on the plan and the difference between clap v3 and structopt long ago, #1574 (comment)

[danieleades]

In that case, I think this issue can probably be closed

[pksunkara]

I am using this issue as a placeholder to write a small blurb about it in the readme/website