'dplyr::select function clashes with MASS::select
If I load the MASS
package:
library(MASS)
then load try to run dplyr::select
, I get a error:
library(dplyr)
mtcars %.%
select(mpg)
# Error in select(`__prev`, mpg) : unused argument (mpg)
How can I use dplyr::select
with the MASS
package loaded?
Solution 1:[1]
As Pascal said, the following works
require(MASS)
require(dplyr)
mtcars %>%
dplyr::select(mpg)
Solution 2:[2]
This happens to me more frequently than I should admit. dplyr clashes with MASS::select
, plyr::summarise
and stats::filter
among other things, especially when loading packages which load one of those libraries via library (they shouldn't, but some still do) or when you load dplyr in your .Rprofile
(don't!). And it can lead to pretty obscure problems, not always an error message, especially conflicts with plyr
.
I only recently learned about the conflicts()
function. It's useful, but "over-reports" conflicts when two packages have identical functions, e.g. tidyr::%>%
and dplyr::%>%
.
So I wrote a function to tell me if I'm going mad or whether there's actually a conflict causing the current bug. It not only checks for conflicts, it checks whether a certain desired package is the one "on top" and whether the function's bodies actually differ.
It does this for dplyr by default, but you can specify another package using the want_package
parameter. For example, I often get tripped up by recode
and alpha
, which are reused in many packages.
Usage is simply: amigoingmad()
.
By default, it will also automatically "fix" things if dplyr is not "on top", using the following commands:
detach("package:dplyr", character.only = TRUE)
library("dplyr", character.only = TRUE)
Note that the function will report if a user-specified function is blocking dplyr, but does not fix this automatically for safety's sake (just remove the function in that case).
As of yet, this solution hasn't caused any problems to me. Of course I wouldn't advocate using this in production code, but when you're debugging an .Rmd
-file and may have messed up the load order by accident it's a quick way to find out.
If you want this in a package:
devtools::install_github("rubenarslan/rcamisc")
Solution 3:[3]
If you load first the MASS
library and second the dplyr
one
library (MASS)
library (dplyr)
then the first version of the select
function in your session searchpaths ()
will be the one in the dplyr
library.
Hence
select(mtcars, mpg)
will work as
dplyr::select(mtcars, mpg)
Solution 4:[4]
The other solutions listed here may solve your immediate issue but fail in a critical way: they can't tell you about conflicts that are unknown in advance. For example, I just updated some older code and discovered that three packages I was using each have a summarize
command.
The elegant solution is to load the conflicted
package in every session / script because it:
- generates informative error messages whenever namespace conflicts arise
- offers an explicit function
conflict_prefer()
to assign namespace priority - doesn't require the more cumbersome
package::function()
syntax
See example code below partly from https://github.com/r-lib/conflicted
# install package
install.packages("conflicted")
# example of how to start load packages at start of your script
library(dplyr)
library(conflicted)
conflict_prefer("select", "dplyr")
conflict_prefer("filter", "dplyr")
Below, an example as if you ran library(conflicted)
at start but did not specify which package gets priority for filter
:
# WITHOUT conflict_prefer("filter", "dplyr")
# example of informative error message
filter(mtcars, cyl == 8)
#> Error: [conflicted] `filter` found in 2 packages.
#> Either pick the one you want with `::`
#> * dplyr::filter
#> * stats::filter
#> Or declare a preference with `conflicted_prefer()`
#> * conflict_prefer("filter", "dplyr")
#> * conflict_prefer("filter", "stats")
Below, an example with library(conflicted)
and conflict_prefer("filter", "dplyr")
:
# WITH conflict_prefer("filter", "dplyr") as suggested at top
# R knows to assign priority
library(conflicted)
conflict_prefer("filter", "dplyr")
filter(mtcars, cyl == 8) %>% head(2)
# mpg cyl disp hp drat wt qsec vs am gear carb
# 1 18.7 8 360.0 175 3.15 3.44 17.02 0 0 3 2
# 2 14.3 8 360.0 245 3.21 3.57 15.84 0 0 3 4
Solution 5:[5]
As with KFB's comment above, one straightforward solution I've found is to:
- load your packages
- don't worry about order (which can be hard with dependencies)
- assign priority to whichever package you'd prefer "own" the namespace:
select <- dplyr::select
filter <- dplyr::filter
For example, see how the environment: namespace
changes below:
library(MASS)
select
function (obj)
UseMethod("select")
<bytecode: 0x7fbe822811b8>
<environment: namespace:MASS> # from MASS::select() <---------
select <- dplyr::select
select
function (.data, ...)
{
UseMethod("select")
}
<bytecode: 0x7fbe7c4a2f08>
<environment: namespace:dplyr> # now dplyr::select() <---------
Solution 6:[6]
After trying many alternatives, what worked for me was removing MASS and installing it again.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | David Arenburg |
Solution 2 | |
Solution 3 | dmontaner |
Solution 4 | |
Solution 5 | |
Solution 6 | Francisco Marco |