tar_map() does not interpret <integer64> values correctly

[psychelzh]

Prework

• Read and agree to the code of conduct and contributing guidelines.
• Confirm that your issue is a genuine bug in tarchetypes and not a known limitation, usage error, or issue from another package that tarchetypes depends on. If you are unsure, please submit a discussion thread instead.
• If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.
• Post a minimal reproducible example like this one so the maintainer can troubleshoot the problems you identify. A reproducible example is:
  • Runnable: post enough R code and data so any onlooker can create the error on their own computer.
  • Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
  • Readable: format your code according to the tidyverse style guide.

Description

When converting an class value, tar_map() does not handle correctly. See the reprex

Reproducible example

• Post a minimal reproducible example like this one so the maintainer can troubleshoot the problems you identify. A reproducible example is:
  • Runnable: post enough R code and data so any onlooker can create the error on their own computer.
  • Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
  • Readable: format your code according to the tidyverse style guide.

withr::local_package("targets")
tar_dir({ # tar_dir() runs code from a temporary directory.
    tar_script({
        tarchetypes::tar_map(
            values = data.frame(game_id = bit64::as.integer64(1)),
            list(
                tar_target(
                    name,
                    game_id
                )
            )
        )
    }, ask = FALSE)
    tar_manifest()
})
#> # A tibble: 1 × 3
#>   name                       command               pattern
#>   <chr>                      <chr>                 <chr>  
#> 1 name_4.94065645841247e.324 4.94065645841247e-324 <NA>

This is correct value

bit64::as.integer64(1) |>
    as.character()
#> [1] "1"

^{Created on 2022-05-19 by the reprex package (v2.0.1)}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.2.0 (2022-04-22 ucrt)
#>  os       Windows 10 x64 (build 22000)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language en
#>  collate  Chinese (Simplified)_China.utf8
#>  ctype    Chinese (Simplified)_China.utf8
#>  tz       Asia/Taipei
#>  date     2022-05-19
#>  pandoc   2.17.1.1 @ C:/Program Files/RStudio/bin/quarto/bin/ (via rmarkdown)
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  backports     1.4.1   2021-12-13 [1] CRAN (R 4.2.0)
#>  base64url     1.4     2018-05-14 [1] CRAN (R 4.2.0)
#>  bit           4.0.4   2020-08-04 [1] CRAN (R 4.2.0)
#>  bit64         4.0.5   2020-08-30 [1] CRAN (R 4.2.0)
#>  callr         3.7.0   2021-04-20 [1] CRAN (R 4.2.0)
#>  cli           3.3.0   2022-04-25 [1] CRAN (R 4.2.0)
#>  codetools     0.2-18  2020-11-04 [2] CRAN (R 4.2.0)
#>  crayon        1.5.1   2022-03-26 [1] CRAN (R 4.2.0)
#>  data.table    1.14.2  2021-09-27 [1] CRAN (R 4.2.0)
#>  digest        0.6.29  2021-12-01 [1] CRAN (R 4.2.0)
#>  ellipsis      0.3.2   2021-04-29 [1] CRAN (R 4.2.0)
#>  evaluate      0.15    2022-02-18 [1] CRAN (R 4.2.0)
#>  fansi         1.0.3   2022-03-24 [1] CRAN (R 4.2.0)
#>  fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.2.0)
#>  fs            1.5.2   2021-12-08 [1] CRAN (R 4.2.0)
#>  glue          1.6.2   2022-02-24 [1] CRAN (R 4.2.0)
#>  highr         0.9     2021-04-16 [1] CRAN (R 4.2.0)
#>  htmltools     0.5.2   2021-08-25 [1] CRAN (R 4.2.0)
#>  igraph        1.3.1   2022-04-20 [1] CRAN (R 4.2.0)
#>  knitr         1.39    2022-04-26 [1] CRAN (R 4.2.0)
#>  lifecycle     1.0.1   2021-09-24 [1] CRAN (R 4.2.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.2.0)
#>  pillar        1.7.0   2022-02-01 [1] CRAN (R 4.2.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.2.0)
#>  processx      3.5.3   2022-03-25 [1] CRAN (R 4.2.0)
#>  ps            1.7.0   2022-04-23 [1] CRAN (R 4.2.0)
#>  purrr         0.3.4   2020-04-17 [1] CRAN (R 4.2.0)
#>  R.cache       0.15.0  2021-04-30 [1] CRAN (R 4.2.0)
#>  R.methodsS3   1.8.1   2020-08-26 [1] CRAN (R 4.2.0)
#>  R.oo          1.24.0  2020-08-26 [1] CRAN (R 4.2.0)
#>  R.utils       2.11.0  2021-09-26 [1] CRAN (R 4.2.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.2.0)
#>  reprex        2.0.1   2021-08-05 [1] CRAN (R 4.2.0)
#>  rlang         1.0.2   2022-03-04 [1] CRAN (R 4.2.0)
#>  rmarkdown     2.14    2022-04-25 [1] CRAN (R 4.2.0)
#>  rstudioapi    0.13    2020-11-12 [1] CRAN (R 4.2.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.2.0)
#>  stringi       1.7.6   2021-11-29 [1] CRAN (R 4.2.0)
#>  stringr       1.4.0   2019-02-10 [1] CRAN (R 4.2.0)
#>  styler        1.7.0   2022-03-13 [1] CRAN (R 4.2.0)
#>  targets     * 0.12.0  2022-04-19 [1] CRAN (R 4.2.0)
#>  tibble        3.1.7   2022-05-03 [1] CRAN (R 4.2.0)
#>  tidyselect    1.1.2   2022-02-21 [1] CRAN (R 4.2.0)
#>  utf8          1.2.2   2021-07-24 [1] CRAN (R 4.2.0)
#>  vctrs         0.4.1   2022-04-13 [1] CRAN (R 4.2.0)
#>  withr         2.5.0   2022-03-03 [1] CRAN (R 4.2.0)
#>  xfun          0.31    2022-05-10 [1] CRAN (R 4.2.0)
#>  yaml          2.3.5   2022-02-21 [1] CRAN (R 4.2.0)
#> 
#>  [1] C:/Users/liang/AppData/Local/R/win-library/4.2
#>  [2] C:/Program Files/R/R-4.2.0/library
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[psychelzh]

Or is this by design? If so, is there any workaround other than converting it to character manually beforehand?

[wlandau]

This edge case happens because tar_map() uses targets::tar_deparse_safe() to sanitize what you supply to values in tar_map(). This is a special wrapper around deparse() which effectively sets the control argument to c("keepNA", "keepInteger"). This causes a different set of behaviors than the default deparse() which makes tracking R code for changes more robust in response to user code and less likely to break across different versions of R. That changes how the 64-bit integer class is deparsed.

deparse(bit64::as.integer64(1))
#> [1] "structure(4.94065645841247e-324, class = \"integer64\")"
deparse(bit64::as.integer64(1), control = c("keepNA", "keepInteger"))
#> [1] "4.94065645841247e-324"

Nothing in metaprogramming works for every edge case, which is why the tar_map() help file cautions against passing complicated objects into values.

tarchetypes/R/tar_map.R

Lines 32 to 38 in 507d06b

	#' in place of those symbols. Elements of the `values` list
	#' should be small objects that can easily deparse to names,
	#' such as characters, integers, and symbols.
	#' For more complicated elements of `values`, such as
	#' lists with multiple numeric vectors,
	#' `tar_map()` attempts to parse the elements into expressions,
	#' but this process is not perfect, and the default

tar_meta() tries to create runnable code, so it is best to supply simple objects that can be easily inserted into R expressions without issue.

[psychelzh]

Thanks for explaining.