Helper function to determine if a package can be added for free?

[njtierney]

Hello! I really love this package, so firstly thanks for making something that brings me a little joy every day.

So, I recently used the neat dependency checkers in pak to determine if a dependency could be added for free, which was really handy, and I was wondering if something like this might be useful for other users of pak?

Here's a little demo for geotargets to help us determine if we could add withr or fs for free:

# on master/main branch
can_we_add_a_dep_for_free <- function(deps){
    
    local_deps <- pak::pkg_deps(".")
    
    are_deps_already_free <- deps %in% local_deps$ref
    
    names(are_deps_already_free) <- deps
    
    if (are_deps_already_free) {
        cli::cli_inform(
            message = c(
                "{.pkg {deps}} can be added for free:",
                "Explanation:")
        )
        print(pak::local_deps_explain(deps = deps))
    }
    
    if (!are_deps_already_free){
        cli::cli_inform(
            message = c(
                "{.pkg {deps}} can not be added for free :("
            )
        )
    }
    
}

can_we_add_a_dep_for_free("withr")
#> ℹ Loading metadata database
#> ✔ Loading metadata database ... done
#> 
#> withr can be added for free:
#> Explanation:
#> geotargets -> targets -> tidyselect -> withr
can_we_add_a_dep_for_free("fs")
#> fs can not be added for free :(

^{Created on 2024-10-28 with reprex v2.1.1}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.1 Patched (2024-07-08 r86915)
#>  os       macOS Sonoma 14.5
#>  system   aarch64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       Australia/Perth
#>  date     2024-10-28
#>  pandoc   3.2 @ /Applications/RStudio.app/Contents/Resources/app/quarto/bin/tools/aarch64/ (via rmarkdown)
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.3   2024-06-21 [1] CRAN (R 4.4.0)
#>  digest        0.6.36  2024-06-23 [1] CRAN (R 4.4.0)
#>  evaluate      0.24.0  2024-06-10 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  htmltools     0.5.8.1 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.48    2024-07-07 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  pak           0.7.2   2024-03-17 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  reprex        2.1.1   2024-07-06 [1] CRAN (R 4.4.0)
#>  rlang         1.1.4   2024-06-04 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.1   2024-07-31 [1] CRAN (R 4.4.0)
#>  xfun          0.46    2024-07-18 [1] CRAN (R 4.4.0)
#>  yaml          2.3.10  2024-07-26 [1] CRAN (R 4.4.0)
#> 
#>  [1] /Users/nick/Library/R/arm64/4.4/library
#>  [2] /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[gaborcsardi]

Thanks! I agree that that's handy, but it does seem a bit specialized, and (well, apart from the nice UI that you added) it is essentially a one-liner:

❯ c("callr", "fs", "igraph") %in%  pak::pkg_deps(".")$package
[1]  TRUE FALSE FALSE

(Btw. you need to use package, not ref, ref might be a reference, e.g. github::r-lib/fs, in which case the results can be incorrect.)

Even if we don't add it as a function, it would be really nice to add this tip somewhere, maybe the FAQ, or maybe elsewhere, so please allow me to keep this issue open for a bit.

[njtierney]

Thanks, @gaborcsardi ! I should have read the documentation a bit closer on what the columns returned meant 😅

I think I also had an extra step in my function to name the output, which might not have been needed, but I can't remember what my plan was there.

Yeah it would be great to have something like this in an FAQ - this was inspired by the itdepends talk/pkg from @jimhester https://www.tidyverse.org/blog/2019/05/itdepends/#assist-removal-with-itdependsdep_locate

[gaborcsardi]

Yes, I agree that the names output is a nice touch.