Merge branch 'main' into strict_tests

.github/ISSUE_TEMPLATE/cran-release.yaml → .github/ISSUE_TEMPLATE/cran-release.yml

@@ -1,12 +1,11 @@
 ---
 name: 🎉 CRAN Release
 description: Template for release to CRAN
-title: "[Release]: <version>"
+title: "[CRAN Release]: <version>"
 labels: ["release"]
 assignees:
   - KlaudiaBB
   - cicdguy
-  - shajoezhu
 body:
   - type: markdown
     attributes:
@@ -19,12 +18,10 @@ body:
       description: Any PRs or issues that this release is blocked by.
       placeholder: Add a list of blocking PRs or issues here.
       value: |
-        ### PRs
-
+        #### PRs
         - [ ] PR 1
 
-        ### Issues
-
+        #### Issues
         - [ ] Issue 1
     validations:
       required: true
@@ -35,7 +32,9 @@ body:
       description: Pre-requisites that must be fulfilled before initiating the release process.
       placeholder: Add your list of pre-requisites here.
       value: |
-        - [ ] Make sure you adhere to CRAN submission policy: https://cran.r-project.org/web/packages/submission_checklist.html; https://cran.r-project.org/web/packages/policies.html.
+        - [ ] Make sure you adhere to CRAN submission policy:
+          * https://cran.r-project.org/web/packages/submission_checklist.html
+          * https://cran.r-project.org/web/packages/policies.html.
         - [ ] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release.
         - [ ] Review old/hanging PRs before going into the release (Optional).
         - [ ] Revisit R-package's lifecycle badges (Optional).
@@ -49,46 +48,46 @@ body:
       description: The steps to be taken in order to create a release.
       placeholder: Steps to create a release.
       value: |
-        ### Prepare the release
-
+        #### Prepare the release
         - [ ] Create a new release candidate branch
           `git checkout -b release-candidate-vX.Y.Z`
         - [ ] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package.
         - [ ] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable.
         - [ ] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package and its reverse dependencies (Optional).
           - [ ] Increase versioned dependency on {package name} to >=X.Y.Z (Optional).
         - [ ] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes:
-          `# Make the necessary modifications to your files
+          ```r
+          # Make the necessary modifications to your files
           # Stage the changes
           git add <files your modified>
           # Commit the changes
           git commit -m "[skip vbump] <Your commit message>"
           git push origin release-candidate-vX.Y.Z`
+          ```
 
-        ### Test the release
 
+        #### Test the release
         - [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).
         - [ ] Monitor integration tests, if integration fails, create priority issues on the board.
         - [ ] Execute UAT tests (Optional).
 
-        ### CRAN submission
-
+        #### CRAN submission
         - [ ] Tag the update(s) as a release candidate vX.Y.Z-rc<iteration-number> (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).
-          `# Create rc tag for submission for internal validation
+          ```r
+          # Create rc tag for submission for internal validation
           git tag vX.Y.Z-rc<iteration number>
-          git push origin vX.Y.Z-rc<iteration number>`
+          git push origin vX.Y.Z-rc<iteration number>
+          ```
         - [ ] Build the package locally using the command:`R CMD build .` which will generate a .tar.gz file necessary for the CRAN submission.
         - [ ] Submit the package to https://win-builder.r-project.org/upload.aspx for testing, for more details please see "Building and checking R source packages for Windows": https://win-builder.r-project.org/.
         - [ ] Once tested, send the package that was built in the previous steps to CRAN via this form: https://cran.r-project.org/submit.html.
         - [ ] Address CRAN feedback, tag the package vX.Y.Z-rc(n+1) and repeat the submission to CRAN whenever necessary.
         - [ ] Get the package accepted and published on CRAN.
 
-        ### Tag the release
-
+        #### Tag the release
         - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to 'main'. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit.
 
-        ### Make sure of the following before continuing
-
+        ##### Make sure of the following before continuing
         - [ ] CI checks are passing in GH before releasing the package.
         - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).
 
@@ -100,7 +99,7 @@ body:
           3. Push the tag to make the final release.
           `git push origin vX.Y.Z`
         - [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}.
-        Note: Once the release tag is created, the package is automatically published to internal repositories.
+        **Note:** Once the release tag is created, the package is automatically published to internal repositories.
   - type: textarea
     id: post-release
     attributes:
@@ -112,7 +111,6 @@ body:
         - [ ] Make sure that the package is published to internal repositories.
         - [ ] Make sure internal documentation is up to date.
         - [ ] Review and update installation instructions for the package wherever needed (Optional).
-        - [ ] Update all integration tests to reference the new release.
         - [ ] Announce the release on ________.
   - type: textarea
     id: decision-tree

.github/ISSUE_TEMPLATE/release.yaml → .github/ISSUE_TEMPLATE/release.yml

@@ -18,12 +18,10 @@ body:
       description: Any PRs or issues that this release is blocked by.
       placeholder: Add a list of blocking PRs or issues here.
       value: |
-        ### PRs
-
+        #### PRs
         - [ ] PR 1
 
-        ### Issues
-
+        #### Issues
         - [ ] Issue 1
     validations:
       required: true
@@ -48,46 +46,48 @@ body:
       description: The steps to be taken in order to create a release.
       placeholder: Steps to create a release.
       value: |
-        ### Prepare the release
-
+        #### Prepare the release
         - [ ] Create a new release candidate branch
         `git checkout -b release-candidate-vX.Y.Z`
         - [ ] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package, check README.
         - [ ] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable.
         - [ ] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package.
-        - [ ] Increase versioned dependency on {package name} to >=X.Y.Z.
+          - [ ] Increase versioned dependency on {package name} to >=X.Y.Z.
         - [ ] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes:
-        `# Make the necessary modifications to your files
-        # Stage the changes
-        git add <files your modified>
-        # Commit the changes
-        git commit -m "[skip vbump] <Your commit message>"
-        git push origin release-candidate-vX.Y.Z`
+          ```r
+          # Make the necessary modifications to your files
+          # Stage the changes
+          git add <files your modified>
+          # Commit the changes
+          git commit -m "[skip vbump] <Your commit message>"
+          git push origin release-candidate-vX.Y.Z
+          ```
 
-        ### Test the release
 
+        #### Test the release
         - [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).
         - [ ] Monitor integration tests, if integration fails, create priority issues on the board.
         - [ ] Execute UAT tests (Optional).
 
-        ### Validation loop
 
-        Note: This section is applicable only for regulatory packages.
+        #### Validation loop
+
+        **Note:** This section is applicable only for regulatory packages.
 
         - [ ] Tag the update(s) as a release candidate vX.Y.Z-rc<iteration-number> (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).
-          `# Create rc tag for submission for internal validation
+          ```r
+          # Create rc tag for submission for internal validation
           git tag vX.Y.Z-rc<iteration number>
-          git push origin vX.Y.Z-rc<iteration number>`
+          git push origin vX.Y.Z-rc<iteration number>
+          ```
         - [ ] Submit the package for internal validation.
         - [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Repeat the submission for internal validation if necessary.
         - [ ] Get the package validated.
 
-        ### Tag the release
-
+        #### Tag the release
         - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to `main`. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit.
 
-        #### Make sure of the following before continuing with the release:
-
+        ##### Make sure of the following before continuing with the release:
         - [ ] CI checks are passing in GH.
         - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).
 
@@ -99,7 +99,7 @@ body:
           3. Push the tag to make the final release.
           `git push origin vX.Y.Z`
         - [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}.
-        Note: Once the release tag is created, the package is automatically published to internal repositories.
+        **Note:** Once the release tag is created, the package is automatically published to internal repositories.
   - type: textarea
     id: post-release
     attributes:

DESCRIPTION

@@ -1,8 +1,8 @@
 Type: Package
 Package: teal.data
 Title: Data Model for 'teal' Applications
-Version: 0.4.0.9000
-Date: 2024-02-01
+Version: 0.5.0.9000
+Date: 2024-02-14
 Authors@R: c(
     person("Dawid", "Kaledkowski", , "[email protected]", role = c("aut", "cre"),
            comment = c(ORCID = "0000-0001-9533-457X")),

NEWS.md

@@ -1,4 +1,13 @@
-# teal.data 0.4.0.9000
+# teal.data 0.5.0.9000
+
+# teal.data 0.5.0
+
+### Bug fixes
+* Fix the `get_code_dependency` bug to detect the usage of objects in functions on both the left and right-hand sides for code reproducibility.
+* Remove duplicate entries in the `code_graph`.
+
+### Enhancements
+* Extended `get_code.teal_data()` with a possibility to steer internal methods with `...` parameter.
 
 # teal.data 0.4.0
 

R/dummy_function.R

@@ -1,13 +1,13 @@
-#' Generate sample `CDISC` datasets
+#' Generate sample CDISC datasets
 #'
-#' Retrieves example `CDISC` datasets for use in examples and testing.
+#' Retrieves example CDISC datasets for use in examples and testing.
 #'
 #' This function returns a dummy dataset and should only be used within `teal.data`.
 #' Note that the datasets are not created and maintained in `teal.data`, they are retrieved its dependencies.
 #'
-#' @param dataname (`character(1)`) name of a `CDISC` dataset
+#' @param dataname (`character(1)`) name of a CDISC dataset
 #'
-#' @return A `CDISC` dataset as a `data.frame`.
+#' @return A CDISC dataset as a `data.frame`.
 #'
 #' @export
 example_cdisc_data <- function(dataname = c("ADSL", "ADAE", "ADLB", "ADCM", "ADEX", "ADRS", "ADTR", "ADTTE", "ADVS")) {

R/join_keys.R

@@ -53,7 +53,7 @@
 #' @seealso [join_key()] for creating `join_keys_set`,
 #' [parents()] for parent operations,
 #' [teal_data()] for `teal_data` constructor _and_
-#' [default_cdisc_join_keys] for default `CDISC` keys.
+#' [default_cdisc_join_keys] for default CDISC keys.
 #'
 join_keys <- function(...) {
   if (missing(...)) {

R/teal_data-get_code.R

@@ -77,6 +77,9 @@
 #' For more details see the "Extracting dataset-specific code" section.
 #' @param deparse (`logical`) flag specifying whether to return code as `character` (`deparse = TRUE`) or as
 #' `expression` (`deparse = FALSE`).
+#' @param ... Parameters passed to internal methods. Currently, the only supported parameter is `check_names`
+#' (`logical(1)`) flag,  which is `TRUE` by default. Function warns about missing objects, if they do not exist in
+#' `code` but are passed in `datanames`. To remove the warning, set `check_names = FALSE`.
 #'
 #' @return
 #' Either a character string or an expression. If `datanames` is used to request a specific dataset,
@@ -101,12 +104,12 @@
 #' @aliases get_code,teal_data-method
 #'
 #' @export
-setMethod("get_code", signature = "teal_data", definition = function(object, deparse = TRUE, datanames = NULL) {
+setMethod("get_code", signature = "teal_data", definition = function(object, deparse = TRUE, datanames = NULL, ...) {
   checkmate::assert_character(datanames, min.len = 1L, null.ok = TRUE)
   checkmate::assert_flag(deparse)
 
   code <- if (!is.null(datanames)) {
-    get_code_dependency(object@code, datanames)
+    get_code_dependency(object@code, datanames, ...)
   } else {
     object@code
   }

R/utils-get_code_dependency.R

@@ -154,17 +154,27 @@ fix_shifted_comments <- function(calls) {
 #' @keywords internal
 #' @noRd
 fix_arrows <- function(calls) {
-  lapply(
-    calls,
-    function(call) {
-      call[call$token == "SYMBOL_FUNCTION_CALL" & call$text == "`<-`", c("token", "text")] <- c("LEFT_ASSIGN", "<-")
-      call[call$token == "SYMBOL_FUNCTION_CALL" & call$text == "`->`", c("token", "text")] <- c("RIGHT_ASSIGN", "->")
-      call[call$token == "SYMBOL_FUNCTION_CALL" & call$text == "`<<-`", c("token", "text")] <- c("LEFT_ASSIGN", "<-")
-      call[call$token == "SYMBOL_FUNCTION_CALL" & call$text == "`->>`", c("token", "text")] <- c("RIGHT_ASSIGN", "->")
-      call[call$token == "SYMBOL_FUNCTION_CALL" & call$text == "`=`", c("token", "text")] <- c("LEFT_ASSIGN", "<-")
-      call
-    }
+  checkmate::assert_list(calls)
+  lapply(calls, function(call) {
+    sym_fun <- call$token == "SYMBOL_FUNCTION_CALL"
+    call[sym_fun, ] <- sub_arrows(call[sym_fun, ])
+    call
+  })
+}
+
+#' Execution of assignment operator substitutions for a call.
+#' @keywords internal
+#' @noRd
+sub_arrows <- function(call) {
+  checkmate::assert_data_frame(call)
+  map <- data.frame(
+    row.names = c("`<-`", "`<<-`", "`=`"),
+    token = rep("LEFT_ASSIGN", 3),
+    text = rep("<-", 3)
   )
+  sub_ids <- call$text %in% rownames(map)
+  call[sub_ids, c("token", "text")] <- map[call$text[sub_ids], ]
+  call
 }
 
 # code_graph ----
@@ -193,7 +203,7 @@ code_graph <- function(calls_pd) {
 
   side_effects <- extract_side_effects(calls_pd)
 
-  mapply(function(x, y) unique(c(x, y)), side_effects, cooccurrence, SIMPLIFY = FALSE)
+  mapply(c, side_effects, cooccurrence, SIMPLIFY = FALSE)
 }
 
 #' Extract object occurrence
@@ -226,6 +236,13 @@ extract_occurrence <- function(calls_pd) {
       rep(FALSE, nrow(x))
     }
   }
+  in_parenthesis <- function(x) {
+    if (any(x$token %in% c("LBB", "'['"))) {
+      id_start <- min(x$id[x$token %in% c("LBB", "'['")])
+      id_end <- min(x$id[x$token == "']'"])
+      x$text[x$token == "SYMBOL" & x$id > id_start & x$id < id_end]
+    }
+  }
   lapply(
     calls_pd,
     function(call_pd) {
@@ -298,7 +315,14 @@ extract_occurrence <- function(calls_pd) {
         sym_cond <- rev(sym_cond)
       }
 
-      append(unique(x[sym_cond, "text"]), "<-", after = 1)
+      after <- match(min(x$id[ass_cond]), sort(x$id[c(min(ass_cond), sym_cond)])) - 1
+      ans <- append(x[sym_cond, "text"], "<-", after = max(1, after))
+      roll <- in_parenthesis(call_pd)
+      if (length(roll)) {
+        c(setdiff(ans, roll), roll)
+      } else {
+        ans
+      }
 
       ### NOTE 2: What if there are 2 assignments: e.g. a <- b -> c.
       ### NOTE 1: For cases like 'eval(expression(b <- b + 2))' removes 'eval(expression('.

README.md

@@ -27,7 +27,7 @@
 This package is used to create the data needed for `teal` applications. This data can be:
 
 - Independent data frames
-- `CDISC` data (for clinical trial reporting)
+- CDISC data (for clinical trial reporting)
 - Relational data
 - `MultiAssayExperiment` objects
 

inst/WORDLIST

@@ -1,3 +1,5 @@
+ADaM
+CDISC
 Forkers
 Getter
 Hoffmann