Skip to content
This repository has been archived by the owner on Jan 1, 2022. It is now read-only.

Add simple prompts #132

Open
epage opened this issue Dec 6, 2021 · 18 comments
Open

Add simple prompts #132

epage opened this issue Dec 6, 2021 · 18 comments
Labels
C: args C: parsing D: medium P2: need to have T: new feature
Milestone
3.1

Comments

@epage
Copy link
Owner

epage commented Dec 6, 2021

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:

$ 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 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)
@epage epage added this to the 3.1 milestone Dec 6, 2021
@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by danieleades
Saturday Jan 11, 2020 at 13:22 GMT

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

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by mayabyte
Saturday Jan 11, 2020 at 13:38 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by danieleades
Saturday Jan 11, 2020 at 13:41 GMT

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

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by mayabyte
Saturday Jan 11, 2020 at 14:06 GMT

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

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Saturday Jan 18, 2020 at 10:20 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by CreepySkeleton
Saturday Jan 18, 2020 at 12:11 GMT

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

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by danieleades
Saturday Jan 18, 2020 at 14:25 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by CreepySkeleton
Saturday Jan 18, 2020 at 14:43 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by Dylan-DPC
Sunday Feb 02, 2020 at 01:12 GMT

I think this is beyond the scope of clap. You could use enquirer or I'd tackled a similar problem in clim which I never completed 😄

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Sunday Feb 02, 2020 at 05:59 GMT

Definitely, I am just keeping this issue open as a placeholder for hooks feature.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by CreepySkeleton
Sunday Feb 02, 2020 at 06:08 GMT

I think this is beyond the scope of clap.

I wouldn't be so categorical. Maybe not hooks, but some sort of prompt support would be pretty useful.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Sunday Feb 02, 2020 at 06:20 GMT

I would say prompts are beyond the scope of main clap.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Wednesday Apr 29, 2020 at 08:44 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by kbknapp
Wednesday Apr 29, 2020 at 16:29 GMT

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 eval type issues, just like validators.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by tech6hutch
Tuesday May 19, 2020 at 21:54 GMT

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.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by danieleades
Wednesday May 20, 2020 at 06:03 GMT

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.

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 dialoguer can handle the prompt. This might involve some interior mutability to lazily populate the value.

But then you run into questions like

  • if interactive prompts, why not config files too?
  • what is the precedence of config values (and how can I customise it)?

The design probably needs to consider these extensions.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by danieleades
Wednesday May 20, 2020 at 06:10 GMT

@tech6hutch if you absolutely must have interactive prompts, you can try an approach I used. (I used structopt).

  • define an Args struct
  • define a PartialArgs struct (derive StructOpt) which is the same as the Args struct, but with Optional fields
  • implement From<PartialArgs> for Args with a bunch of unwrap_or_else(|| //prompt user) calls

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Wednesday Nov 17, 2021 at 21:39 GMT

This can be made a plugin when #3008 is done.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
C: args C: parsing D: medium P2: need to have T: new feature
Projects
None yet
Milestone
3.1
Development

No branches or pull requests
1 participant
@epage