No way to create a global template

[anna-is-cute]

Affected Version of clap

2.29.4

Expected Behavior Summary

Being able to call global_template and have the template propagate down to subcommands.

Actual Behavior Summary

For every single subcommand, I have to add a template call to get them all to match my custom template.

[kbknapp]

Totally agree this is a lacking feature, thanks for the suggestion!

In order for me to actually get v3 released I have to put blinders on and only implement bug fixes or super trivial features which are simple to forward port to the v3 branch.

I don't know that this is one such issue. I'll leave it open for v3 as it is something I do want to have.

Having said all this, if someone implements this for v2 I'm not against the PR, so long as the understanding is that for v3 I may have to rip out the commit and re-do it depending how deep into the internals it gets to implement this. (for v3 the internals are quite different, so some changes aren't trivial to forward port).

[pksunkara]

To solve this, we would either need to add a global_help_template function that would forward the template to children (example) or we could add a setting called PropagateTemplate which does the same.

[epage]

One idea I have for this (and other issues) is if we implemented a layered config. Some fields would be designated as layered, like this, and others would not, like a subcommands display order. For layered fields, we propagate them to subcommands if they are set in the parent but not the sucommand, and then continue this recursively.

So build would have code like:

if let Some(help_template) = self.help_template.as_deref() {
    sub.help_template.get_or_insert(help_template)
}

[pksunkara]

I think you might need to expand on this. I am quite confused reading your comment.

[epage]

Yeah, I can see needing to re-phrase since i'm using a term in an adjacent domain for which we have feature requests ;).

What if we modeled clap's builder API after layered config? What I mean is where you take configuration from different sources and merge them together.

The approach I've taken in several applications that I've been finding works well is that the config data tracks what is explicitly set, using Option. You then build the final config by merging all the sources by reading each layer and reading the explicitly set values, giving precedence to the higher layer. All the config fields are private and we expose getters that contain the default value so the callers don't care about these details. Granted, when a user does a --dump-config, I want to merge in the defaults so they can see them

So what this would look like in clap is an App would have all "global" fields be Option<T>. When we build, we merge the parent Apps global fields into its subcommand with code blocks similar to

if let Some(help_template) = self.help_template.as_deref() {
    subcommand.help_template.get_or_insert(help_template)
}

This will preserve the subcommands original help template. If it was never explicitly set by the user, the parent command's help template would be used.

Depending on performance, we might also apply the default layer so that the accessors don't have to re-compute it on each call.

Arg::display_order is part way there at this point

• https://github.com/clap-rs/clap/blob/master/src/build/arg/mod.rs#L84
• https://github.com/clap-rs/clap/blob/master/src/build/arg/mod.rs#L4869
• https://github.com/clap-rs/clap/blob/master/src/build/app/mod.rs#L2877