Suggest: add Remotes/Additional_repositories for non-CRAN deps so consuming packages can resolve datelife on CI

[itchyshin]

Background

I'm building prepR4pcm, an R
package that wraps datelife::datelife_search() and
datelife::datelife_use() as backends for retrieving and dating
species lists. datelife is in our Suggests: field with
Remotes: phylotastic/datelife (since the package was archived from
CRAN in 2024-08).

What's happening

When we run R-CMD-check on GitHub Actions, the
r-lib/actions/setup-r-dependencies@v2 step fails at the pak
resolver. The chain pak reports:

* deps::.: Can't install dependency phylotastic/datelife
* phylotastic/datelife: Can't install dependency bold
* bold: Can't find package called bold.

bold is a regular CRAN package
(https://cran.r-project.org/package=bold), so this is unexpected.
The same pattern likely affects:

• The Bioconductor packages Biostrings and msa in your
  Suggests: (pak's CRAN/RSPM resolver doesn't auto-fall-through
  to Bioconductor)
• phylocomr (CRAN; should resolve)

The local install (R CMD INSTALL, pak::pkg_install("phylotastic/datelife"))
works fine on a typical research machine where these deps are already
installed. The issue is purely on CI runners where pak builds the
dep tree from scratch.

What would fix it for downstream packages

Adding a Remotes: and/or Additional_repositories: block to
datelife's DESCRIPTION so pak's resolver finds the non-CRAN deps
without intervention from each downstream consumer. Concretely:

Additional_repositories:
    https://bioc.r-universe.dev,
    https://ropensci.r-universe.dev

Remotes:
    bioc::Biostrings,
    bioc::msa

(or similar — happy to test variants). The same fix landed upstream
in daijiang/rtrees for their megatrees transitive dep
(daijiang/rtrees#10)
and unblocked downstream packages without forcing each consumer to
copy the Remotes.

What we're doing in the meantime

prepR4pcm accepts the CI red badge for the Suggests-resolution
step; local checks pass cleanly (0 / 0 / 0 on
R CMD check --as-cran). When a user actually calls
pr_get_tree(source = "datelife") we have a clear requireNamespace
guard with the install hint
(pak::pak("phylotastic/datelife")).

Happy to test any candidate fix on our CI if useful.

Thanks for maintaining datelife — it's the backbone of our chronogram
backend in prepR4pcm and the prepR4pcm → pigauto pipeline for
multi-tree PCMs.