This vignette is written for concerned package maintainers or users that want to check their package in relationship with other packages. For general usage of the other functions check the manual or package index (a vignette might come too).
Keeping up with the repositories
Packages required by a package might have their own dependencies with minimal versions requirements. The maintainers or developers might wonder what is the oldest version of each recursive package their users are required to have. This is useful for developing packages that should remain compatible with old versions of R and packages.
pd <- package_dependencies("ggeasy")
head(pd)
#> Name Version Type Op Package
#> 1 cli 3.4.0 Imports >= <NA>
#> 2 lifecycle 1.0.3 Imports >= <NA>
#> 3 R 4.4.0 Depends >= <NA>
#> 4 rlang 1.1.0 Imports >= <NA>
#> 5 vctrs 0.6.0 Imports >= <NA>
#> 6 utils <NA> <NA> <NA> <NA>
package_dependencies()
identify the minimal version
required for each dependency. If no version is required by any
dependencies NA
is used.
We can identify packages that are required on a lower version than one of the dependencies with
# Discover the requirements that can be upgraded
update_dependencies("ggeasy")
#> Name Version
#> 1 R 4.4.0
Increasing these version requirements on ggeasy won’t affect users as they already should have these versions installed as required by other dependencies.
We can also be interested on since when can users install a package. There can be two possible answers: - Since it was published/release on the repositories - If the maintainer developers are careful the requirements might be available earlier.
We can use package_date()
to get those answers:
package_date("ggeasy")
#> Published deps_available
#> "2025-06-15 04:40:04 UTC" "2021-05-18 07:05:22 UTC"
Why are they important? The first one is important to know if it hasn’t been updated in a long time. The second one helps estimate if it can be installed on old systems without updating anything else. If the date the dependencies are available is closer to the published date, the users will need to have updated systems and dependencies.
Improving packages
Help pages are found via alias, when a user press ?word
it searches for alias. Checking for existing alias might help you to
find packages and reduce the confusion on the help pages.
alias <- cran_alias(c("fect", "gsynth"))
#> Retrieving cran_aliases, this might take a bit.
#> Caching results to be faster next call in this session.
dup_alias <- duplicated_alias(alias)
head(dup_alias)
#> Target Package Source
#> 1 _gsynth_beta_iter fect fect-internal.Rd
#> 2 _gsynth_beta_iter gsynth gsynth-internal.Rd
#> 3 _gsynth_data_ub_adj fect fect-internal.Rd
#> 4 _gsynth_data_ub_adj gsynth gsynth-internal.Rd
#> 5 _gsynth_fe_ad_covar_iter fect fect-internal.Rd
#> 6 _gsynth_fe_ad_covar_iter gsynth gsynth-internal.Rd
For example these two packages have the same alias for the internal functions but most of them point to the same file.
Connecting help pages
Often it is helpful to link help pages so that: - Pages are linked to other pages - Pages are linked from other pages.
pkg <- "BaseSet"
head(cran_help_pages_wo_links(pkg))
#> Retrieving base_aliases, this might take a bit.
#> Caching results to be faster next call in this session.
#> Warning in cran_alias(cran_pkgs): Omitting packages bartMachineJARs, clean, fontBitstreamVera, fontLiberation, GreedyExperimentalDesignJARs, hse, LifeInsuranceContracts, openNLPdata, positron.tutorials, RKEAjars, RMOAjars, ROI.plugin.cplex, ROI.plugin.glpk, ROI.plugin.ipop, ROI.plugin.symphony, rsparkling, RWekajars, Sejong.
#> Maybe they are currently not on CRAN?
#> Warning: Packages 'geneHapR', 'Hmisc', 'sfsmisc' have targets not present in a
#> OS.
#> Retrieving cran_rdxrefs, this might take a bit.
#> Caching results to be faster next call in this session.
#> Warning in cran_links(cran_pkgs): Omitting packages bartMachineJARs, clean, fontBitstreamVera, fontLiberation, GreedyExperimentalDesignJARs, hse, LifeInsuranceContracts, openNLPdata, positron.tutorials, RKEAjars, RMOAjars, ROI.plugin.cplex, ROI.plugin.glpk, ROI.plugin.ipop, ROI.plugin.symphony, rsparkling, RWekajars, Sejong.
#> Maybe they are currently not on CRAN?
#> Warning: Some pages point to different places according to the OS.
#> Warning: Some links are distinct depending on the OS.
#> Package Source
#> 1 BaseSet activate.Rd
#> 2 BaseSet add_column.Rd
#> 3 BaseSet add_elements.Rd
#> 4 BaseSet add_relation.Rd
#> 5 BaseSet add_relations.Rd
#> 6 BaseSet add_sets.Rd
head(cran_help_pages_not_linked(pkg))
#> Package Source
#> 1 BaseSet activate.Rd
#> 2 BaseSet add_column.Rd
#> 3 BaseSet add_elements.Rd
#> 4 BaseSet add_relation.Rd
#> 5 BaseSet add_relations.Rd
#> 6 BaseSet add_sets.Rd
In addition to those help pages that are not well connected it could be that some pages are linked but link to each other without connecting with other help pages of the package or other packages.
cliques <- cran_help_cliques(pkg)
#> Warning in cran_targets_links(pkges): Omitting packages BaseSet, dplyr, methods, rlang, utils, cli, generics, glue, lifecycle, magrittr, pillar, R6, tibble, tidyselect, vctrs, utf8, pkgconfig, withr, graphics, grDevices.
#> Maybe they are currently not on CRAN?
table(cliques$n) # Number of help pages connected
#> < table of extent 0 >
If there is more than one length this would mean some pages not linked to the rest of the package.
Sometimes even if links exists they might not resolve correctly on the html version. For example if they link to a help page of a package that is not on the strong dependency list.
cran_help_pages_links_wo_deps(pkg)
#> [1] Package Source Anchor Target
#> <0 rows> (or 0-length row.names)
If there is some output then the link cannot be resolved correctly if the other package is not independently installed on the same machine.
Reproducibility
If you wish to know what packages were available on CRAN on any given date you can use:
cs <- cran_snapshot(as.Date("2020-01-31"))
#> Warning: There are 4 packages both archived and published
#> This indicate manual CRAN intervention.
#> Retrieving comments, this might take a bit.
#> Caching results to be faster next call in this session.
nrow(cs)
#> [1] 101405
This might be helpful to know what was available on old project and why some feature of a given package wasn’t used. Maybe it wasn’t available on a given date!
Local versions
While working it might be good to update packages. To decide if it is needed maybe you’d like to know when were packages last updated on the system?
cran_session()
#> Warning in cran_archive(versions[, "Package"]): Omitting packages repo.data.
#> Maybe they were not on CRAN?
#> [1] "2025-08-27 16:40:06 CEST"
This uses the sessionInfo()
output to find the date of
last installation. Under the hood it uses a function for an arbitrary
packages and their versions:
versions <- data.frame(Package = c("dplyr", "Rcpp", "rlang"),
Version = c("1.1.4", "0.8.9", NA))
cran_date(versions)
#> [1] "2023-11-17 16:50:03 CET"
This is the first date were these packages were at the requested
version number (or available). Currently these packages can have a
release with higher version numbers (this can be easily checked with
old.packages()
).
To answer the original question of this section we can use:
ip <- cran_date(installed.packages())
#> Warning in cran_archive(versions[, "Package"]): Omitting packages repo.data.
#> Maybe they were not on CRAN?
ip
#> [1] "2025-08-27 16:40:06 CEST"
Risk of being archived
If you ever wonder which packages are at risk of being archived you
can use cran_doom()
:
cd <- cran_doom(bioc = TRUE)
#> Retrieving CRAN_db, this might take a bit.
#> Caching results to be faster next call in this session.
#> Retrieving bioc_available_release, this might take a bit.
#> Caching results to be faster next call in this session.
cd[c("time_till_last", "last_archived", "npackages")]
#> $time_till_last
#> Time difference of 62 days
#>
#> $last_archived
#> [1] "2025-10-31"
#>
#> $npackages
#> CRAN all
#> 22625 26331
knitr::kable(head(cd$details))
Package | Deadline | type | repo | n_affected |
---|---|---|---|---|
xportr | 2025-08-25 | direct | CRAN | 6 |
duckplyr | 2025-08-25 | direct | CRAN | 2 |
CopSens | 2025-09-01 | direct | CRAN | 11 |
SPARSEMODr | 2025-09-01 | direct | CRAN | 11 |
NIMAA | 2025-09-01 | direct | CRAN | 8 |
tidyrgee | 2025-09-01 | direct | CRAN | 8 |
There are website dedicated to track those and provide information about new version submissions to CRAN to fix those. I participate on the cranhaven.org dashboard (and project).
Note that if a package is archived it can be brought back to the repository.
Reproducibility
For reproducibility here is the session info:
sessionInfo()
#> R Under development (unstable) (2025-08-29 r88740)
#> Platform: x86_64-pc-linux-gnu
#> Running under: Ubuntu 24.04.3 LTS
#>
#> Matrix products: default
#> BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
#> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.26.so; LAPACK version 3.12.0
#>
#> locale:
#> [1] LC_CTYPE=C.UTF-8 LC_NUMERIC=C LC_TIME=C.UTF-8
#> [4] LC_COLLATE=C.UTF-8 LC_MONETARY=C.UTF-8 LC_MESSAGES=C.UTF-8
#> [7] LC_PAPER=C.UTF-8 LC_NAME=C LC_ADDRESS=C
#> [10] LC_TELEPHONE=C LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C
#>
#> time zone: UTC
#> tzcode source: system (glibc)
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] repo.data_0.0.0.9004
#>
#> loaded via a namespace (and not attached):
#> [1] cli_3.6.5 knitr_1.50 rlang_1.1.6 xfun_0.53
#> [5] rversions_2.1.2 textshaping_1.0.1 jsonlite_2.0.0 litedown_0.7
#> [9] markdown_2.0 htmltools_0.5.8.1 ragg_1.4.0 sass_0.4.10
#> [13] rmarkdown_2.29 evaluate_1.0.5 jquerylib_0.1.4 fastmap_1.2.0
#> [17] yaml_2.3.10 lifecycle_1.0.4 compiler_4.6.0 igraph_2.1.4
#> [21] fs_1.6.6 pkgconfig_2.0.3 systemfonts_1.2.3 digest_0.6.37
#> [25] R6_2.6.1 curl_7.0.0 magrittr_2.0.3 commonmark_2.0.0
#> [29] bslib_0.9.0 tools_4.6.0 xml2_1.4.0 pkgdown_2.1.3
#> [33] cachem_1.1.0 desc_1.4.3