dotnet / command-line-api

Command line parsing, invocation, and rendering of terminal output.
https://github.com/dotnet/command-line-api/wiki
MIT License
3.39k stars 381 forks source link

Dynamic options - again. #2246

Closed aurora closed 1 year ago

aurora commented 1 year ago

I am really sorry for bringing this up again, as there seem to be lots of questions regarding dynamic options - I've read through the documentation and the issue tracker, but I am having a hard time figuring out how this can be done: I have a main application with a fixed set of commands. I have a plugin-architecture, with an unknown number of plugins. My Problem is the following:

app --plugin=name1 command --arg1=val1 --arg2=val2

app --plugin=name2 command --arg3=val3 --arg4=val4 --arg5=val5

So: in this example I have two different plugins, identified by "name1" and "name2" and I have one(!) command. I want to configure the "--plugin" option as global option and the "command" in my main application, "--arg1", "--arg2", "--arg3", "--arg4" and "--arg5" are arbitrary options for the particular plugin, that I do not know beforehand, as they can be different for each plugin. So my main problem is figuring out a way, how I can configure different options for the same command, depending on the value of "--plugin". Can this be done somehow?

elgonzo commented 1 year ago

Hmm... why did you specifically choose a global option for selecting a plug-in instead of making the plugin names commands themselves? Nested sub commands are possible, so you could either make the plug-ins sub commands of your "ordinary" commands, or vice versa.

This would come with several advantages. First, with separate (sub) commands for each plug-in, you then simply don't have that problem anymore of needing to lump all the options for the different plug-ins into the same command anymore. It should also make it much easier to create a meaningfully structured help text. And last but not least, it would make it easier for System.CommandLine to respond with good error messages in case invalid CLI options/arguments have been provided for a specified plug-in.

aurora commented 1 year ago

You're right - your suggested design is so much better compared to what I had in mind; no need for complicated rules and dynamic options in this case, and it allows for much cleaner code. Thanks so much for your help! :-)