Stablize App::replace Tracking Issue

[epage]

Original request: #1603

Original PR: #1697

Feature flag: unstable-replace

Known issues:

• Help subcommand behaves different than help flags when App::replace is used #2011
• No presence in --help

[pksunkara]

We should link implementation also, right?

[epage]

Works for me.

[pksunkara]

So -l expands to --source list and -r expands to --target residues?

The unstable replace feature gets you part way. It would allow a -l to expand out but it wouldn't allow -lr.

Another issue with this feature as the use case is documented here

[epage]

Due to the lack of interest on this tracking issue, I'm considering removing this unstable feature.

Any concerns people want to raise?

[pksunkara]

Would you happen to have ideas on how to solve the mentioned issues? Maybe by restricting replace behavior to only work on subcommands? There aren't any other new issues.

[epage]

But the problem in #2011 is with subcommands and I thought they were the primary motivation for this.

There is also the item brought up about being invisible in --help.

I also feel like there has been little interest expressed in this that it makes me wonder if the feature is worth it in the first place.

[pksunkara]

Yeah, that's what I meant. The current API replaces any and all input. Maybe we can restrict it to only replace subcommands by doing asserts. That, way we can use the replace config to solve the above-mentioned issues.

I also feel like there has been little interest expressed in this that it makes me wonder if the feature is worth it in the first place.

People might not be talking about it because they don't have anything to complain.

That's something we might have different opinions about. I would recommend keeping it.

[epage]

Except for the fact that its unstable which carries its own level of risk, including it being removed.

Features carry a cost and we need to balance that cost against the impact they have on end-users. Right now, command aliases can be emulated by duplicating the commands. This is also done in our "default subcommand" example (see the git examples). People requested that workflow to be streamlined but with us having a workaround, the cost seemed hardly justified. I feel like this might be another one of those scenarios.