-
Notifications
You must be signed in to change notification settings - Fork 0
Add simple prompts #132
Comments
Comment by danieleades actually i think this is proposing a much more significant change than #1471.
then parsing your prompt function into this method |
Comment by mayabyte Ah, that's true I suppose. Their suggestion of adding a Something like |
Comment by danieleades if you're prompting for user input it must be lazily evaluated, right? |
Comment by mayabyte Yeah, but |
Comment by pksunkara Copying my response from #1471 I have worked on https://github.com/termapps/enquirer this week. Either a hook fn or a matches fn, this library can easily provide them. IMO, the prompts shouldn't be in the core. Hooks? yes but not prompts. Implementation plan
It should cover all the use cases @mayabyte wanted since the type of prompts are irrelevant when we abstract them out as hooks. |
Comment by CreepySkeleton Also, should we decide to go on the way of hooks, they would be impossible to serialize/deserialize since... well, how do you serialize a function 😄 ? |
Comment by danieleades
Yeah it's not the easiest... This exists- https://docs.rs/serde_closure/0.2.9/serde_closure/ |
Comment by CreepySkeleton
...which generally serializes/deserializes the code as plain text. It brings in all the problems of I'm really, totally, absolutely not OK with this approach.
This sounds good. |
Comment by Dylan-DPC I think this is beyond the scope of clap. You could use |
Comment by pksunkara Definitely, I am just keeping this issue open as a placeholder for hooks feature. |
Comment by CreepySkeleton
I wouldn't be so categorical. Maybe not hooks, but some sort of prompt support would be pretty useful. |
Comment by pksunkara I would say prompts are beyond the scope of main clap. |
Comment by pksunkara Wanted to note that I am now a maintainer of https://github.com/mitsuhiko/dialoguer which means it will be easy to add compatibility for clap if needed. |
Comment by kbknapp I'd second the prompts being too far out of scope for clap. A hook I think is OK. As for the serialization problem, I'm fine with just saying, "This one feature can't be serialized" to avoid the |
Comment by tech6hutch Is there currently any way to make prompts in Clap, manually if necessary? I just don't want to repeat myself with arg parsing and error messages. |
Comment by danieleades
Negative. But it looks like there's a reasonable concensus as to how to fit the pieces together. Clap can add hooks which allow you to populate fields using a function. Then crates like But then you run into questions like
The design probably needs to consider these extensions. |
Comment by danieleades @tech6hutch if you absolutely must have interactive prompts, you can try an approach I used. (I used structopt).
|
Comment by pksunkara This can be made a plugin when #3008 is done. |
Issue by mayabyte
Friday Jan 10, 2020 at 20:18 GMT
Originally opened as clap-rs/clap#1634
Why?
Let's say you want to write a CLI program that requires the user to log in with a username and password, e.g. a CLI API for some web service. This is perfectly doable with arguments, but it may be preferred to prompt the user to supply these when they start the program, as follows:
Or, let's say you have an option that can be dangerous to enable in certain circumstances, and you want to ask the user if they're sure (like
rm -rf
does):It's not hard to write this logic on your own, but given that these are rather common use-cases, it would be convenient to include this functionality within Clap.
What?
I propose adding a few simple prompting functions for handling common prompting situations. Here's a rough list:
prompt_if_absent(prompt: &str)
: Asks the user to supply a value for this argument if they didn't at run time. Displaysprompt
on the line where they type; in the first example above, theprompt
s would have been"> username: "
and"> password: "
respectively.suggest_if_absent(prompt: &str, default: Fn() -> Option<String>)
: Likeprompt_if_absent
, but takes a function that can try to find a sensible default to suggest to the user, which can then be chosen by pressing enter without typing. Useful when you're not sure the default makes sense (e.g. if it's found from an envar or something), so you want to run it by the user to make sure.ensure_if(prompt: &str, arg_id: Key, val: &str, default: Yes/No/None)
and similarensure_ifs
: Asks the user if they're sure when they've setval
(s) with a[y/n]
prompt. The user can select the default option by just pressing enter.prompt_secret(prompt: &str)
: likeprompt_if_absent
but doesn't show what you're typingThese can all be gated behind a
prompts
feature or something to keep the core functionality simple.I realise there's been a little pushback on stuff like this in the past (~a few years ago?), but I do genuinely think it would be a nice addition. A lot of great CLI building tools in other languages include prompting functionality, so adding a few convenience methods for it reduces the friction required to port existing things over to Rust.
I'm happy to implement this myself if there's interest.
(Note: I'm aware of clap-rs/clap#1471, but the changes they suggest are much more significant and have potentially quite wide implications, so I consider it a separate matter. I'd love to see that get added though :P)
The text was updated successfully, but these errors were encountered: