Stablize `App::replace` Tracking Issue

Question

Stablize `App::replace` Tracking Issue

epage opened this issue 3 years ago · comments

Ed Page commented 3 years ago

Original request: #1603

Original PR: #1697

Feature flag: unstable-replace

Known issues:

#2011
No presence in --help

Pavan Kumar Sunkara · Answer 1 · Sat Oct 09 2021 23:43:55 GMT+0800 (China Standard Time)

We should link implementation also, right?

Ed Page · Answer 2 · Sat Oct 09 2021 23:46:50 GMT+0800 (China Standard Time)

Works for me.

Pavan Kumar Sunkara · Answer 3 · Wed Oct 27 2021 04:42:40 GMT+0800 (China Standard Time)

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

Ed Page · Answer 4 · Fri Mar 24 2023 04:49:31 GMT+0800 (China Standard Time)

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

Any concerns people want to raise?

Pavan Kumar Sunkara · Answer 5 · Fri Mar 24 2023 08:54:08 GMT+0800 (China Standard Time)

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.

Ed Page · Answer 6 · Fri Mar 24 2023 08:59:31 GMT+0800 (China Standard Time)

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.

Pavan Kumar Sunkara · Answer 7 · Fri Mar 24 2023 09:05:11 GMT+0800 (China Standard Time)

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.

Ed Page · Answer 8 · Fri Mar 24 2023 09:21:39 GMT+0800 (China Standard Time)

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.