From 0cb10866ce52fbe59a1e5750b49f6948295d40ea Mon Sep 17 00:00:00 2001 From: Philipp Baumann Date: Fri, 19 Jan 2024 23:08:40 +0100 Subject: [PATCH] fix conflict --- dev/running_r_or_shell_code_in_nix_from_r.Rmd | 26 +++++++++-------- .../running-r-or-shell-code-in-nix-from-r.Rmd | 28 +++++++++++-------- 2 files changed, 31 insertions(+), 23 deletions(-) diff --git a/dev/running_r_or_shell_code_in_nix_from_r.Rmd b/dev/running_r_or_shell_code_in_nix_from_r.Rmd index 232958d7..5662d92a 100644 --- a/dev/running_r_or_shell_code_in_nix_from_r.Rmd +++ b/dev/running_r_or_shell_code_in_nix_from_r.Rmd @@ -5,7 +5,7 @@ editor_options: chunk_output_type: console --- -# Testing Code in Evolving Software Dependency Environments with Confidence +## Testing Code in Evolving Software Dependency Environments with Confidence Adhering to sound versioning practices is crucial for ensuring the reproducibility of software. Despite the expertise in software engineering, the ever-growing complexity and continuous development of new, potentially disruptive features present significant challenges in maintaining code functionality over time. This pertains not only to backward compatibility but also to future-proofing. When code handles critical production loads and relies on numerous external software libraries, it's likely that these dependencies will evolve. Infrastructure-as-code and other DevOps principles shine in addressing these challenges. However, they may appear less approachable and more labor-intensive for the average R developer. @@ -15,15 +15,10 @@ Are you ready to test your custom R functions and system commands in a a differe We aim to accommodate various use cases, considering a gradient of declarativity in individual or sets of software environments based on personal preferences. There are two main modes for defining and comparing code running through R and system commands (command line interfaces; CLIs) -1. 'System-to-Nix' environments: We assume that you launch an R session with an R version defined on your host operating system, either from the terminal or an integrated development environment like RStudio. You need to make sure that you actively control and know where you installed R and R packages from, and at what versions. You may have interactively tested that your custom function pipeline worked for the current setup. Most importantly, you want to check whether you get your computations running and achieve identical results when going back to a Nix revision that represent either newer or also older versions of R and package sources. -2. 'Nix-to-Nix' environments: Your goals of testing code are the same as in 1., but you want more fine-grained control in the source environment where you launch \`with_nix()\` from, too. You are probably on the way of getting a passionate Nix user. - -## Case study 1: Evolution of base R - 1. **'System-to-Nix'** environments: We assume that you launch an R session with an R version defined on your host operating system, either from the terminal or an integrated development environment like RStudio. You need to make sure that you actively control and know where you installed R and R packages from, and at what versions. You may have interactively tested that your custom function pipeline worked for the current setup. Most importantly, you want to check whether you get your computations running and achieve identical results when going back to a Nix revision that represent either newer or also older versions of R and package sources. 2. **'Nix-to-Nix'** environments: Your goals of testing code are the same as in 1., but you want more fine-grained control in the source environment where you launch \`with_nix()\` from, too. You are probably on the way of getting a passionate Nix user. -# Case study 1: Evolution of base R +## Case study 1: Evolution of base R Carefully curated software improves over time, so does R. We pick an example from the R changelog, the following [literal entry in R 4.2.0](https://cran.r-project.org/doc/manuals/r-release/NEWS.html): @@ -45,7 +40,7 @@ init( ) ``` -Next, we write a \`default.nix\` file containing Nix expressions that pin R version 4.2.0 from Nixpkgs. +Next, we write a `default.nix` file containing Nix expressions that pin R version 4.2.0 from Nixpkgs. ```{r, eval=FALSE} rix( @@ -55,13 +50,22 @@ rix( ) ``` -We know have set up the configuration for R 4.2.0 set up in a `default.nix` file in the folder `./env-1R-4-2-0.` +We know have set up the configuration for R 4.2.0 set up in a `default.nix` file in the folder `./env-1R-4-2-0`. Since you are sure you are using an R version higher 4.2.0 available on your system, you can check what that `as.vector.data.frame()` S3 method returns a list. ```{r, eval=FALSE} df <- data.frame(a = 1:3, b = 4:6) -out <- as.vector(x = df, mode ="list") +(out <- as.vector(x = df, mode ="list")) +``` + +To formally confirm in a 'System-to-Nix' approach that the `out` object is identical since `R` \>= 4.2.0, we define a function that runs the computation above. Then, we will evaluate it through a `nix-shell` R session. This adds both build-time and run-time purity with the declarative Nix software configuration we have made above. Leveraging computing on the language, static code analysis, detecting and serializing as well as deserializing global objects of a function `expr` (save R objects), and system command execution via `Rscript` in a `nix-shell` environment we can achieve perfect isolation. At the same time, we can shuffle and input arguments of `expr` , its call stack and as well its outputs between the Nix-R and the system's R sessions. + +```{r} +df_as_vector <- function(x) { + out <- as.vector(x = x, mode = "list") + return(out) +} ``` ## Case study 2: Breaking changes in {stringr} 1.5.0 -We add one more layer to the reproducibility of R. User libraries from CRAN or GitHub, one thing that makes R shine is the huge collection of software packages available from the community. +We add one more layer to the reproducibility of R. User libraries from CRAN or GitHub, one thing that makes R shine is the huge collection of software packages available from the community. Despite diff --git a/vignettes/running-r-or-shell-code-in-nix-from-r.Rmd b/vignettes/running-r-or-shell-code-in-nix-from-r.Rmd index 94a10c06..366610ef 100644 --- a/vignettes/running-r-or-shell-code-in-nix-from-r.Rmd +++ b/vignettes/running-r-or-shell-code-in-nix-from-r.Rmd @@ -20,7 +20,7 @@ library(rix) -# Testing Code in Evolving Software Dependency Environments with Confidence +## Testing Code in Evolving Software Dependency Environments with Confidence Adhering to sound versioning practices is crucial for ensuring the reproducibility of software. Despite the expertise in software engineering, the ever-growing complexity and continuous development of new, potentially disruptive features present significant challenges in maintaining code functionality over time. This pertains not only to backward compatibility but also to future-proofing. When code handles critical production loads and relies on numerous external software libraries, it's likely that these dependencies will evolve. Infrastructure-as-code and other DevOps principles shine in addressing these challenges. However, they may appear less approachable and more labor-intensive for the average R developer. @@ -31,17 +31,11 @@ Are you ready to test your custom R functions and system commands in a a differe We aim to accommodate various use cases, considering a gradient of declarativity in individual or sets of software environments based on personal preferences. There are two main modes for defining and comparing code running through R and system commands (command line interfaces; CLIs) -1. 'System-to-Nix' environments: We assume that you launch an R session with an R version defined on your host operating system, either from the terminal or an integrated development environment like RStudio. You need to make sure that you actively control and know where you installed R and R packages from, and at what versions. You may have interactively tested that your custom function pipeline worked for the current setup. Most importantly, you want to check whether you get your computations running and achieve identical results when going back to a Nix revision that represent either newer or also older versions of R and package sources. -2. 'Nix-to-Nix' environments: Your goals of testing code are the same as in 1., but you want more fine-grained control in the source environment where you launch \`with_nix()\` from, too. You are probably on the way of getting a passionate Nix user. - - -## Case study 1: Evolution of base R - 1. **'System-to-Nix'** environments: We assume that you launch an R session with an R version defined on your host operating system, either from the terminal or an integrated development environment like RStudio. You need to make sure that you actively control and know where you installed R and R packages from, and at what versions. You may have interactively tested that your custom function pipeline worked for the current setup. Most importantly, you want to check whether you get your computations running and achieve identical results when going back to a Nix revision that represent either newer or also older versions of R and package sources. 2. **'Nix-to-Nix'** environments: Your goals of testing code are the same as in 1., but you want more fine-grained control in the source environment where you launch \`with_nix()\` from, too. You are probably on the way of getting a passionate Nix user. -# Case study 1: Evolution of base R +## Case study 1: Evolution of base R Carefully curated software improves over time, so does R. We pick an example from the R changelog, the following [literal entry in R 4.2.0](https://cran.r-project.org/doc/manuals/r-release/NEWS.html): @@ -65,7 +59,7 @@ init( ) ``` -Next, we write a \`default.nix\` file containing Nix expressions that pin R version 4.2.0 from Nixpkgs. +Next, we write a `default.nix` file containing Nix expressions that pin R version 4.2.0 from Nixpkgs. ```{r eval = FALSE} @@ -76,15 +70,25 @@ rix( ) ``` -We know have set up the configuration for R 4.2.0 set up in a `default.nix` file in the folder `./env-1R-4-2-0.` +We know have set up the configuration for R 4.2.0 set up in a `default.nix` file in the folder `./env-1R-4-2-0`. Since you are sure you are using an R version higher 4.2.0 available on your system, you can check what that `as.vector.data.frame()` S3 method returns a list. ```{r eval = FALSE} df <- data.frame(a = 1:3, b = 4:6) -out <- as.vector(x = df, mode ="list") +(out <- as.vector(x = df, mode ="list")) +``` + +To formally confirm in a 'System-to-Nix' approach that the `out` object is identical since `R` \>= 4.2.0, we define a function that runs the computation above. Then, we will evaluate it through a `nix-shell` R session. This adds both build-time and run-time purity with the declarative Nix software configuration we have made above. Leveraging computing on the language, static code analysis, detecting and serializing as well as deserializing global objects of a function `expr` (save R objects), and system command execution via `Rscript` in a `nix-shell` environment we can achieve perfect isolation. At the same time, we can shuffle and input arguments of `expr` , its call stack and as well its outputs between the Nix-R and the system's R sessions. + + +```{r} +df_as_vector <- function(x) { + out <- as.vector(x = x, mode = "list") + return(out) +} ``` ## Case study 2: Breaking changes in {stringr} 1.5.0 -We add one more layer to the reproducibility of R. User libraries from CRAN or GitHub, one thing that makes R shine is the huge collection of software packages available from the community. +We add one more layer to the reproducibility of R. User libraries from CRAN or GitHub, one thing that makes R shine is the huge collection of software packages available from the community. Despite