Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Helper to resolve conflicts #4
This is from a discussion I had with @hadley about resolving conflicts.
The recommended solution is to assign a value in the global env, like this:
library(dplyr) #> The following objects are masked from ‘package:stats’: #> #> filter, lag lag <- stats::lag
This is a little fragile and changes the behavior from normal. For example, a user might clear their workspace by pressing the broom button in RStudio, or by doing
Another issue is that it introduces a slight change in the way R behaves when you assign a value with the same name as a function.
Normally, if you assign a variable with the same name as a function, you can still call the function as normal:
## In a new R session lag <- 100 lag(1:3) # Calls stats::lag #>  1 2 3 #> attr(,"tsp") #>  0 2 1
But if you've resolved a conflict by assigning it in the global env, then assigning a value to the same name will undo the resolution. For example:
library(dplyr) lag <- stats::lag lag <- 100 lag(1:3) # Calls dplyr::lag #>  NA 1 2
One possible solution that @hadley suggested is to add a function
# Make dplyr win all conflicts conflicted::win(dplyr) # Make dplyr win one conflict conflicted::win(dplyr, filter) # or conflicted::win(dplyr::filter)
The drawbacks here are that it's one more thing to learn, and that the package would need to have an exported function.
I played with this and you can "resolve" conflicts by smashing the definition in the environment in the search path (position 2 usually). For example, if you want dplyr::filter to win, then
so now that environment acts as a switching yard for conflicted functions.
I think this is starting to look like an imports env that sits between the global env and the package envs. You could import single functions or whole packages at a time but importing a symbol that already exists in that environment would throw a warning (or an error?).
Basically the same pattern as for packages' imports, but for (and shared by) users and sourced scripts.
Even without this feature isn't it an imports env?
I think allowing importing whole packages would be convenient, users could import stats or Biobase and move on to their script.
It'd be nice to provide a shortcut to this env so you can do:
.imports$lag <- stats::lag
Rather than (or pehaps along with?) making a given function from a package able to always win a conflict, would it make sense to be able to define the result of a single specific conflict between two packages?
As an example, I use
Essentially, I would like to be able to specify that when
Perhaps this could be extended to a form of
Yeah I very much like that idea - then
This will probably need to wait until I employ a different strategy for computing the conflicts, and after a thorough review of the other means of conflict resolution that we need.