R: 2 functions with the same name in 2 different packages
Solution 1
You have probably already noticed that the order of loading the packages makes a difference, i.e. the package that gets loaded last will mask the functions in packages loaded earlier.
To specify the package that you want to use, the syntax is:
chron::is.weekend()
tseries::is.weekend()
In other words, use packagename::functionname()
In addition, if you know that you will always want to use the function in chron, you can define your own function as follows:
is.weekend <- chron::is.weekend #EDIT
Solution 2
library(chron)
is.weekend.chron <- is.weekend
library(tseries)
then you can call is.weekend for the tseries version or is.weekend.chron for the chron version
Solution 3
you should turn to the conflicted
package from Hadly.
library(conflicted)
library(dplyr)
filter(mtcars, am & cyl == 8)
Then the conflicted package will throw an error and will force you clearly determine which function you prefer:
Error: filter found in 2 packages. You must indicate which one you want with :: * dplyr::filter * stats::filter
To resolve conflicts for your entire session, use <-
:
filter <- dplyr::filter
filter(mtcars, am & cyl == 8)
mpg cyl disp hp drat wt qsec vs am gear carb
1 15.8 8 351 264 4.22 3.17 14.5 0 1 5 4
2 15.0 8 301 335 3.54 3.57 14.6 0 1 5 8
You can also turn to the conflict_prefer()
function which can determine the winner when a conflict occur.
The code example is borrowed from Hadly, pls refer to the package website.
https://www.tidyverse.org/blog/2018/06/conflicted/
Related videos on Youtube
RockScience
Updated on July 05, 2022Comments
-
RockScience over 1 year
I need to load to R packages : tseries and chron
Both have a function named is.weekend
I always have in my environment the function from the second package I loaded.
How can I access always the function from, let say, chron ?
-
mbq over 12 years
is.weekend<-chron::is.weekend
is enough. -
Gavin Simpson over 12 yearsNot relevant here, so just for future reference in this thread: if the function is not exported (i.e. you want a specific S3 method and the method is not exported but the generic is) then the
:::
operator is required. -
Andrie over 12 years@Gavin That is correct, but I am always very cautious about referring to a function that is not exported. Presumably the package author didn't export it for a reason, and could change the function without warning. To safeguard code that is dependent on this type of function, it might be better to either persuade the package author to export this function, or to get permission to re-use in your own code.
-
Gavin Simpson over 12 yearsI agree totally for production code in a package. For personal use I don't see the issues as long as one archives the exact version of the package sources and records details of which versions of packages are used in the data analysis code. Of course, this applies to all use of package code as your are at the whims of the package developers to change things, and all code likely contains some bugs... The key issue is reproducibility in my opinion, the rest we have to accept and live with, but at least one can see the code and check it works with R and (most) R packages.
-
LauriK almost 9 yearsHow would you go about calling an operator-type function, like %in% which is defined in more than one loaded packages?
-
Andrie almost 9 years@LauriK Use
base::`%in%`
or`%in%` <- base::`%in%`