-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Cli] Add default_prompt_response
option to set_global_config
command
#5614
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey this is a great first start!
I think you'll want to do one of these two options:
- Make an enum with,
[yes, no, prompt]
, where prompt is default - Take advantage of
Option<bool>
, to handleNone
as prompt.
It's probably easier from a readability perspective for the first one, and then it can default to prompt.
Then you can loop this into the PromptOptions
to read the global config and use this as the default behavior rather than what it does right now
Agree with Greg, particularly with the first thing he suggests. |
I also agree with the first thing. Please review the updated code, and then I will move forward with |
Will look next week :) |
crates/aptos/src/config/mod.rs
Outdated
@@ -174,6 +184,9 @@ pub struct GlobalConfig { | |||
/// Whether to be using Global or Workspace mode | |||
#[serde(skip_serializing_if = "Option::is_none")] | |||
pub config_type: Option<ConfigType>, | |||
/// Prompt response type | |||
#[serde(skip_serializing_if = "Option::is_none")] | |||
pub default_prompt_response: Option<PromptResponseType>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use serde(default)
here instead of making this an Option
? As it is now the Option
doesn't really make much sense given there is also a Prompt
variant of the PromptReponseType
enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, it would save default_prompt_response: Prompt
in the config file, even if we run set-global-config
without --default-prompt-response
option. It's what we should come up with?
crates/aptos/src/config/mod.rs
Outdated
ASSUME_YES => Ok(Self::Yes), | ||
ASSUME_NO => Ok(Self::No), | ||
_ => Err(CliError::CommandArgumentError( | ||
"Invalid prompt response type, must be one of [yes, no]".to_string(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could also be prompt
right?
Awesome work, this looks like it is good to go to me! My only concern now is if this PR lands, users might think the feature is ready, but it doesn't actually affect anything yet. Could you perhaps stack then next PR on top of this one and then we'll land them all together? |
Sure thing!. I am doing the exact implementation. thanks. |
I thought |
crates/aptos/src/common/utils.rs
Outdated
} | ||
|
||
if !prompt_options.assume_yes { | ||
match GlobalConfig::load()?.get_default_prompt_response() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of points here:
First, GlobalConfig only reads the config at the global folder (e.g. ~/.aptos
), we want to read the correct config based on scope. So if there is an .aptos
dir in the current dir, use that. You want something like this instead:
let config = CliConfig::load(ConfigSearchMode::CurrentDirAndParents)?;
Second, we shouldn't load the config here, it should be passed in, since in some cases we might already have it. That way we avoid unnecessary double reads of the config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First - As default_prompt_response
is saved in global config file, I think using GlobalConfig::load
rather makes sense. CliConfig::load
loads the profiles only. Otherwise, it should be stored in the profiles as needed.
Second - I agree with your principle. GlobalConfig::load
is used to get .aptos
folder path mostly to load profiles, save them, and check the config existence and called more than once to load and then save in a line. Furthermore, it's not designed to pass the global config from the root to the leaf, which means it should be redesigned and/or needed much updates relatively.
@banool, thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First: Okay I may be misunderstanding the code, I'd have to dive deeper. Though for now I'll invoke @gregnazario to comment since he knows the CLI better than anyone 😛
Second: Same thing, what do you think @gregnazario? I see instances where we have a config already, it seems redundant to load it again. Perhaps the config object should be smarter and act as a passthrough cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, been very very busy.
I would put it in the global config like he does here, and I think it's the right choice.
This code maybe should read a slightly different way. This will let you override via CLI flags default behavior even if you sent it, allow you to set a default which overtakes so you don't need to send flags, and allow for default prompting otherwise.
This pseudocode below I think lets it be very simple and straightforward for someone to read afterwards and tell what's going on.
// Handle CLI flags
If assume_no:
return abort
else if assume_yes:
return Ok
// Then handle default or prompt behavior
bool is_yes = if let Some(response) = default_response:
response
else:
prompt and get response
if is_yes:
return Ok
else:
return abort
I see now you have Prompt
as an option, then replace the end there with a match statement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the reply. I just did some changes. could you please review again?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Head branch was pushed to by a user without write access
Head branch was pushed to by a user without write access
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
…mand (aptos-labs#5614) * [cli] add default_prompt_response option to set_global_config * update options * update global config struct * add prompt response getter * apply default prompt option config * update prompt func * update prompt func * fix lint issue * fix lint error
[WIP]
Description
Updates for issue #2205
Test Plan
This PR is in WIP, so far saving the configuration in the config file works well.
This change is