# Maintain packages with {fusen}

library(fusen)

# Daily use of {fusen}

## Add a new set of chunks in the current Rmd

• Name the chunks using function name planned to be created
• Decide if this function is exported to the user or not

## Create a new flat Rmd template

To add a new family of functions, create a new flat Rmd template

add_flat_template(template = "add")

# How to maintain a {fusen}? Can I use {fusen} with old-way packages ?

After you inflate() the “flat_template.Rmd”, your code appears twice in the package. In the “flat_template.Rmd” itself and in the correct place for it to be a package. Take it as a documentation for the other developers.
Maintaining such a package requires a choice:

• Option 1: Modifications are only added to the “flat_template.Rmd” file, which then is inflated to update all packages files
• Option 2: Modifications are realized in the package files directly, and the “flat_template.Rmd” file must be protected from any use.

Your first inflate() may not directly work as expected as with any R code that you write. In this case, you can continue to implement your functionality using Option 1.

Advice 1 : Use Option 1 until you find it too complicated to be used ! I assure you, you will find the moment when you say : ok this is not possible anymore…

Advice 2 : Use git as soon as possible, this will avoid losing your work if you made some modifications in the wrong place

## Option 1: Continue with the “flat_template.Rmd”

• (+) This does not require to fully understand the package structure and files to continue building your package, and you continue to develop in a unique file
• (+) You are encouraged to continue documenting and testing all parts of your package
• (-) You need to pay attention to checking and debugging tools that may direct you to the R file directly. This requires to pay attention and always be sure you are modifying code in the flat template file, to be inflated.
• (-) This may trouble co-developers who already built packages

=> {fusen} itself is built as is. Each modification is added to the dedicated dev_history file and then inflated

## Option 2: Maintain like a classical package

• (+) You can use dedicated checking and debugging tools as is, in particular in RStudio. There are built to direct you as quickly as possible to the source of the problem
• (+) This allows collaboration with more advanced developers who are used to debug in the package structure directly
• (-) This requires to understand the structure and files of a package and how they interact each other, and be able to jump from one file to the other, in the correct folder. This may drives you lazy to continue documenting and testing your modifications
• This requires to protect the flat template file, so that you never use it again. <!-- Do not edit by hand--> is the minimum. Then you can add <!-- File used to start new functionalities, do not use anymore, go directly to appropriate files in the package -->, and you can rename the old template with “old-flat_template.Rmd” for instance.

=> This is the way I add new functionalities in packages that started in the old way, and in specific cases where inflating is now too complicated, like for function inflate() and all its unit tests in this very {fusen} package.

# What about packages already built the old way ?

The “flat_template.Rmd” template only modifies files related to functions presented inside the template. This does not remove or modify previous functions, tests or vignettes, provided that names are different.

• {fusen} itself was started in the classical way before having enough functions to be able to build a package from itself. This does not prevent me at all to use {fusen} to build himself now !
• If you want to modify existing functionalities, you will need to continue maintain your already-built package in the classical way
• If you want to add new functionalities, correctly documented and tested, you can use {fusen}. This will not delete previous work.
• Use the “Option 2” above to continue after the development of your functionality

## Let’s try to convince package developers with an example

• Install {fusen} : install.packages("fusen")
• Open a project for one of your already existing package
• Commit your previous state if you are afraid of {fusen}
• If you are not sure enough to do it on an existing package, then follow the guide in “How to use fusen”
• Run in the Console : fusen::add_flat_template("add")
• A Rmd file appears in “dev/flat_additional.Rmd”. Open it.
• Add a new function in the function chunk. For instance:
#' My median
#'
#' @param x Vector of Numeric values
#' @inheritParams stats::median
#'
#' @return
#' Median of vector x
#' @export
#'
#' @examples
my_median <- function(x, na.rm = TRUE) {
if (!is.numeric(x)) {stop("x should be numeric")}
stats::median(x, na.rm = na.rm)
}
• Add a corresponding example in the example chunk. For instance:
my_median(1:12)
• Add a corresponding unit test in the test chunk. For instance:
test_that("my_median works properly and show error if needed", {
expect_true(my_median(1:12) == 6.5)
expect_error(my_median("text"))
})
• Run command of the last chunk: fusen::inflate(flat_file = "dev/flat_additional.Rmd")
• This will run {attachment} behind the scene and may modify the list of dependencies in the DESCRIPTION file accordingly. Use fusen::inflate(flat_file = "dev/flat_additional.Rmd", document = FALSE) to avoid that.
• This will also run devtools::check(). Use fusen::inflate(flat_file = "dev/flat_additional.Rmd", check = FALSE) to avoid that.

That’s it!
You added a new function in your package, along with example, test and a new vignette:

• R/my_median.R
• tests/testthat/test-my_median.R
• vignettes/get-started.Rmd