How to require an option but only if it is specified without a value?

[rcdailey]

I have the following option:

[CommandOption("list-terms", Description = "Test")]
public string? ListTerms { get; set; }

There are three variations of the command line:

1. ./mycommand
2. ./mycommand --list-terms
3. ./mycommand --list-terms myvalue

Here is the behavior I want to program for each of the variations above:

1. Command proceeds with behavior unaltered.
2. Command fails and notifies user that --list-terms requires a value to be provided.
3. Command proceeds with behavior altered by the specified option and its value.

Right now, 1 & 2 are ambiguous. In other words, I get the same value in the ListTerms property when the user doesn't specify the option at all, and when they specify it without a value.

I need a way to require that an option be given an explicit value, but not require the option itself. Is this possible right now? I'm OK implementing the enforcement myself, but that still requires me to disambiguate 1 & 2 above by using the value of the property after command line processing is done by CliFx.

[Tyrrrz]

I think you can do it via BindingValidator and by setting the validator on the CommandOption:

[CommandOption("list-terms", Description = "Test", Validators = new[] { typeof(MyValidator)})]

If I remember correctly, the validator is only triggered on the value if the option has been provided, so you would simply handle the null value which would correspond to case 2 in your situation.

[Tyrrrz]

I don't understand exactly what you did there but what I meant was:

    [CommandOption("list-terms", Validators = new[] {typeof(ListTermsOptionSpecifiedValidator)}, Description =
        "For the given Release Profile Trash ID, list terms in it that can be filtered in YAML format. " +
        "Note that not every release profile has terms that may be filtered.")]
    public string? ListTerms { get; [UsedImplicitly] set; }

internal class ListTermsOptionSpecifiedValidator : BindingValidator<string>
{
    public override BindingValidationError? Validate(string? value)
    {
        if (value is null)
        	// Option has been provided, but with null value
           return Error("Bla bla bla");

        return Ok();
    }
}

This will print something like:

Option --list-terms has been provided with an invalid value.
Error(s):
- Bla bla bla

There are no docs on BindingValidators, but you can look at some examples in tests:

CliFx/CliFx.Tests/ConversionSpecs.cs

Lines 906 to 948 in ed3054c

	[Fact]
	public async Task Parameter_or_option_value_conversion_fails_if_one_of_the_validators_fail()
	{
	// Arrange
	var commandType = DynamicCommandBuilder.Compile(
	// language=cs
	@"
	public class ValidatorA : BindingValidator<int>
	{
	public override BindingValidationError Validate(int value) => Ok();
	}
	public class ValidatorB : BindingValidator<int>
	{
	public override BindingValidationError Validate(int value) => Error(""Hello world"");
	}
	[Command]
	public class Command : ICommand
	{
	[CommandOption('f', Validators = new[] {typeof(ValidatorA), typeof(ValidatorB)})]
	public int Foo { get; set; }
	public ValueTask ExecuteAsync(IConsole console) => default;
	}
	");
	var application = new CliApplicationBuilder()
	.AddCommand(commandType)
	.UseConsole(FakeConsole)
	.Build();
	// Act
	var exitCode = await application.RunAsync(
	new[] {"-f", "12"},
	new Dictionary<string, string>()
	);
	var stdErr = FakeConsole.ReadErrorString();
	// Assert
	exitCode.Should().NotBe(0);
	stdErr.Should().Contain("Hello world");
	}

[rcdailey]

I prefer to keep business rules in my command class not in a validator. Either way, I feel like validators are being abused here which is why I suggested this be a new feature.

[Tyrrrz]

Okay then you can just do this:

    [CommandOption("list-terms", Description =
        "For the given Release Profile Trash ID, list terms in it that can be filtered in YAML format. " +
        "Note that not every release profile has terms that may be filtered.")]
    public string? ListTerms { get; [UsedImplicitly] set; } = "";

Then you will have three states:

1. ./mycommand → ListTerms is empty
2. ./mycommand --list-terms → ListTerms is null
3. ./mycommand --list-terms myvalue → ListTerms is myvalue

There's also another edge case:

4. ./mycommand --list-terms "" → ListTerms is empty

if you want to differentiate between 4 and 1, then you can set ListTerms default value to some magic string then you're sure isn't going to be used as a value. Case 4 will always result in an empty value.

[rcdailey]

Ok this is a little better, thank you.

If you're not objected to it, I'd be happy to contribute a PR to make an attribute property for this. What do you think? If I were to spend time on this, how would you like it to be done? I certainly wouldn't want to start working on a feature you won't accept or that isn't otherwise acceptable because it doesn't function as you like or consistent with the design principles of the library.

Let me know if and how you'd like to discuss it.

[Tyrrrz]

I'd say let's hold it off until it becomes something more people request. As of now, both workarounds above are easier than designing and implementing a new feature.