Skip to content
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

feat(console): Support config file #320

Merged
merged 20 commits into from
Apr 12, 2022
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 65 additions & 2 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

3 changes: 3 additions & 0 deletions tokio-console/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -44,3 +44,6 @@ h2 = "0.3"
regex = "1.5"
once_cell = "1.8"
humantime = "2.1.0"
serde = { version = "1", features = ["derive"] }
toml = "0.5"
dirs = "4"
179 changes: 168 additions & 11 deletions tokio-console/src/config.rs
Original file line number Diff line number Diff line change
@@ -1,5 +1,10 @@
use crate::view::Palette;
use clap::{ArgGroup, Parser as Clap, ValueHint};
use color_eyre::eyre::WrapErr;
use serde::Deserialize;
use std::fs;
use std::ops::Not;
use std::path::PathBuf;
use std::process::Command;
use std::str::FromStr;
use std::time::Duration;
Expand Down Expand Up @@ -71,15 +76,15 @@ struct RetainFor(Option<Duration>);
pub struct ViewOptions {
/// Disable ANSI colors entirely.
#[clap(name = "no-colors", long = "no-colors")]
no_colors: bool,
no_colors: Option<bool>,

/// Overrides the terminal's default language.
#[clap(long = "lang", env = "LANG", default_value = "en_us.UTF-8")]
lang: String,
#[clap(long = "lang", env = "LANG")]
lang: Option<String>,

/// Explicitly use only ASCII characters.
#[clap(long = "ascii-only")]
ascii_only: bool,
ascii_only: Option<bool>,

/// Overrides the value of the `COLORTERM` environment variable.
///
Expand Down Expand Up @@ -107,20 +112,66 @@ pub struct ViewOptions {
}

/// Toggles on and off color coding for individual UI elements.
#[derive(Clap, Debug, Copy, Clone)]
#[derive(Clap, Debug, Copy, Clone, Deserialize)]
pub struct ColorToggles {
/// Disable color-coding for duration units.
#[clap(long = "no-duration-colors", parse(from_flag = std::ops::Not::not), group = "colors")]
pub(crate) color_durations: bool,
#[clap(long = "no-duration-colors", group = "colors")]
#[serde(rename = "durations")]
color_durations: Option<bool>,

/// Disable color-coding for terminated tasks.
#[clap(long = "no-terminated-colors", parse(from_flag = std::ops::Not::not), group = "colors")]
pub(crate) color_terminated: bool,
#[clap(long = "no-terminated-colors", group = "colors")]
#[serde(rename = "terminated")]
color_terminated: Option<bool>,
}

#[derive(Debug, Clone, Deserialize)]
pub struct ConfigFile {
charset: Option<CharsetConfig>,
colors: Option<ColorsConfig>,
}

#[derive(Debug, Clone, Deserialize)]
pub struct CharsetConfig {
lang: Option<String>,
ascii_only: Option<bool>,
}

#[derive(Debug, Clone, Deserialize)]
pub struct ColorsConfig {
enabled: Option<bool>,
truecolor: Option<bool>,
palette: Option<Palette>,
enable: Option<ColorToggles>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: these are only used for parsing the TOML config file, they're not exposed to the rest of the crate, as we turn them into a Config before returning it. i think these don't need to be pub:

Suggested change
#[derive(Debug, Clone, Deserialize)]
pub struct ConfigFile {
charset: Option<CharsetConfig>,
colors: Option<ColorsConfig>,
}
#[derive(Debug, Clone, Deserialize)]
pub struct CharsetConfig {
lang: Option<String>,
ascii_only: Option<bool>,
}
#[derive(Debug, Clone, Deserialize)]
pub struct ColorsConfig {
enabled: Option<bool>,
truecolor: Option<bool>,
palette: Option<Palette>,
enable: Option<ColorToggles>,
#[derive(Debug, Clone, Deserialize)]
struct ConfigFile {
charset: Option<CharsetConfig>,
colors: Option<ColorsConfig>,
}
#[derive(Debug, Clone, Deserialize)]
struct CharsetConfig {
lang: Option<String>,
ascii_only: Option<bool>,
}
#[derive(Debug, Clone, Deserialize)]
struct ColorsConfig {
enabled: Option<bool>,
truecolor: Option<bool>,
palette: Option<Palette>,
enable: Option<ColorToggles>,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, it might be worth adding comments explaining that these types are used so that the structure of the config file can be different from how the CLI arguments are structured?

}

// === impl Config ===

impl Config {
pub fn from_config() -> color_eyre::Result<Self> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure if from_config() is the best name for this, since it also parses the config from the command line arguments as well?

let xdg = ViewOptions::from_config(ConfigPath::Xdg)?;
let current = ViewOptions::from_config(ConfigPath::Current)?;
let base = match (xdg, current) {
(None, None) => None,
(Some(xdg), None) => Some(xdg),
(None, Some(current)) => Some(current),
(Some(mut xdg), Some(current)) => {
xdg.merge_with(current);
Some(xdg)
}
};
let mut config = Self::parse();
let view_options = match base {
None => config.view_options,
Some(mut base) => {
base.merge_with(config.view_options);
base
}
};
config.view_options = view_options;
Ok(config)
}

pub fn trace_init(&mut self) -> color_eyre::Result<()> {
let filter = std::mem::take(&mut self.env_filter);
use tracing_subscriber::prelude::*;
Expand Down Expand Up @@ -167,7 +218,9 @@ impl Config {

impl ViewOptions {
pub fn is_utf8(&self) -> bool {
self.lang.ends_with("UTF-8") && !self.ascii_only
let lang = self.lang.as_deref().unwrap_or_default();
let ascii_only = self.ascii_only.unwrap_or(true);
lang.ends_with("UTF-8") && !ascii_only
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it occurs to me that we can simplify this a bit if we check the value of self.ascii_only before we touch self.lang:

Suggested change
let lang = self.lang.as_deref().unwrap_or_default();
let ascii_only = self.ascii_only.unwrap_or(true);
lang.ends_with("UTF-8") && !ascii_only
if !self.ascii_only.unwrap_or(true) {
return false;
}
self.lang.as_deref().unwrap_or_default().ends_with("UTF-8")

this has the advantage of avoiding the string comparison when the ascii_only flag is set.

}

/// Determines the color palette to use.
Expand All @@ -179,7 +232,7 @@ impl ViewOptions {
/// - Checking the `terminfo` database via `tput`
pub(crate) fn determine_palette(&self) -> Palette {
// Did the user explicitly disable colors?
if self.no_colors {
if self.no_colors.unwrap_or(true) {
tracing::debug!("colors explicitly disabled by `--no-colors`");
return Palette::NoColors;
}
Expand Down Expand Up @@ -219,6 +272,27 @@ impl ViewOptions {
pub(crate) fn toggles(&self) -> ColorToggles {
self.toggles
}

fn from_config(path: ConfigPath) -> color_eyre::Result<Option<Self>> {
let options = ConfigFile::from_config(path)?.map(|config| config.into_view_options());
Ok(options)
}

fn merge_with(&mut self, command_line: ViewOptions) {
self.no_colors = command_line.no_colors.or_else(|| self.no_colors.take());
self.lang = command_line.lang.or_else(|| self.lang.take());
self.ascii_only = command_line.ascii_only.or_else(|| self.ascii_only.take());
self.truecolor = command_line.truecolor.or_else(|| self.truecolor.take());
self.palette = command_line.palette.or_else(|| self.palette.take());
self.toggles.color_durations = command_line
.toggles
.color_durations
.or_else(|| self.toggles.color_durations.take());
self.toggles.color_terminated = command_line
.toggles
.color_terminated
.or_else(|| self.toggles.color_terminated.take());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a minor style suggestion, take it or leave it: what if, instead of mutating self, we had this function take self by value and return a new ViewOptiions? like this:

Suggested change
fn merge_with(&mut self, command_line: ViewOptions) {
self.no_colors = command_line.no_colors.or_else(|| self.no_colors.take());
self.lang = command_line.lang.or_else(|| self.lang.take());
self.ascii_only = command_line.ascii_only.or_else(|| self.ascii_only.take());
self.truecolor = command_line.truecolor.or_else(|| self.truecolor.take());
self.palette = command_line.palette.or_else(|| self.palette.take());
self.toggles.color_durations = command_line
.toggles
.color_durations
.or_else(|| self.toggles.color_durations.take());
self.toggles.color_terminated = command_line
.toggles
.color_terminated
.or_else(|| self.toggles.color_terminated.take());
}
fn merge_with(self, command_line: ViewOptions) -> ViewOptions {
Self {
no_colors: command_line.no_colors.or(self.no_colors),
lang: command_line.lang.or(self.lang),
ascii_only: command_line.ascii_only.or(self.ascii_only),
truecolor: command_line.truecolor.or(self.truecolor),
palette: command_line.palette.or(self.palette),
toggles: ColorToggles {
color_durations: command_line
.toggles
.color_durations
.or(self.toggles.color_durations)
color_terminated: command_line
.toggles
.color_terminated
.or(self.toggles.color_terminated)
}
}
}

This approach has one big advantage, in my opinion: if we add new fields to the ViewOptions type in the future, but forget to add code in merge_with to merge those fields, the current implementation will just use the values from the config file and ignore the values from the command-line, because it's modifying the existing instance of ViewOptions. If we make the change I suggested, though, forgetting to merge any new fields would result in a compile-time error, because we are constructing a new instance of ViewOptions, and we wouldn't be adding the new fields to the returned value. It would be nice to be able to prevent that kind of bug at compile-time, IMO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(we probably want to do the same thing in the Config struct's merge_with function, too...)

Copy link
Contributor Author

@nrskt nrskt Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach has one big advantage

Sounds great! I agree with your opinion.
682a261

}

fn parse_true_color(s: &str) -> bool {
Expand All @@ -238,3 +312,86 @@ impl FromStr for RetainFor {
}
}
}

// === impl ColorToggles ===

impl ColorToggles {
pub fn color_durations(&self) -> bool {
self.color_durations.map(std::ops::Not::not).unwrap_or(true)
}

pub fn color_terminated(&self) -> bool {
self.color_durations.map(std::ops::Not::not).unwrap_or(true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor style nit: Not is imported, so we could just write

Suggested change
self.color_durations.map(std::ops::Not::not).unwrap_or(true)
}
pub fn color_terminated(&self) -> bool {
self.color_durations.map(std::ops::Not::not).unwrap_or(true)
self.color_durations.map(Not::not).unwrap_or(true)
}
pub fn color_terminated(&self) -> bool {
self.color_durations.map(Not::not).unwrap_or(true)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might also be worth having a comment or something here explaining why these are inverted?

}
}

// === impl ColorToggles ===

impl ConfigFile {
fn from_config(path: ConfigPath) -> color_eyre::Result<Option<Self>> {
let config = path
.into_path()
.and_then(|path| fs::read_to_string(path).ok())
.map(|raw| toml::from_str::<ConfigFile>(&raw))
.transpose()
.wrap_err_with(|| format!("failed to parse {:?}", path.into_path()))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A small note: I think the path will be formatted nicer if we use Path::display here instead of its Debug implementation:

Suggested change
.wrap_err_with(|| format!("failed to parse {:?}", path.into_path()))?;
.wrap_err_with(|| format!("failed to parse {}", path.into_path().display()))?;

Ok(config)
}

fn into_view_options(self) -> ViewOptions {
ViewOptions {
no_colors: self.no_colors(),
lang: self.charset.as_ref().and_then(|config| config.lang.clone()),
ascii_only: self.charset.as_ref().and_then(|config| config.ascii_only),
truecolor: self.colors.as_ref().and_then(|config| config.truecolor),
palette: self.colors.as_ref().and_then(|config| config.palette),
toggles: ColorToggles {
color_durations: self.color_durations(),
color_terminated: self.color_terminated(),
},
}
}

fn no_colors(&self) -> Option<bool> {
self.colors
.as_ref()
.and_then(|config| config.enabled.map(Not::not))
}

fn color_durations(&self) -> Option<bool> {
self.colors
.as_ref()
.and_then(|config| config.enable.map(|toggles| toggles.color_durations()))
}

fn color_terminated(&self) -> Option<bool> {
self.colors
.as_ref()
.and_then(|config| config.enable.map(|toggles| toggles.color_terminated()))
}
}

#[derive(Debug, Clone, Copy)]
enum ConfigPath {
Xdg,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a minor nitpick, but I don't think Xdg is the best thing to call this variant. The dirs trait uses XDG_CONFIG_HOME on Linux, but it uses a different directory on Windows or macOS. Calling it Xdg kind of suggests to the reader that it is specifically using XDG_CONFIG_HOME...maybe we should call it something like User or Home or something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

surely, It's right. I choose Home.
2da4fdf

Current,
}

impl ConfigPath {
fn into_path(self) -> Option<PathBuf> {
match self {
Self::Xdg => {
let mut path = dirs::config_dir();
if let Some(path) = path.as_mut() {
path.push("tokio-console/console.toml");
}
path
}
Self::Current => {
let mut path = PathBuf::new();
path.push("./console.toml");
Some(path)
}
}
}
}
9 changes: 7 additions & 2 deletions tokio-console/src/main.rs
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,6 @@ use color_eyre::{eyre::eyre, Help, SectionExt};
use console_api::tasks::TaskDetails;
use state::State;

use clap::Parser as Clap;
use futures::stream::StreamExt;
use tokio::sync::{mpsc, watch};
use tui::{
Expand All @@ -26,7 +25,13 @@ mod warnings;

#[tokio::main]
async fn main() -> color_eyre::Result<()> {
let mut args = config::Config::parse();
let mut args = match config::Config::from_config() {
Err(e) => {
eprintln!("failed to parse config file: {:#?}", e);
std::process::exit(1);
}
Ok(args) => args,
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that any config parsing error will be displayed more nicely if we format the error with its standard Debug ({:?}) formatter rather than its alternate-mode Debug formatter ({:#?}), according to the eyre documentation. So, if we change this to

Suggested change
let mut args = match config::Config::from_config() {
Err(e) => {
eprintln!("failed to parse config file: {:#?}", e);
std::process::exit(1);
}
Ok(args) => args,
};
let mut args = match config::Config::from_config() {
Err(e) => {
eprintln!("failed to parse config file: {:?}", e);
std::process::exit(1);
}
Ok(args) => args,
};

we'll get a much nicer message.

The documentation also notes that

Note that this is the representation you get by default if you return an error from fn main instead of printing it explicitly yourself.

So, we could also just write this and get the same output, which I think is much nicer:

Suggested change
let mut args = match config::Config::from_config() {
Err(e) => {
eprintln!("failed to parse config file: {:#?}", e);
std::process::exit(1);
}
Ok(args) => args,
};
let mut args = config::Config::from_config()?;

When I make either of those changes and run the console with the invalid configuration file from your example, I get output like this, which I think is more helpful than the :#? output:

:; cargo run
   Compiling tokio-console v0.1.3 (/home/eliza/Code/console/tokio-console)
    Finished dev [unoptimized + debuginfo] target(s) in 5.66s
     Running `target/debug/tokio-console`
Error: failed to parse Some("./console.toml")

Caused by:
    invalid type: string "string value", expected a boolean for key `charset.ascii_only` at line 2 column 14

Location:
    tokio-console/src/config.rs:337:14

(unfortunately, the output isn't colored, because we don't install our custom eyre handler until after we've parsed the config file...but there's not really a way around that, so this is good enough!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have tried it and getting the expected result. c87ddfc

❯ RUST_LOG=debug cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/tokio-console`
Error: failed to parse ./console.toml

Caused by:
    invalid type: string "string value", expected a boolean for key `charset.ascii_only` at line 2 column 14

Location:
    tokio-console/src/config.rs:337:14

let retain_for = args.retain_for();
args.trace_init()?;
tracing::debug!(?args.target_addr, ?args.view_options);
Expand Down
Loading