In lorenzwalthert/fallback: Default values for function calls from yaml config files

knitr::opts_chunk$set(eval = FALSE)

Any interest in moving {fallback} to the next level? It's a package to resolve default values with config files, similar to RStudio's {config}, but extends it with:

• Deriving the key for a config value within the function that resolves it, so we can write:

f <- function(x = fallback(TRUE)) {
  resolve(x)
}
f()
#> fallback
#> package: [package where the function is defined]
#> function: f
#> key: x
#> value: TRUE

• explicitly allow (package developers) to set default values inline, with {config} won't allow: https://github.com/rstudio/config/issues/28. This fallback will be used whenever a user has not defined a value in a config file, which will be the case for most values. So For {styler}, for example, we can have

style_file <- function(file, scope = fallback("tokens"), ...) {
  # ...
}

# then, the user calls the function without a config file.
style_file("path/to/my.R")

# overrides the default inline
style_file("path/to/my.R", scope = "spaces")

# writes a config file to overwrite it, e.g. globally or for that project dir:
yaml::write_yaml(
  list(
    styler = list(scope = "line_breaks")
  ),
  "~/fallback.yaml"
)
style_file("path/to/my.R")

# maybe again changes his mind one time to override this again.
style_file("path/to/my.R", scope = "none")

• Supporting for nested configurations.
• Support for a config file residing in the users's home directory.

I believe such a package would be quite useful, but I don't have time to develop it. I'm happy to transfer the {fallback} package as is to anyone who would like to continue my work. As I said, maybe the only think that remains in the end is the ideas and maybe the API, I am completely fine with (and I think it's a good idea) to move some of the heavy lifting to {config} and only build a thin layer on top.

lorenzwalthert/fallback documentation built on April 19, 2022, 1:51 p.m.