Library/Package Development - Message When Loading

Library/package development - message when loading

Yes. You can use the .onLoad, .onAttach, or .First.lib functions to do whatever you want when the package is loaded. I suggest looking at the help for those functions. You would use .onLoad with a namespace, and .First.lib without.

One convention is that people will frequently put these commands in a separate zzz.R file, which is just used for package related code.

R package development how to suppress messages generated from dependency package?

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

Suppress package loading messages

Not sure if anyone is still looking for an answer to this one but

suppressWarnings(suppressMessages(library("dplyr")))

works perfectly on Jupyter Notebooks. I typically define a function like this:

import_library = function(lib_name){
    suppressWarnings(suppressMessages(require(lib_name, character.only = TRUE)))
}
import_library('dplyr')

Note that, inside the user-defined function, library(...) will not work, so use require(...). The character.only = TRUE is also necessary to circumvent R from trying to load lib_name as name of library, rather than actual library (in our case dplyr).

A similar answer can be found here.

Package Imports not loading in R development package

That's the correct behaviour. Imports just means that code inside your package can see the functions that you import from other packages. The other packages aren't placed on the search path like with Depends.

Further reading:

Better explanation of when to use Imports/Depends

Suppress start-up messages when loading a library to snowfall cluster with sfLibrary

Use the Source.

If you look at the source code for sfLibrary, specifically where it prints those messages, you'll see that is uses sfCat. Tracing that down (same file), it uses cat.

I know of two ways to prevent cat from dumping onto the console: capture.output and sink.

1. capture.output: "evaluates its arguments with the output being returned as a character string or sent to a file".

   cat("quux4\n")
   # quux4
   invisible(capture.output(cat("quux5\n")))
   cat("quux6\n")
   # quux6
   

   Since capture.output returns the captured output visibly as a character vector, wrapping it in invisible or storing the return value into a variable (that is ignored and/or removed) will prevent its output on the console.

2. sink: "send R output to a file".

   cat("quux1\n")
   # quux1
   sink("ignore_me.txt")
   cat("quux2\n")
   sink(NULL) # remove the sink
   cat("quux3\n")
   # quux3
   

I personally find the use of sink (in general) to be with some risks, especially in automation. One good example is that knitr uses sink when capturing the output for code chunks; nested calls to sink have issues. An astute reader will notice that capture.output uses sink, so neither is better in that regard.

Looking again at the source (first link above),

else {
  ## Load message in slave logs.
  sfCat( paste( "Library", .sfPars$package, "loaded.\n" ) )

  ## Message in masterlog.
  message( paste( "Library", .sfPars$package, "loaded in cluster.\n" ) )
}

you'll see that it also calls message, which is not caught by capture.output by default. You can always use capture.output(..., type="message"), but then you aren't capturing the cat output as well. So you are left with having to capture both types, either with nested capture.output or with suppressMessages.

I suggest you can either use suppressMessages(invisible(capture.output(sfLibrary(raster)))) or write some helper function that does that for you.

Package Loading Problems

One solution is to update htmltools then load equatiomatic, e.g.

# restart or start a new session to 'unload' all libraries

# install htmltools
install.packages("htmltools")

# load equatiomatic
library(equatiomatic)

How to avoid printing a package's author message?

For data.table, this was done in commit 233 (2011.06.11 01:04:27) :

"onAttach now uses packageStartupMessage so the banner can be suppressed by those annoyed by banners, whilst still being helpful to new users"

This is in v1.6.1 available from R-Forge, and may be released to CRAN soon.

I'll add a note to NEWS ...

---

Related Topics