Optional (Suggests) dependency that has been archived on CRAN

Package Development
, ,
1

I was wondering if anyone had any experiences with submitting a package to CRAN that has an optional dependency (i.e. Suggests dependency) that has been archived by CRAN? In this particular case, the package that was archived by CRAN was due to some over-zealous compiler warnings and the package works just fine. I observe that CRAN appears to be happy for packages that have optional dependencies which have been archived to remain on CRAN. Assuming the rules for non-CRAN optional dependencies hold the same for archived package, then I would guess that it would be sufficient to (1) list the optional depency in the Suggests field, and (2) provide URL to download package in the Description field of the package DESCRIPTION? Can anyone confirm if this has worked for them?

For the sake of discussion, please assume (1) this is not an XY problem, (2) no one will take over maintenance of archived package, (3) the original maintainer will/can not submit an update, (3) the source is publicly available on GitHub (i.e., cran/cplexAPI), and (4) there is no other package on CRAN that provides desired functionality (because the Rcplex package is not compatible with recent versions of CPLEX and maintainers are unresponsive). Also, this is not a duplicate of this post (What is best practice when a dependency is removed from CRAN?) because I am asking about resubmitting a package to CRAN with an archived package as an optional dependency—I am not asking about other possible mitigation strategies. Furthermore, although CRAN documentation discusses policies regarding orphaned packages, please note that these are different things and an orphaned package is not the same as an archived package (https://cran.r-project.org/web/packages/policies.pdf).

2

I don’t have experience with this, but I think there are a couple of options.

You could take over the maintenance of the optional package dependency, and get it back to CRAN or other repositories. This would prevent you and your users to run into problems but increase the burden of maintenance (which you don’t seem to want).

If those packages are needed (and only in Suggests because otherwise it wouldn’t build/install in CRAN) then you could set up a drat or universe repository and add to the DESCRIPTION an additional repository via Additional_repositories (and change them to Imports/Depends). However, relying in a package that is not maintained and has known problems might cause that your own users might find that same trouble that got the package out of CRAN.

As an aside, I don’t think that how to install suggested packages should be in the Description field. That field is to explain what does the package, not to provide instructions of installation or usage (in my humble opinion). I think that a vignette/help page explaining how to install those packages might be easier for users to find. This is similar to how currently is done as in examples:

# This function requires package A, 
# please install it with BiocManager::install("A"):
if (requireNamespace("A", quiet = TRUE)) {
    run_package()
}
3

Thanks LluĂ­s! I appreciate you taking the time to describe some alternative options!

Yeah, I didn’t know about the Additional_repositories field - that’s definitely an interesting idea - but seems like it would be a bit more hassle than simply listing the package as a Suggests dependency and providing information on installing it (assuming that this is a valid option).

Although I appreciate your perspectives on the Description field, this does not seem to follow CRAN policies (per CRAN Repository Policy). CRAN policies state the Description field should contain such installation details/URLs for packages that are not on CRAN (relevant text bolded for emphasis): “Packages on which a CRAN package depends should be available from a mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ fields are not from such a repository, where to obtain them at a repository should be specified in an ‘Additional_repositories’ field of the DESCRIPTION file (as a comma-separated list of repository URLs) or for other means of access, described in the ‘Description’ field” . I certainly agree that it is useful to provide such information in the package documentation as well, but would seem inadequate for CRAN publication.

4

Oh, nice catch, about CRAN requirement’s for those packages not in Additional_repositories. There is nothing forbidding describing how to do it in the DESCRIPTION file and on a manual or vignette. Ultimately I think it depends on how savvy your (potential) users.

Setting up an additional repository with r-universe is not that complicated. I haven’t tried with drat but it seems more common on the ~100 packages that use additional repositories (it is also older). I never tested how easy is to install those packages, aka, if missing packages are picked from Additional_repositories or not…

5

Interesting! Yeah, I haven’t looked into r-universe before either - thanks!

6

Just to follow up in case this helps anyone else, it would appear that it’s fine to have archived packages listed as Suggests for CRAN submission - as long as conditions for non-CRAN packages are met (e.g., listing URL for package install in the DESCRIPTION file). For reference, see prioritizr version 7.2.2 (CRAN - Package prioritizr) which has the (currently) archived cplexAPI package listed as an optional dependency (CRAN - Package cplexAPI).

2 Likes