How do I make required options?

[koliyo]

I need some "options" to be required. This is different from the provided example in #217

Which does provide an example of an option with a required value, but the option itself is not required.

How do I make a command line "option" required?

By this I mean that if the option is not provided by the user then this is a validation error.

[nils-a]

You could set a default value on the option and then validate that the value is not the default.

But, if the option is not optional, I personally would rather use an argument and denote that as required, by using the angle-bracket-syntax like so:

[CommandArgument(0, "<firstName>")] 
public string FirstName { get; set; }

[koliyo]

For my usecase there is a multiple level nested CLI, and in this context it becomes very confusing with multiple positional arguments as well. Hard to separate command names from the input parameters. Eg compare:

program sub1 sub2 sub3 arg1 arg2 arg3

to

program sub1 sub2 sub3 --foo arg1 --bar arg2 --hej arg3

For rich CLI utilities with many subcommands I think this makes things much clearer. Think about CLI applications similar to awscli

[patriksvensson]

@koliyo Options is by its nature never required (therefore the name). You could add a custom validation step to your command such as:

public sealed class MySettings : CommandSettings
{
    [CommandOption("--foo <VALUE>")]
    public string Foo { get; set; }

    public override ValidationResult Validate()
    {
        if (string.IsNullOrWhiteSpace(Foo))
        {
            return ValidationResult.Error("Foo is required");
        }

        return base.Validate();
    }
}

[patriksvensson]

@rhnatiuk There is a solution. This is by design and requires logic in the validstion step. See my answer above.

[lucasshiva]

@rhnatiuk There is a solution. This is by design and requires logic in the validstion step. See my answer above.

I'm a big fan of required options. Having one of the following would be quite nice:

[CommandOption("-f|--foo", Required = true)]
// or
[CommandOption("-f|--foo")]
[Required(true)]

System.CommandLine also supports them:

var searchTermsOption = new Option<string[]>(
    name: "--search-terms",
    description: "Strings to search for when deleting entries.")
    { IsRequired = true, AllowMultipleArgumentsPerToken = true };

[tobysmith568]

Hey @patriksvensson, are there some documented CLI API design principles you have in mind when you suggest that a CLI tool should not have mandatory options?
I ask because I too am finding myself thinking that they would be the most sensible approach for my CLI tool and am wondering why Spectre does not offer them - but perhaps I should be thinking about my CLI's API design differently?
If there is a resource that could be linked to then it might stop others, like myself, from finding this thread and adding to the support for them.

I find the approach of implementing a validation step somewhat unsatisfactory because it doesn't affect the output when the --help option is given. I've currently added a [grey][[Required]][/] prefix to my DescriptionAttributes which I'm not a fan of because it doesn't feel particularly DRY having to repeat the same formatting and the same validation logic each time.

I would suggest that in a codebase with Nullable enabled, not specifying the type of a CommandOption in a CommandSettings as nullable could be sufficient to deem it as required, with Spectre then validating it as such and indicating so in the --help text. If this approach isn't possible/practical then I suggest the System.ComponentModel.DataAnnotations.RequiredAttribute is also a good approach (and isn't a breaking change). I feel the approach used by CommandArguments of using angle brackets would also work.

Lastly, I'm not sure I understand the rationale of "They're always optional because they're called options". In general (outside of CLI flags) it's common for picking an option to be mandatory, e.g. "You need to pick one of these options".

Thanks for any insight.

[IanKemp]

@patriksvensson literally every other command-line parser I know of supports mandatory options. It is an option because it allows you to control how the program runs, not because it is optional. The fact that this question constantly comes up, and you are constantly answering it with "override Validate", should be a strong clue that the API needs to change. Dogmatism is not the correct answer.

[jnm2]

Named arguments are just as important for readability here as in C# when you have Xyz(false, false, 3);.

[koliyo]

The word "option" is a bit unfortunate for what it provides and how it is used in CLIs. And from that perspective the "by design" argument makes sense.

But as others mention, the requested functionality is really useful in CLIs and is pretty widely adopted., I think the term "flag" is better than "option" here. Not sure if this helps the discussion, but relying too much on the semantic meaning of "option" is not the best argument imo.

[patriksvensson]

We will be adding required options in the next release.

[dfaivre-pcs]

any issue we can track - excited for this!