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?

Wilks

You can use it as you just wrote: dplyr::select(mpg) – Headstone

As of today 03.12.2019, five years later it's still not fixed, I just had the exact same issue. – Benzol

Answer 1

As Pascal said, the following works

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

Jaine

If you are sure you are going to load MASS and dplyr together very often and use 'select' a lot, you could do reassign the function: select <- dplyr::select which could help save typing 'dplyr::' repeatedly – Fayalite

I know this is old but anyway. Just encountered the same problem. And apparently MASS is imported (among others) by ggplot2 so I guess many are likely to use them together. Although I believe I've been using ggplot2 and dplyr without problems before... – Piezoelectricity

I have a similar problem. However, what is weird is that this problem did not occur until today, and I did not really change my code. I only plugged the section causing the error into an if(x == x) { ... } condition. Any ideas why this error suddenly appears, where previously there was no problem? – Ballyrag

@deca, I don't have any idea, you might like to ask that as a separate question. – Jaine

also clashes with package drc The workaround is to use dplyr:select, as stated above – Vu

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

Mutilate

Beautiful. I thought I was going mad. – Zelma

Could you update this answer, I think the functions you refer to are not in the repo anymore – Corrientes

@Corrientes thanks, I moved it into another package. links fixed. – Mutilate

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)

Coverup

+1 for the hint to searchpaths() to self-check. I found out that library(tidyverse) loads MASS before dplyr - this causes the frequent error! So the workaround is to explicitly load MASS before tidyverse like library(MASS); library (tidyverse) – Alyssa

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

Apiece

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

Apiece

Answer 6

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

Elan