start working on a cli app #7
2 changed files with 30 additions and 11 deletions
|
@ -3,7 +3,6 @@ use clap::Parser;
|
|||
use self::{
|
||||
cli::Args,
|
||||
config_file::{find_config_file, Configs},
|
||||
error::ConfigError,
|
||||
};
|
||||
|
||||
mod cli;
|
||||
|
@ -15,20 +14,40 @@ pub struct Config {
|
|||
}
|
||||
|
||||
impl Config {
|
||||
pub fn read() -> Result<Self, ConfigError> {
|
||||
pub fn read() -> Self {
|
||||
let args = Args::parse();
|
||||
let config_path = if let Some(config_path) = args.config_path {
|
||||
config_path
|
||||
Ok(config_path)
|
||||
} else {
|
||||
find_config_file()?
|
||||
find_config_file()
|
||||
};
|
||||
let file_config = Configs::read(config_path)?;
|
||||
|
||||
Ok(Self {
|
||||
let file_config = if let Ok(config_path) = config_path {
|
||||
let file_config = Configs::read(config_path);
|
||||
|
||||
match file_config {
|
||||
Ok(c) => Some(c),
|
||||
Err(e) => {
|
||||
eprintln!("Config error: {e:?}");
|
||||
eprintln!("Proceeding with defaults or cli args...");
|
||||
None
|
||||
}
|
||||
}
|
||||
} else {
|
||||
None
|
||||
};
|
||||
|
||||
if let Some(file_config) = file_config {
|
||||
Self {
|
||||
// this is negated because to an outward api, the negative is more intuitive,
|
||||
// while in the source the other way around is more intuitive
|
||||
startup_msg: !(args.no_startup_message || file_config.no_startup_message),
|
||||
multisamplednight marked this conversation as resolved
Outdated
|
||||
})
|
||||
}
|
||||
} else {
|
||||
Self {
|
||||
startup_msg: !args.no_startup_message,
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ mod welcome_msg;
|
|||
|
||||
fn main() {
|
||||
// TODO: proper error handling
|
||||
let cfg = Config::read().unwrap();
|
||||
let cfg = Config::read();
|
||||
|
||||
if cfg.startup_msg {
|
||||
multisamplednight marked this conversation as resolved
Outdated
multisamplednight
commented
Might want to streamline those two, in order to avoid accidentally checking only one of them in future. The Might want to streamline those two, in order to avoid accidentally checking only one of them in future.
The `figment` crate might be worth looking at in that case.
schrottkatze
commented
i'd prefer to try at least to some degree reduce dependencies, but i'll work on something like that then i'd prefer to try at least to some degree reduce dependencies, but i'll work on something like that then
multisamplednight
commented
You don't need to use You don't _need_ to use `figment`. Custom merge logic works fine, too.
|
||||
print_startup_msg();
|
||||
|
|
Loading…
Reference in a new issue
For later, not now: Should use proper error handling.
put that on the non-existing todo list for when we have a proper error handling and reporting system