Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Argument options depending on other argument? #272

Closed
janpio opened this issue Jul 24, 2019 · 1 comment
Closed

Argument options depending on other argument? #272

janpio opened this issue Jul 24, 2019 · 1 comment

Comments

@janpio
Copy link

janpio commented Jul 24, 2019

I am currently building a CLI using oclif and have another special use case I am not sure how to implement:

(In my understanding this issue is about the exact same code as #270, but represents another use case. I am writing it down, just as additional input)

I have 2 arguments. The first defines a "platform", and the second the "action" that should be executed. The list of actions depends on the platform (with our without overlap between the platforms, not sure yet). Right now I have added all the available actions for all platforms to the options of that argument, and use parse or code in run itself to validate that the chosen action is actually valid for that platform.

Could there be a concept of options that depend on the value of another argument? Would that make sense in the docs?


A workaround here would be to actually use 2 different subcommands, one for each platform instead of both using the same command and then branching for the platform in the code. But the command really shares all the logic besides this argument handling stuff, so I am hesitant to do that (and the : for subcommands might also play a role).

@mdonnalley mdonnalley closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2022
@0xdevalias
Copy link

@mdonnalley It would be nice to include some context/description on why the issue is being closed (if it was completed, then when/where it was completed; if it's 'not planned' then more of an explanation of why it's not going to happen). This current process of 'close a huge pile of issues' with no context is generally considered pretty 'hostile'/'disrespectful' (for lack of a better term) to open source/collaboration/etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants