Add simple prompts

[mayabyte]

Maintainer's notes

• Blocked on [modular] User-driven values (defaults, env vars, implied values, etc) #4793 and the general move to Potential Design Direction #2832

---

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:

$ example_program
> username: beepboop
> password: 
Successfully logged in!

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):

$ example_program --danger
> Are you sure you want to do the dangerous thing? [y/N] 

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. Displays prompt on the line where they type; in the first example above, the prompts would have been "> username: " and "> password: " respectively.
• suggest_if_absent(prompt: &str, default: Fn() -> Option<String>): Like prompt_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 similar ensure_ifs: Asks the user if they're sure when they've set val(s) with a [y/n] prompt. The user can select the default option by just pressing enter.
• prompt_secret(prompt: &str): like prompt_if_absent but doesn't show what you're typing

These 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 #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)

[danieleades]

actually i think this is proposing a much more significant change than #1471.
you could resolve #1471 simply by adding a hook that takes a closure-

Arg::default_with<F, S>(mut self, fun: F) -> Self
    where
    F: FnOnce -> S,
    S: AsRef<str>,

then parsing your prompt function into this method

[mayabyte]

Ah, that's true I suppose. Their suggestion of adding a get_matches_from_fns is definitely larger though.

Something like default_with would be pretty nice to have as well. You can kinda already fudge something like that with default_value and a closure full of prompting (or whatever else) code, but default_with could be lazily-evaluated which makes it nicer imo.

[danieleades]

if you're prompting for user input it must be lazily evaluated, right?

[mayabyte]

Yeah, but default_with could be used for other things besides prompting. I was porting a tool the other day that set the default of a field with the output of another program, so in that case default_with would be noticeably better than default_value due to laziness

[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

• If a required option is missing, and a default_with exists, then prompt happens.
• If a flag is marked confirm_with, then when the flag is used, the prompt can confirm

It should cover all the use cases @mayabyte wanted since the type of prompts are irrelevant when we abstract them out as hooks.

[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 😄 ?

[danieleades]

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 ?

Yeah it's not the easiest...

This exists- https://docs.rs/serde_closure/0.2.9/serde_closure/
But I suppose in general you could only use these hooks with programmatic argument building.

[CreepySkeleton]

This exists- https://docs.rs/serde_closure/0.2.9/serde_closure/

...which generally serializes/deserializes the code as plain text. It brings in all the problems of eval in some languages, let alone the fact it allows a malicious user/attacker inject arbitrary code and execute it!

I'm really, totally, absolutely not OK with this approach.

But I suppose in general you could only use these hooks with programmatic argument building.

This sounds good.