doc: update doc with last infos

README.Rmd

@@ -34,10 +34,10 @@ knitr::include_graphics("man/figures/fusen_inflate_functions.png")
 
 _Fill the flat Rmd (or qmd) template with everything in one place and {fusen} will inflate the identified parts in the correct package files and directories._
 
-> The {fusen} Rmarkdown template encourages users to fill their documentation and tests at the same time of writing their functions code. Thanks to the R package structure used by {fusen}, you can built a robust workflow or R package. {fusen} simplifies and reduces the number of steps towards a full R package.   
+> The {fusen} Rmarkdown template encourages users to fill their documentation and tests at the same time of writing their functions code. Thanks to the R package structure used by {fusen}, you can build a robust workflow or R package. {fusen} simplifies and reduces the number of steps towards a full R package.   
 > After that, your {pkgdown} documentation website is one command away to be shared with all your users.
 
-This {fusen} package is a real-world example of {fusen} use as it was itself created from the flat templates available in `"dev/"` folder in its GitHub repository.
+This {fusen} package is a real-world example of {fusen} use as it is itself created from the flat templates available in `"dev/"` folder in its GitHub repository. You can have a look at its architecture in the [Readme of the "dev" directory](https://github.com/ThinkR-open/fusen/blob/main/dev/README.md).
 
 ## Installation
 
@@ -49,20 +49,15 @@ install.packages("fusen")
 > *Full documentation for the CRAN version is here: https://thinkr-open.github.io/fusen/*
 
 
-You can install the development version of {fusen} from GitHub:
+You can install the development version of {fusen} from r-universe or GitHub:
 
 ```{r, eval=FALSE}
 # From r-universe.dev (No need for GITHUB_PAT)
-options(repos = c(
-  thinkropen = "https://thinkr-open.r-universe.dev",
-  CRAN = "https://cloud.r-project.org"
-))
-# Download and install {fusen} in R
-install.packages("fusen")
+install.packages("fusen", repos = c("https://thinkr-open.r-universe.dev", "https://cloud.r-project.org"))
 
-# With {remotes} using GitHub API - Need for GITHUB_PAT
-# install.packages("remotes")
-remotes::install_github("ThinkR-open/fusen")
+# Or with {pak} using GitHub API - Need for GITHUB_PAT
+# install.packages("pak")
+pak::pak("ThinkR-open/fusen")
 ```
 > *Full documentation for the development version is here: https://thinkr-open.github.io/fusen/dev/*
 
@@ -144,19 +139,21 @@ _Note that the `"flat*.Rmd"` files created with templates `full` and `teaching`
 
 There is a dedicated vignette to answer this: https://thinkr-open.github.io/fusen/articles/Maintain-packages-with-fusen.html
 
-- **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.
+- **Option 1**: After a first inflate of your flat file, you can continue developing in the "flat_template.Rmd" file, and then inflate it using `fusen::inflat_all()`
+- **Option 2**: After you're done with inflating, you can decide to deprecate your flat file with `fusen::deprecate_flat_file()` and develop in the package files directly, as for any other R package. 'fusen' has no impact on the structure of a classical package once inflated.
 
 > Advice : Use git as soon as possible, this will avoid losing your work if you made some modifications in the wrong place
 
 ## Who is {fusen} for?
 
-When you write a Rmarkdown file (or a vignette), you create a documentation for your analysis (or package). Inside, you write some functions, you test your functions with examples and you maybe write some unit tests to verify the outputs. This is even more true if you follow this guide : ['Rmd first': When development starts with documentation](https://rtask.thinkr.fr/when-development-starts-with-documentation/)
-After that, you need to move your functions and scripts in the correct place. Let {fusen} do that for you!
+If you mind about documentation for your users and tests for your maintainers, {fusen} is for you. Start writing documentation and tests while you conceive your functionalities, so that there are directly available for your users and maintainers.
+
+Indeed, when you write a Rmarkdown file (or a vignette), you create a documentation for your analysis (or package). When you write some functions, you check your functions with examples and you maybe write some unit tests to verify the outputs. This is even more true if you follow this guide : ['Rmd first': When development starts with documentation](https://rtask.thinkr.fr/when-development-starts-with-documentation/)
+Write them all in the same file while you explore the possibilities and let {fusen} store them in the right place for you!
 
-*{fusen} is first addressed to people who never wrote a package before* but know how to write a Rmarkdown file. Understanding package infrastructure and correctly settling it can be frightening. This package may help them do the first step!
+*{fusen} was first addressed to people who never wrote a package before* and know how to write a Rmarkdown file. Understanding package infrastructure and correctly settling it can be frightening. This package may help them do the first step!
 
-*{fusen} is also addressed to more advanced developers who are fed up with switching* between R files, tests files, vignettes. In particular, when changing arguments of a function, we need to change examples, unit tests in multiple places. Here, you can do it in one place. No risk to forget one. Think also about code review: everything related to one function is at the same place.  
+*{fusen} is also addressed to more advanced developers who care about their users and the sustainability of their products, and are fed up with switching* between R files, tests files, vignettes while they prototype their functions. In particular, when changing arguments of a function, we need to change examples, unit tests in multiple places. Here, you can do it in one place. No risk to forget one. Think also about code review: everything related to one function is at the same place.  
 
 ## Q&A : All tips and tricks of a {fusen} template
 
@@ -169,12 +166,13 @@ After that, you need to move your functions and scripts in the correct place. Le
 - How to create a vignette with different title and Index Entry?
 - How not to create a vignette ?
 - How to get a pre-filled template for a specific function name ?
-- How to Inflate multiple flat files ?
+- How to inflate multiple flat files ?
 - How to store multiple functions in a unique R file ?
 - How to read dataset that I usually put in “tests/testthat/” for my unit tests? 
 - Can I load all functions of the current flat file during development without having to `inflate()`?
 - Can I inflate a Quarto qmd file?
 - Can I use {fusen} with {golem}?
+- How can I know if R files were created from a flat or not ?
 
 => See vignette Tips and Tricks: https://thinkr-open.github.io/fusen/articles/tips-and-tricks.html
 

README.md

@@ -27,15 +27,17 @@ and directories.*
 
 > The {fusen} Rmarkdown template encourages users to fill their
 > documentation and tests at the same time of writing their functions
-> code. Thanks to the R package structure used by {fusen}, you can built
+> code. Thanks to the R package structure used by {fusen}, you can build
 > a robust workflow or R package. {fusen} simplifies and reduces the
 > number of steps towards a full R package.  
 > After that, your {pkgdown} documentation website is one command away
 > to be shared with all your users.
 
-This {fusen} package is a real-world example of {fusen} use as it was
+This {fusen} package is a real-world example of {fusen} use as it is
 itself created from the flat templates available in `"dev/"` folder in
-its GitHub repository.
+its GitHub repository. You can have a look at its architecture in the
+[Readme of the “dev”
+directory](https://github.com/ThinkR-open/fusen/blob/main/dev/README.md).
 
 ## Installation
 
@@ -48,20 +50,16 @@ install.packages("fusen")
 > *Full documentation for the CRAN version is here:
 > <https://thinkr-open.github.io/fusen/>*
 
-You can install the development version of {fusen} from GitHub:
+You can install the development version of {fusen} from r-universe or
+GitHub:
 
 ``` r
 # From r-universe.dev (No need for GITHUB_PAT)
-options(repos = c(
-  thinkropen = "https://thinkr-open.r-universe.dev",
-  CRAN = "https://cloud.r-project.org"
-))
-# Download and install {fusen} in R
-install.packages("fusen")
+install.packages("fusen", repos = c("https://thinkr-open.r-universe.dev", "https://cloud.r-project.org"))
 
-# With {remotes} using GitHub API - Need for GITHUB_PAT
-# install.packages("remotes")
-remotes::install_github("ThinkR-open/fusen")
+# Or with {pak} using GitHub API - Need for GITHUB_PAT
+# install.packages("pak")
+pak::pak("ThinkR-open/fusen")
 ```
 
 > *Full documentation for the development version is here:
@@ -180,38 +178,47 @@ for your chunks.
 There is a dedicated vignette to answer this:
 <https://thinkr-open.github.io/fusen/articles/Maintain-packages-with-fusen.html>
 
-  - **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.
+  - **Option 1**: After a first inflate of your flat file, you can
+    continue developing in the “flat\_template.Rmd” file, and then
+    inflate it using `fusen::inflat_all()`
+  - **Option 2**: After you’re done with inflating, you can decide to
+    deprecate your flat file with `fusen::deprecate_flat_file()` and
+    develop in the package files directly, as for any other R package.
+    ‘fusen’ has no impact on the structure of a classical package once
+    inflated.
 
 > Advice : Use git as soon as possible, this will avoid losing your work
 > if you made some modifications in the wrong place
 
 ## Who is {fusen} for?
 
-When you write a Rmarkdown file (or a vignette), you create a
-documentation for your analysis (or package). Inside, you write some
-functions, you test your functions with examples and you maybe write
+If you mind about documentation for your users and tests for your
+maintainers, {fusen} is for you. Start writing documentation and tests
+while you conceive your functionalities, so that there are directly
+available for your users and maintainers.
+
+Indeed, when you write a Rmarkdown file (or a vignette), you create a
+documentation for your analysis (or package). When you write some
+functions, you check your functions with examples and you maybe write
 some unit tests to verify the outputs. This is even more true if you
 follow this guide : [‘Rmd first’: When development starts with
 documentation](https://rtask.thinkr.fr/when-development-starts-with-documentation/)
-After that, you need to move your functions and scripts in the correct
-place. Let {fusen} do that for you\!
+Write them all in the same file while you explore the possibilities and
+let {fusen} store them in the right place for you\!
 
-*{fusen} is first addressed to people who never wrote a package before*
-but know how to write a Rmarkdown file. Understanding package
+*{fusen} was first addressed to people who never wrote a package before*
+and know how to write a Rmarkdown file. Understanding package
 infrastructure and correctly settling it can be frightening. This
 package may help them do the first step\!
 
-*{fusen} is also addressed to more advanced developers who are fed up
-with switching* between R files, tests files, vignettes. In particular,
-when changing arguments of a function, we need to change examples, unit
-tests in multiple places. Here, you can do it in one place. No risk to
-forget one. Think also about code review: everything related to one
-function is at the same place.
+*{fusen} is also addressed to more advanced developers who care about
+their users and the sustainability of their products, and are fed up
+with switching* between R files, tests files, vignettes while they
+prototype their functions. In particular, when changing arguments of a
+function, we need to change examples, unit tests in multiple places.
+Here, you can do it in one place. No risk to forget one. Think also
+about code review: everything related to one function is at the same
+place.
 
 ## Q\&A : All tips and tricks of a {fusen} template
 
@@ -224,14 +231,15 @@ function is at the same place.
   - How to create a vignette with different title and Index Entry?
   - How not to create a vignette ?
   - How to get a pre-filled template for a specific function name ?
-  - How to Inflate multiple flat files ?
+  - How to inflate multiple flat files ?
   - How to store multiple functions in a unique R file ?
   - How to read dataset that I usually put in “tests/testthat/” for my
     unit tests?
   - Can I load all functions of the current flat file during development
     without having to `inflate()`?
   - Can I inflate a Quarto qmd file?
   - Can I use {fusen} with {golem}?
+  - How can I know if R files were created from a flat or not ?
 
 \=\> See vignette Tips and Tricks:
 <https://thinkr-open.github.io/fusen/articles/tips-and-tricks.html>

dev/README.Rmd

@@ -4,10 +4,12 @@ output: github_document
 
 # Here is a map of the architecture of the 'fusen' project
 
+The _keep_ section is for independent files, which were not issued from a flat file.
+
 ```{r, message=FALSE, results='asis'}
 pkgload::load_all()
 
 usethis::with_project(here::here(), {
-  draw_the_tree(silent = TRUE)
+  fusen::draw_the_tree(silent = TRUE)
 })
 ```

dev/README.md

@@ -1,11 +1,14 @@
 
 # Here is a map of the architecture of the ‘fusen’ project
 
+The *keep* section is for independent files, which were not issued from
+a flat file.
+
 ``` r
 pkgload::load_all()
 
 usethis::with_project(here::here(), {
-  draw_the_tree(silent = TRUE)
+  fusen::draw_the_tree(silent = TRUE)
 })
 ```
 
@@ -76,7 +79,7 @@ usethis::with_project(here::here(), {
           - tests/testthat/test-get\_package\_structure.R
           - tests/testthat/test-get\_all\_created\_funs.R
       - vignettes
-          - vignettes/draw-a-map-of-your-package-files-and-functions.Rmd
+          - vignettes/draw-a-tree-of-your-package-files-and-functions.Rmd
   - flat\_history\_core.Rmd
       - flat\_title
           - dev\_history.Rmd

dev/config_fusen.yaml

@@ -51,10 +51,10 @@ flat_get_package_structure.Rmd:
   tests:
   - tests/testthat/test-get_package_structure.R
   - tests/testthat/test-get_all_created_funs.R
-  vignettes: vignettes/draw-a-map-of-your-package-files-and-functions.Rmd
+  vignettes: vignettes/draw-a-tree-of-your-package-files-and-functions.Rmd
   inflate:
     flat_file: dev/flat_get_package_structure.Rmd
-    vignette_name: Draw a map of your package files and functions
+    vignette_name: Draw a tree of your package files and functions
     open_vignette: true
     check: true
     document: true

dev/flat_get_package_structure.Rmd

@@ -211,7 +211,7 @@ draw_the_tree <- function(structure_list, silent = FALSE) {
 }
 ```
 
-```{r examples-get_package_structure}
+```{r examples-get_package_structure, eval=TRUE}
 #' \dontrun{
 #' # This only works inside a 'fusen' built package
 #' pkg_structure <- get_package_structure()

vignettes/Maintain-packages-with-fusen.Rmd

@@ -48,33 +48,37 @@ 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. 
+- **Option 2**: Modifications are realized in the package files directly as for any other package, and the "flat_template.Rmd" file must be deprecated using `deprecate_flat_file()`. 
 
 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 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
+> Advice 2: Use git as soon as possible, this will avoid losing your work if you made some modifications in the wrong place
+
+> Advice 3: Create a Readme.Rmd in the "dev/" directory with a chunk having `fusen::draw_the_tree()` and knit it. This will help to understand the structure of your package and see what is inflated or not. Have a look at the {fusen} package itself on GitHub to see how it looks like.
 
 
 ## Option 1: Continue with the "flat_template.Rmd"
 
+- (+) You are encouraged to start with documenting and testing your package before you start coding, which is generally a good practice for prototyping.
 - (+) 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
-
+=> The tree structure in the "dev/Readme.md" file is very useful to understand what is inflated or not, and to see the structure of the package
 
 
 ## 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
+- (-) You need to remember that you need to care about your users and maintainers, and that you need to document and test your code as soon as possible, in a different place than the code itself.
 - (-) 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.
+
+You can use `deprecate_flat_file()` to protect the original flat template file, so that you never use it again. Inflated files are also unprotected, so that you can modify them directly.
 
 
 => 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. 

vignettes/draw-a-map-of-your-package-files-and-functions.Rmd → vignettes/draw-a-tree-of-your-package-files-and-functions.Rmd

@@ -1,8 +1,8 @@
 ---
-title: "Draw a map of your package files and functions"
+title: "Draw a tree of your package files and functions"
 output: rmarkdown::html_vignette
 vignette: >
-  %\VignetteIndexEntry{Draw a map of your package files and functions}
+  %\VignetteIndexEntry{Draw a tree of your package files and functions}
   %\VignetteEngine{knitr::rmarkdown}
   %\VignetteEncoding{UTF-8}
 ---
@@ -40,6 +40,8 @@ You can know:
 With `draw_the_map()`, you can draw a tree of the package structure in the console.
 
 ```{r examples-get_package_structure}
+#| eval: yes
+
 #' \dontrun{
 #' # This only works inside a 'fusen' built package
 #' pkg_structure <- get_package_structure()