Feature Request: Add easy way to specify aliases to DragonFruit params

[bradleypatton]

I'm evaluating System.CommandLine and this seems like basic functionality. For simple console programs I want to be able declaratively add an additional alias with a short form of the parameter name. Setting up a RootCommand and configuring options seems like overkill for this usecase.

Seems like there have been some other PR to solve this but none have been approved ? (see #345 #525), Would love to see this functionality added.

[kasajian]

I realize this isn't going to get done since it's not a priority. Got no issues with that. But has anyone yet forked this repo and added the PRs mentioned above so that those of us who want to use DragonFruit for our own projects can continue to do so? asking for a friend.

[jonsequitur]

The reason we haven't added alias support to DragonFruit isn't because of priorities so much as the implications of such a design decision.

XML comments exist in C# for documentation, so using it for command line help isn't very surprising. If we were to add aliases, we're going down the path of making the XML drive program behavior, which would be surprising. And from there, why not tab suggestions, or whether or not an option is required, or the argument arity? We'd be headed in the direction of writing an XML-based DSL for an API that's already fully-featured in C#, but with no support for things like IntelliSense, compiler diagnostics, etc.

But the DragonFruit experiment is informing a more complete approach here: https://github.com/KathleenDollard/command-line-api-starfruit. One of its goals is that the "DragonFruit-style" command line app will still work, but with a set of conventions for adding these richer figures over time.

If you're motivated to keep using DragonFruit but need that extra functionality, we'd welcome the help.

[bradleypatton]

Thanks for responding and explaining the rationale.

In searching for command line parsers I found Cocona. Which interestingly supports this with Option Arguments. The StarFruit approach looks like the CommandLineParser model where you create a separate 'options' class and decorate the properties with attributes.

Seems like Option Attributes would be more line with your approach and not require extra XML parsing.

[jonsequitur]

We're working on an attribute-based approach on top of System.CommandLine here: https://github.com/KathleenDollard/command-line-api-starfruit

Please take a look.

[jacobjoensen-zz]

Method parameters can have attributes. Isn't that the obvious choice?

static void Main([Alias("-v")] bool verbose)

[CrossBound]

This is just my two cents but I much prefer the DragonFruit model over the examples I'm seeing on the StarFruit page... I like the simplicity of simply declaring your parameters in the Main method parameter list.

I also am not in favor of the XML option, I agree that is the wrong road to be traveling. I also completely agree with the comments in #525 in regards to the messiness of the parameter attributes.

Why not compromise and use method Attributes... like this.

[Alias("a", "MyParameter")]
[Alias("b", "MyParameter")]
public static void Main(string MyParameter)
{
    Console.Writeline("MyParameter = " + MyParemter);
}

This has a double benefit in my opinion which is:

• Cleaner than parameter attributes
• Easy to add multiple aliases per parameter if needed

[CrossBound]

BTW... the repo for starfruit linked above hasn't seen any activity in over 4 months... is it basically dead?

[jonsequitur]

It's not dead. We're working through some interesting source generation scenarios, and planning for getting System.CommandLine ready for a non-beta release.

[CrossBound]

Excellent, thanks. Exciting to hear about the non-beta release.

[Simplifier]

So what prevents you from implementing aliases using parameter attributes as @jacobjoensen-zz suggested? I don't really understand