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
add support for required options #560
Comments
UX example using dotnet-counters from https://github.com/dotnet/diagnostics:
code:
|
Until the api is decided this is what works for me.
|
Doesn't |
My understanding is Arity only helps if the option is used. |
|
I will check it out. No need to re-invent the wheel if that works. |
The argument arity describes the number of arguments that are valid for an option or command if that option or command is specified. If the option or command isn't specified, then its argument arity is immaterial. There are some additional details here: https://github.com/dotnet/command-line-api/wiki/How-To#argument-validation-and-binding |
@jonsequitur thanks for clarifying argument arity. |
Right now, you can have required positional arguments (no parent Option), but not not required named arguments (Argument has a parent Option). I think the combination of |
I tried implementing this, but it breaks some tests. Example: [Fact]
public async Task Nullable_parameters_are_bound_to_null_when_option_is_not_specified()
{
var wasCalled = false;
int? boundAge = default;
var command = new Command("command")
{
new Option("--age")
{
Argument = new Argument<int?>()
}
};
command.Handler = CommandHandler.Create<int?>(age =>
{
wasCalled = true;
boundAge = age;
});
await command.InvokeAsync("command", _console);
wasCalled.Should().BeTrue();
boundAge.Should().BeNull();
} Doing |
This is super important. The workarounds may work, but the help text is not changed. We need a full solution, this is a basic feature. |
@giggio look at my solution |
@darinclarkdev your solution is the one we are using right now, and it is a good workaround, but the docs from |
@giggio I have updated the RequiredOption constructor in my example. It now prepends [REQUIRED] to the description. |
I would still like to know whether or not it's logical for the unit-test above to pass. I have a branch locally that mostly adds support for required options, but it obviously breaks the unit-test above, because it directly contradicts the requirement. |
@johncrim Agreed. It might be that adding an extension method like @giggio The help output should currently reflect the arity requirements. If it doesn't it's clearly a bug. |
Ah. I'm so used to nullable reference types by now that I've learned to overlook nullable value types to xD. You're right, I'll have to look into why it's failing. |
@jonsequitur I went back to look at this, and there seems to be something weird going on. This is the As you can clearly see, |
I tried to clarify this in this comment. |
@johncrim It turns out that there's an ambiguity here that I missed earlier, so I'd like to clarify my response. To my understanding, the following statement is absolutely aligned with the design:
But here's the potential ambiguity. What you're calling positional arguments are represented in the API as The reason we don't have a concept in the API right now for an option's arity is that we wanted the following to all be equivalent: > myapp -x 1 -x 2 -x 3
> myapp -x 1 2 -x 3
> myapp -x 1 2 3
This is not quite the case. If for an option myapp -x The most common use case for arity 0 is, by far, binding to If option
Option > myapp The above would also be valid if the argument to option My goal here is to clarify the current design, not to argue that it's ideal. This part of it can clearly be made more intuitive. |
@jonsequitur Back to the drawing board then. Would you thing having |
I'm not sure. I do think that a |
This removes the need for my workaround. I would have preferred the help to use the option name instead of the first alias but I will get over it. |
The option name doesn't include the prefix, so it's a little less helpful in practice. |
Technically speaking, aliases don't have to include the prefix either. Both of these are valid and (semi-)functional, but they return different help texts.
Only the first one will actually work as expected, however. The 2nd alias doesn't work in the 2nd example above. This is because the code doesn't use the Prefixes variable consistently. (And the Prefixes variable doesn't support the concept of long and short names.) |
@brandonschmidt What specifically doesn't work? |
Add support for making an option, or one option out of a group of options, required. While this can currently be done using a custom validator, it's awkward and not obvious.
Related: #381.
The text was updated successfully, but these errors were encountered: