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."
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
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.