When I load a package, I get a message stating that:
"The following object is masked from 'package:xxx'
For example, if I load testthat
then assertive
, I get the following:
library(testthat) library(assertive) ## Attaching package: ‘assertive’ ## ## The following objects are masked from ‘package:testthat’: ## ## has_names, is_false, is_less_than, is_null, is_true
What does this message mean, and how do I prevent it?
You may sometimes encounter the following message in R: The following objects are masked from 'package:stats': filter, lag. This message appears when you load some package in R that contains functions that share names with functions that are already loaded from some other package in your current environment.
Order of Loading Packages in RIf two packages use the same function name, then the package loaded last will hide the function from earlier packages. This is called masking.
The following object is masked from package:base.
Explanation: The following objects are masked from 'package:base': intersect, setdiff, setequal, union.
The message means that both the packages have functions with the same names. In this particular case, the testthat
and assertive
packages contain five functions with the same name.
R will look through the search
path to find functions, and will use the first one that it finds.
search() ## [1] ".GlobalEnv" "package:assertive" "package:testthat" ## [4] "tools:rstudio" "package:stats" "package:graphics" ## [7] "package:grDevices" "package:utils" "package:datasets" ## [10] "package:methods" "Autoloads" "package:base"
In this case, since assertive
was loaded after testthat
, it appears earlier in the search path, so the functions in that package will be used.
is_true ## function (x, .xname = get_name_in_parent(x)) ## { ## x <- coerce_to(x, "logical", .xname) ## call_and_name(function(x) { ## ok <- x & !is.na(x) ## set_cause(ok, ifelse(is.na(x), "missing", "false")) ## }, x) ## } <bytecode: 0x0000000004fc9f10> <environment: namespace:assertive.base>
The functions in testthat
are not accessible in the usual way; that is, they have been masked.
You can explicitly provide a package name when you call a function, using the double colon operator, ::
. For example:
testthat::is_true ## function () ## { ## function(x) expect_true(x) ## } ## <environment: namespace:testthat>
If you know about the function name clash, and don't want to see it again, you can suppress the message by passing warn.conflicts = FALSE
to library
.
library(testthat) library(assertive, warn.conflicts = FALSE) # No output this time
Alternatively, suppress the message with suppressPackageStartupMessages
:
library(testthat) suppressPackageStartupMessages(library(assertive)) # Also no output
If you have altered some of R's startup configuration options (see ?Startup
) you may experience different function masking behavior than you might expect. The precise order that things happen as laid out in ?Startup
should solve most mysteries.
For example, the documentation there says:
Note that when the site and user profile files are sourced only the base package is loaded, so objects in other packages need to be referred to by e.g. utils::dump.frames or after explicitly loading the package concerned.
Which implies that when 3rd party packages are loaded via files like .Rprofile
you may see functions from those packages masked by those in default packages like stats, rather than the reverse, if you loaded the 3rd party package after R's startup procedure is complete.
First, get a character vector of all the environments on the search path. For convenience, we'll name each element of this vector with its own value.
library(dplyr) envs <- search() %>% setNames(., .)
For each environment, get the exported functions (and other variables).
fns <- lapply(envs, ls)
Turn this into a data frame, for easy use with dplyr.
fns_by_env <- data_frame( env = rep.int(names(fns), lengths(fns)), fn = unlist(fns) )
Find cases where the object appears more than once.
fns_by_env %>% group_by(fn) %>% tally() %>% filter(n > 1) %>% inner_join(fns_by_env)
To test this, try loading some packages with known conflicts (e.g., Hmisc
, AnnotationDbi
).
The conflicted
package throws an error with a helpful error message, whenever you try to use a variable with an ambiguous name.
library(conflicted) library(Hmisc) units ## Error: units found in 2 packages. You must indicate which one you want with :: ## * Hmisc::units ## * base::units
I have the same problem. I avoid it with remove.packages("Package making this confusion")
and it works. In my case, I don't need the second package, so that is not a very good idea.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With