Command Parameters hook for resolving missing required parameters

[ronnyek]

First of all, let me state that I'm unaware of whether this is already achievable... it may not be a feature that needs building.

Is your feature request related to a problem? Please describe.
Well what I'd like to do is have a command have parameters as usual, and still specify required parameters etc... but in the event the user didn't provide them, prompt for them, or even just offer to allow them to use the most recent parameters for that command (I can implement the persistence of that...)

I guess the question is is there a way to intercept a command call with missing parameters so we can potentially fulfil them via other means before executing?

I'd prefer not to just make everything optional, but I suppose if that's what I have to do, that's what I have to do.

With my limited experience with the library I was hoping for something like this...

No changes to command and parameters
If spectre.console decides parameters are missing and that it should display help prompt, allow a hook that would let me gather supply those parameters before attempting to run somehow.

If there is already a way to achieve this, awesome... if not... I feel like this could be extremely handy in at least my use cases.

Thanks for the consideration / feedback.

[nils-a]

@ronnyek could you explain a bit what your use case is and what you are missing from the existing functionality?

[ronnyek]

Imagine I have a logs command, that has explicit settings like so:

public class LogsCommandSettings: CommandSettings
{
    [CommandArgument(0, "[container]")]
    public required string Container { get; set; }
    
    [CommandOption("-f|--follow")]
    public bool? Follow { get; set; }
}

What I was hoping to do was keep the definition of LogsCommandSettings exactly as it appears (such that by the time the command executes, all the required properties are present.

Where my desires potentially miss the functionality present (that I've seen) is that if you specify the command but omit say the Container argument, I'd like to be able to hook into things right there... like if logs is there but the required argument was not specified, I'd like to be able to provide a Func<CommandArgument, string> to populate it before executing the command.

My hope is that by having that hook, I could do something like prompt someone to use previous runs parameters or maybe in some cases go get a list of containers.

I realize I could probably do this by not making this required (and in the case of primitives, make then nullable), but then it seems like I'd have to provide a lot more checking and validation to guarantee by the time we are actually trying to run the command, we have everything actually required to execute.

[nils-a]

The only way I see how to get this working is - as you said - making all arguments optional and add many checks.

[ronnyek]

Do you think the idea of having a way to provide something to resolve missing parameters before trying to execute the command would be something reasonable for inclusion, or outside the scope of this project? I'd be willing to try to create a PR for this if there is ANY interest in it whatsoever.

[nils-a]

We always welcome a nice PR! (Though we're not always fast to process them 😁)

As a starting point, maybe this could be integrated as part of the ICommandInterceptor.

[ronnyek]

So initial glance, I was unaware of Validate() override at both the command and settings level and interceptors.

Honestly this actually provides most of the functionality I'd need... I just wish interceptor could be executed before settings were validated or at least have the validation not exit until after the interceptor runs.

theoretically like this:

command and settings bound -> <optional interceptor that could call validate and mutate settings> -> officially validate settings and fail if settings are still invalid

This would allow me to say what settings if any were provided, if they are currently not valid, potentially prompt and update those settings, and continue on.

I need to look at spectre.console's code a bit more to see how disruptive a change like that would be, but does that seem like a reasonable idea?

[nils-a]

I got to admit, I'm not the Interceptor-PowerUser... 😁

command and settings bound -> [...]

Do you mean like "partially bound"? Like "regardless of required parameters that are still missing".
I am uncertain if that would work. Given an option [CommandOption("-c|--count")] public int Count { get; set; } - the int is not nullable, so what should its value be if it can't be bound?

I think, however, it might be possible to extend the interceptors to PreParseSettings (or something like that) which contains the options and arguments as raw array. This would be after the command has been identified and before the arguments and options are parsed.

@patriksvensson you are using interceptors in multiple places, right? What do you think?

[ronnyek]

So I've had a bit of time to evaluate / tinker with some ideas, and I think the biggest problem is that validation of a commands settings, at least in practice thus far (examples and such) tend to resort to throwing exceptions, vs returning some sort of validation result.

I tested creating a new method on the ICommandInterceptor but seems like the settings and things aren't passed to the place where spectre.console attempts to validate a commands settings. I feel like from what little I know, what would be ideal would be to either have validation called, and have a list of validation results, then call the new method InterceptPreBind. (this would of course depend on command settings validate method to return a set of validation results and not depend on overrides just throwing exeptions)

Another option that seems like it could be may useful seems like the idea of a resolver. I know there is a resolver type, that I believe is responsible for parsing command arguments and binding, if there was a way to say we didnt get this argument at the time of binding, and could then use a registered fallback resolver (perhaps I could do the equivalent of what I'm trying to do with interceptors).

I think in both cases, it would depend on validate at the commandsettings validate method to work more like command validate method works.

Curious if anyone has some input on that experimentation.