-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Implement a partial parse method for Command #4395
Comments
At first I thought you were discussing a REPL which clap already supports but instead you are wanting to prompt the user for each part of the struct as it gets built up. We do have #1634 for prompts for fields, which would act as another input like an arg, an env variable, a default, etc. But your use case goes further and has people entering sub-prompts for subcommands. I don't think this is as simple as the issue describes it to be to implement as this is effectively pausing the parser and having it resumed later. This also feels too specialized that the work and code to support this wouldn't give enough pay off. This would also not work with the derive which the introductory code makes it sound like it would be expected. On reddit, I had brought up the idea of CommandActions like ArgActions but seeing more detail, I'm unsure if that would apply; it'd very much depend on how we design the actions. |
@epage thanks so much for taking the time to look at this. I dug a little deeper into clap this morning and I agree it looks like it might be more complicated than I suggested above. I'll look into those link you sent and see if perhaps that will work as a workaround for me. The CommandActions that I was looking for on reddit would have been a hacky workaround to get the functionality that I want, but the feature request above is really what I'm looking to achieve. I'm curious If you have any other ideas for how I can achieve this? |
Why would this not work with derive? There might be something I'm not understanding here. |
@epage If I were to do this work myself, do you imagine that this could potentially be included in clap via a PR? or do you think it's too niche to warrant inclusion within clap? If you think it could eventually be included, could you perhaps give me some guidance on how you would implement it? I don't have any experience with clap so getting a little insight would be great. |
The derive needs everything parsed to be able to fill in the fields.
Native, built-in support for this exact work flow is unlikely to get in unless we see a wider need. If we can find a solution that provides the building blocks for your need that can be useful more broadly, then that can work. For example, if we could expose a single parse pass and callers build on top of that, then that might work. |
That sounds good @epage. I created a super basic repo called clap-interactive with support for clap. I'm not sure that's the best way to get the functionality that I want but it works pretty well for what I need. I am still looking for a better way to begin the interactive mode when the clap parser errors out. |
Please complete the following tasks
Clap Version
4.0.8
Describe your use case
I want to build an interactive parser. Imagine you have a program with dozens of nested subcommands and args. In this case it is not practical for the user to enter everything in one line. I think an interactive parser itself might be outside of scope for clap, but a method that allows partial parsing would make this much easier and more elegant for perhaps another crate to use.
Example:
My program would eventually look like this:
Describe the solution you'd like
I think there are a couple things that need to be built to allow this. To reiterate I don't think clap should be doing the readline implementation, just the partial parsing.
I imagine the function signature would looks something like this
and PartialArgMatches would contain all the same information, except potentially omit any info from the next subcommand:
try_get_partial_matches_from would succeed if it receives all required args and required subcommands for the specific command it was called on. It would attempt to traverse down the subcommand tree, but if it fails it would simply return as much successful parsing as possible, and the error would be contained in a PartialSubCommand
I don't think this will be too much work hopefully, as the new method should be very similar to what is already created. The only difference really is when to error. Ideally try_get_partial_matches_from will only error if it cannot successfully parse the very first subcommand.
The text was updated successfully, but these errors were encountered: