What's the best way to work around function name conflicts in R?

user_9731173 0
Viewed 713

In loading a few packages to work with some data, I received an error when I tried to use the function select() from the dplyr package. I was trying to use a new package (to me), MASS, so I was easily able to diagnose and get things working properly. This experience made me curious, though, about the optimal way to work in a world of many packages, with functions that conflict with one another.

Consider the following code and error message:

library(dplyr)
library(MASS)


df<-data.frame(Lobsters=c(1,3,4,5,7,1),Llamas=c(7,1,2,5,8,3))

df2<-df%>%
  select(Lobsters)

Error in select(.,Lobsters) : unused argument (Lobsters)

While this error makes it clear that select() is giving me the problem, it doesn't necessarily make it clear to me that the problem is that I'm not calling on the select() function I'm used to.

I know I can call the dplyr function and get my desired result using:

df2_alt<-df%>%
  dplyr::select(Lobsters)

I wonder, though:

  1. Is there a best practice in diagnosing problems with same-named functions, besides the "The following object is masked from" messages when a package is loaded?

  2. Is my method of dplyr::select( the best way to work around these conflicts?

Ultimately, my current strategy is to load the package that has the select() function I'll be using more after the package that has the less-frequently-used version.

r
2 Answers

Here are some things that can be done.

  1. When issuing a library statement, R will list all conflicts. Pay attention to these! If you need to know the conflicts later enter: conflicts() .

  2. Use the exclude argument on library (R 3.6 and later). e.g. library(MASS, exclude = "select"). dplyr clobbers base lag and filter so you might want to get into the habit of routinely excluding those: library(dplyr, exclude = c("filter", "lag")) One can still access them using dplyr::lag, etc.

  3. Use dplyr::select notation if you find it has been masked.

  4. detach any packages you are no longer using, e.g. detach("package:MASS") .

  5. In some cases the masking is benign since the new version it is backwardly compatible and in those cases there is no need to avoid the conflict.

  6. As noted by @LenGreski in the comments the package order will determine the resolution of any conflicts. Each package overrides all prior packages that were loaded before it in the case of conflicts.

There are also a number of packages that address the problem of conflicts including conflicted (mentioned by @MrFlick), modules, import and box which are all on CRAN.

user_5165480

Using dplyr::select avoids ambiguity. In my opinion, that's the best you can do.

The drawback of not calling library(dplyr) is that the pipe is not in available. You can still do library(magrittr) to get it available. Or you can have a look at the nice import package that is very useful if you don't want to attach packages. Basically, if you do import::from("magrittr", "%>%"), you can use the pipe without attaching any package.

user_91977260
Related