问题
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
回答1:
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 packagestry explicitly loading required packages in
./R/zzz.Rin theonLoadfunction. For example:.onLoad <- function(libname, pkgname) { invisible(suppressPackageStartupMessages( sapply(c("tibble", "purrr", "dplyr", "tidyr", "ggplot2", "data.table"), requireNamespace, quietly = TRUE) )) }(BTW: I used
sapplyhere for laziness, not that it adds much to things. It could easily have been aforloop with no consequence.)For a discussion about the use of
requireNamespacein place oflibrary, see "library vs require", and "Writing R Extensions" where it statesR 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 usepackageStartupMessageinstead ofmessagefor 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.tableordplyr), then you might want to explicitly load them withlibrary. 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 forpkgname::is much easier than searching for each of their functions individually).Some packages use
.onLoadtoo liberally, doing things that are not strictly necessary and/or have unneeded side-effect. For this, you can always write a function such asload_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.)
来源:https://stackoverflow.com/questions/53941218/r-package-development-how-to-suppress-messages-generated-from-dependency-package