3

I am developing an R package called VSHunter and need NMF package as a dependency, however, every time load NMF will throw many message, I don't know how to suppress them.

> devtools::load_all(".")
Loading VSHunter
Loading required package: NMF
Loading required package: pkgmaker
Loading required package: registry

Attaching package: ‘pkgmaker’

The following object is masked from ‘package:base’:

    isFALSE

Loading required package: rngtools
Loading required package: cluster
NMF - BioConductor layer [OK] | Shared memory capabilities [NO: 
bigmemory] | Cores 7/8
  To enable shared memory capabilities, try: install.extras('
NMF
')

I don't want to bother user and expect the result

> devtools::load_all(".")
Loading VSHunter

and

> library(VSHunter)
Loading VSHunter
Shixiang Wang
  • 2,147
  • 2
  • 24
  • 33
  • 2
    Have you tried `devtools::load_all(..., quiet=TRUE)`? – r2evans Dec 27 '18 at 07:41
  • This seems like a strange question to me. Isn't `load_all()` a development helper that loads all of the functions into the working environment to facilitate development and debugging? As @r2evans suggested you can suppress, but why would you want to hide useful information from yourself during development? – trosendal Dec 27 '18 at 08:19
  • @trosendal, I can commiserate. I have a package that is (1) formal and big enough that it must be a package, but (2) not something I can push to CRAN, and (3) I don't have enough of these packages (yet) to justify making my own mini-repository of packages. So often, I have a few packages to load like this, and yet since I do this on a regular (weekly) basis, I don't want to be bothered by "stuff" on the console. – r2evans Dec 27 '18 at 08:26
  • I forgot to add: frequent-enough changes that preclude `devtools::install` and `install.packages`. – r2evans Dec 27 '18 at 08:27
  • @r2evans Thanks. But how to make user will also not accept so many messages? – Shixiang Wang Dec 27 '18 at 09:46

1 Answers1

5

Here are some things you can do to reduce the noise when loading packages with devtools::load_all:

  • devtools::load_all(..., quiet = TRUE) handles messages for this single package, but not necessarily dependent packages

  • try explicitly loading required packages in ./R/zzz.R in the onLoad function. For example:

    .onLoad <- function(libname, pkgname) {
  invisible(suppressPackageStartupMessages(
    sapply(c("tibble", "purrr", "dplyr", "tidyr", "ggplot2", "data.table"),
           requireNamespace, quietly = TRUE)
  ))
}

    (BTW: I used sapply here for laziness, not that it adds much to things. It could easily have been a for loop with no consequence.)

    For a discussion about the use of requireNamespace in place of library, see "library vs require", and "Writing R Extensions" where it states

    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.

    What we are doing is technically not required, but I think by forcing doing it this way, it is encouraging more-silent operation. (This rides on the coat-tails of

    Notice that I used suppressPackageStartupMessages. "Courteous" package maintainers use packageStartupMessage instead of message for their loading messages: the latter takes a bit more work and is much less discriminant than the former, which is very easily suppressed without unintended consequences. There are many packages that do not do this, for which I think it's fair to submit a PR to fix.

    Another comment about requireNamespace: this means that the functions in those packages will not be in the search path of the R sessions. If the user will always be using certain packages (e.g., data.table or dplyr), then you might want to explicitly load them with library. From "Writing R Extensions" again:

    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.

    However, if you're being good about your package, then you are using :: notation for all non-base packages anyway. There are certainly ways you can get around using ::, but (1) CRAN checks are rather intense at times, (2) explicit is usually "A Good Thing (tm)", and (3) it can actually make maintainability much easier (such as when a dependent package changes their API/ABI and you need to check all calls to their package, where searching for pkgname:: is much easier than searching for each of their functions individually).

  • Some packages use .onLoad too liberally, doing things that are not strictly necessary and/or have unneeded side-effect. For this, you can always write a function such as load_deppkgs_silently(updatesearchpath=TRUE) that can be called manually or on-load with the presence of an option. (I'm thinking about your end users here, I'm a big fan of providing flexibility and the ability to not load things they way I do.)

r2evans
  • 141,215
  • 6
  • 77
  • 149