R: 2 functions with the same name in 2 different packages

66,246

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/

Share:
66,246

Related videos on Youtube

RockScience
Author by

RockScience

Updated on July 05, 2022

Comments

  • RockScience
    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
    mbq over 12 years
    is.weekend<-chron::is.weekend is enough.
  • Gavin Simpson
    Gavin Simpson over 12 years
    Not 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
    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
    Gavin Simpson over 12 years
    I 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
    LauriK almost 9 years
    How would you go about calling an operator-type function, like %in% which is defined in more than one loaded packages?
  • Andrie
    Andrie almost 9 years
    @LauriK Use base::`%in%` or `%in%` <- base::`%in%`

Related