R package CRAN note for package dependencies and warnings in tests

Question

I'm planning to submit my first package to CRAN. I've heard that you should not have any errors, warnings or notes. However, I get the Note stating that there are too many package dependencies:

"Imports includes 24 non-default packages. Importing from so many packages makes the package vulnerable to any of them becoming unavailable. Move as many as possible to Suggests and use conditionally."

1. Is this note something I have to address in regard to a CRAN submission?
2. Does it make a difference to state that all/most packages used is OK to be included because they are well-maintained?
3. Is it possible to use tidyverse as a dependency instead of each individual package (I understand that this to some extent defeats the purpose with the limit; although having a 20-package-limit feels rather arbitrary anyway and the focus should also be on using well-maintained packages).

Warnings in tests

I have created test cases for the package; however, in order to keep the size limit I need to get use fewer cases than normally used; and this creates different warnings when running the test. Is this OK to have these test related warnings when submitting CRAN?

Thanks in advance! John

Leoraleos

It might be useful to provide a link to the source repo – Codding

Answer 1

In most cases, "Notes" won't automatically cause a reviewer to reject your submission, assuming you otherwise passed R CMD CHECK --as-cran [yourpackage] . In this case, I would take the advice to heart.
First, decide if you really, truly need all those imports at all , let alone as imports. That does seem like a very large collection. Make sure you can't, for example, call some functions in referenced packages A, B, C, and D rather than similar functions in packages K, Q, and T (listing your references from A to X). If you're only using one standalone function from a package, i.e. a function which doesn't depend on any other item in that package, copy the source code from there, with attribution, into your package's source directory.

Second, Only import them if they're needed for your functions to be able to execute regardless of their argument lists. Packages which only support specific "modes" or options should be moved to Suggests .

The relevant portion of the document "R_exts" , which I hope you've read, is quoted below.

All packages that are needed7 to successfully run R CMD check on the package must be listed in one of ‘Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or tests conditionally (e.g. via if(require(pkgname))) should be listed in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all the packages needed for a complete check are installed.) In particular, packages providing “only” data for examples or vignettes should be listed in ‘Suggests’ rather than ‘Depends’ in order to make lean installations possible. Version dependencies in the ‘Depends’ and ‘Imports’ fields are used by library when it loads the package, and install.packages checks versions for the ‘Depends’, ‘Imports’ and (for dependencies = TRUE) ‘Suggests’ fields. It is increasingly important that the information in these fields is complete and accurate: it is for example used to compute which packages depend on an updated package and which packages can safely be installed in parallel. This scheme was developed before all packages had namespaces (R 2.14.0 in October 2011), and good practice changed once that was in place. Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available. Almost always packages mentioned in ‘Depends’ should also be imported from in the NAMESPACE file: this ensures that any needed parts of those packages are available when some other package imports the current package. The ‘Imports’ field should not contain packages which are not imported from (via the NAMESPACE file or :: or ::: operators), as all the packages listed in that field need to be installed for the current package to be installed. (This is checked by R CMD check.) R code in the package should call library or require only exceptionally. Such calls are never needed for packages listed in ‘Depends’ as they will already be on the search path. It used to be common practice to use require calls for packages listed in ‘suggests’ in functions which used their functionality, but nowadays it is better to access such functionality via :: calls.

Kenward

Thanks! First, how/where do you give attribution when "copy[ing] the source code"; also, doesn't this "unfairly take" downloads counts from that package that you copy source code from? Second, "Packages which only support specific "modes" or options should be moved to Suggests"; does this depend on which the default settings in your function are? For example, can you have the default setting being to use multiple cores but still have the needed packages for this in options in suggests since you can set the setting to FALSE and not use the multiple cores. Thanks! – Leoraleos

Nobody gives a [bleep] about download counts. For attribution, start with citation() . I would recommend putting a complete citation into the 'References" section of applicable man pages as well as in the "[packagename].Rd" page . I'm not sure whether the defaults should affect placing packages into "Suggests," sorry about that – Kenward

I would only copy, with attribution, very small functions that don't depend on any other functions in the package and that are necessary for your package. Otherwise put the package in Suggests and use the function conditionally, after checking that the package you depend on is installed using requireNamespace(package, ..., quietly = TRUE). Or Import the function(s) from the package, if they're almost always necessary for your package. It is not best practice to import the entire package. – Erysipelas