dplyr::select function clashes with MASS::select

Question

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?

Answer 1

As Pascal said, the following works

require(MASS)
require(dplyr)
mtcars %>%
   dplyr::select(mpg)

Answer 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")

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

Answer 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

Answer 5

As with KFB's comment above, one straightforward solution I've found is to:

1. load your packages
2. don't worry about order (which can be hard with dependencies)
3. 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() <---------

Answer 6

After trying many alternatives, what worked for me was removing MASS and installing it again.