r-lib / conflicted Goto Github PK

https://developer.r-project.org/Blog/public/2019/03/19/managing-search-path-conflicts/index.html

i.e. only let pkgA::foo()beat pkgB::foo() if .Deprecated() mentions foo().

In RStudio.

15: .rs.getHelpFromObject(object, envir, topic)
14: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
13: .rs.getHelpFromObject(object, envir, topic)
12: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
11: .rs.getHelpFromObject(object, envir, topic)
10: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
9: .rs.getHelpFromObject(object, envir, topic)
8: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
7: .rs.getHelpFromObject(object, envir, topic)
6: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
5: .rs.getHelpFromObject(object, envir, topic)
4: .rs.getHelp(topic = objectName, package = namespace, sig = signature)
3: .rs.getHelpFromObject(object, envir, name)
2: .rs.getHelpFunction(what, from)

Start by creating a reprex

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 rm(list=ls()), and that would reset the conflict resolution without any indication that it's happening.

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] 1 2 3
#> attr(,"tsp")
#> [1] 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
#> [1] NA  1  2

One possible solution that @hadley suggested is to add a function win:

# 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.

Explore the impact on BiocGenerics

Base R doesn't do this, and it causes problems (e.g. haven and Hmisc both declare methods for labelled class)

ls(asNamespace("ggplot2")$.__S3MethodsTable__.)

I'm not sure whose issue this is, but I noticed that code that had capture.output() from utils running inside it asked me to resolve conflicts that were unrelated to the function call before allowing the code to run. I noticed it when using the brms package in tandem with tidyverse:

library(conflicted)
library(tidyverse)
library(brms)
#> Loading required package: Rcpp
#> Loading 'brms' package (version 2.9.0). Useful instructions
#> can be found by typing help('brms'). A more detailed introduction
#> to the package is available through vignette('brms_overview').
conflict_scout()
#> 10 conflicts:
#> * `.DollarNames`: [Rcpp]
#> * `filter`      : dplyr, stats
#> * `formals<-`   : [Rcpp]
#> * `intersect`   : [dplyr]
#> * `lag`         : dplyr, stats
#> * `Position`    : ggplot2, base
#> * `prompt`      : [Rcpp]
#> * `setdiff`     : [dplyr]
#> * `setequal`    : [dplyr]
#> * `union`       : [dplyr]

tmp_df <- tibble(Y=rnorm(100),
                 X=rnorm(100))

brm_fit <- brm(Y~s(X,bs='cr'),
               chains=1,iter=1000,
               family="gaussian", data=tmp_df)
#> Compiling the C++ model
#> [conflicted] `filter` found in 2 packages.
#> Either pick the one you want with `::` 
#> * dplyr::filter
#> * stats::filter
#> Or declare a preference with `conflict_prefer()`
#> * conflict_prefer("filter", "dplyr")
#> * conflict_prefer("filter", "stats")

When I resolved that conflict, it went to the next one on the list:

library(conflicted)
library(tidyverse)
library(brms)
#> Loading required package: Rcpp
#> Loading 'brms' package (version 2.9.0). Useful instructions
#> can be found by typing help('brms'). A more detailed introduction
#> to the package is available through vignette('brms_overview').
# conflict_scout()
conflict_prefer("filter", "stats")
#> [conflicted] Will prefer stats::filter over any other package

tmp_df <- tibble(Y=rnorm(100),
                 X=rnorm(100))

brm_fit <- brm(Y~s(X,bs='cr'),
               chains=1,iter=1000,
               family="gaussian", data=tmp_df)
#> Compiling the C++ model
#> [conflicted] `lag` found in 2 packages.
#> Either pick the one you want with `::` 
#> * dplyr::lag
#> * stats::lag
#> Or declare a preference with `conflict_prefer()`
#> * conflict_prefer("lag", "dplyr")
#> * conflict_prefer("lag", "stats")

And so on, until all conflicts were resolved. By using debug(), I found that this problem appears to originate in the capture.output() function, but it doesn't use filter(), lag(), or any of the other conflicted functions to run. My full script had 20+ conflicts that don't usually pertain to my code, so it was a bit annoying to work through, though not intractable. I figured I'd bring it to your attention.

^{Created on 2019-07-19 by the reprex package (v0.3.0)}

It might be useful to create new functions:

conflicted::enable_conflicted()
conflicted::disable_conflicted()

In order to include conflicted in the tidyverse package.

By default, when you execute:

library(conflicted)

The package could be enabled by default. But with tidyverse:

library(tidyverse)

The package could be included, but not enabled, and raise a message saying that it could be enabled, till the users get used to the "conflicted" library, and adapt their code.

And in the future, vice versa, the package could be enabled by default, and give the option of disabling it.

By setting an onDetach hook in the library shim

What if any is the preferred method to remove conflicted preferences?
For example, if I do

library(dplyr)
library(MASS)

conflicted::conflict_prefer("select", "dplyr")

What would I do to remove that preference later on? It would seem that conflicted:::conflicts_remove("dplyr") should work, but then, why isn't it exported? Also, what would I do to remove a preference for one particular function, not just overwrite it with a new preference?

Prepare for release:

• devtools::check()
• devtools::check_win_devel()
• rhub::check_for_cran()
• revdepcheck::revdep_check(num_workers = 4)
• Polish NEWS
• Polish pkgdown reference index

Submit to CRAN:

• usethis::use_version('patch')
• Update cran-comments.md
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()

e.g. dplyr::intersects() makes base::intersect() generic so it shouldn't ever cause problems.

Although in my code I am not using the function layout calling heatmap3::heatmap3

causes the following error:
Error: layout found in 2 packages. You must indicate which one you want with ::

• plotly::layout
• graphics::layout

Since the call is not made from my code I can not "choose which function to use." Package description of conflicted

How to proceed in such a case?

I'm having trouble using %in% with conflicted. The function works when R is in a clean state.

library(conflicted)

"A" %in% LETTERS
# [1] TRUE

The package h2o also declares the function %in%, which throws an error from conflicted.

library(conflicted)
library(h2o)
"A" %in% LETTERS
# Error: %in% found in 2 packages. You must indicate which one you want with ::
#  * h2o::%in%
#  * base::%in%

How can I specify which package's %in% I want to use? Copying and pasting the recommendation doesn't work.

"A" base::%in% LETTERS
# Error: unexpected symbol in ""A" base"

I thought that using backticks around the function name would help, but that still doesn't work.

"A" base::`%in%` LETTERS
# Error: unexpected symbol in ""A" base"

Any ideas?

This happens when attaching one of my packages :

library(conflicted)
library(inops)
#> Error: `fn` must be an R function, not a primitive function

The package can be attached without problem if conflicted is not attached.

library(inops)
#> 
#> Attaching package: 'inops'
#> The following object is masked from 'package:base':
#> 
#>     <<-

It appears to come from the fact that the package overrides a primitive (namely <<-).

library(conflicted) triggers conflicted:::.onAttach(), which calls conflicted:::conflicts_register(), which calls conflicted:::is_superset() and rlang::fn_fmls() is called, and chokes on primitives because they have no formals.

If I call library() twice then I have no error and can use the package, including <<- :

library(conflicted)
library(inops)
#> Error: `fn` must be an R function, not a primitive function
library(inops)
2 %in[]% c(1,3)
#> [1] TRUE
x <- 1:4
x < 3 <- 0
x
#> [1] 0 0 3 4

library(conflicted) will be the one failing if it's called second :

library(inops)
#> 
#> Attaching package: 'inops'
#> The following object is masked from 'package:base':
#> 
#>     <<-
library(conflicted)
#> Error: package or namespace load failed for 'conflicted':
#>  .onAttach failed in attachNamespace() for 'conflicted', details:
#>   call: NULL
#>   error: `fn` must be an R function, not a primitive function

in conflicted::conflict_scout(c("devtools", "usethis"))

It should be identical to usethis::use_data()

When converting a script that was not written with conflicted in mind, it would be nice if I could load conflicted in some kind of "passive" mode where it tracked each time a conflicted function name was used without first resolving the conflict, and emitted a warning for it, but allowed execution to continue using R's default conflict resolution. Then it could have a function similar to conflict_scout that only reports on conflicted names that were actually used.

e.g. conflict_disable()

I my under stand, the 'conficted' should only block the user defined function on naming ambiguity, but I meet a strange case as below:
base::as.Date(base::intersect(idx[1:10], idx[7:15]))

**Error: as.Date.numeric found in 2 packages. You must indicate which one you want with ::

• zoo::as.Date.numeric
• base::as.Date.numeric**

in my understanding, it should not block this function 'base::as.Date', but it rerport an error. why the inside called function is blocked by 'conflicted'?

Hi! I have a potential feature request:

Would it be possible to have the ability to prioritize packages during conflicts? That is to say if I have PackageA and PackageB, given a conflict I always want to use PackageB over PackageA, rather than using the order I load them in?

I'm not sure how exactly this would be implemented, but I imagine this happens often in practice (like dplyr is always used over plyr).

Thanks!

Is it intentional that conflicted outright breaks other packages? I thought it was intended to help enforce explicit namespace behaviour on the part of the user, but it seems to also expect this of the packages used by the user. For example, when I run:

library("conflicted")
library("rstan")
stancode <- 'data {real y_mean;} parameters {real y;} model {y ~ normal(y_mean,1);}'
mod <- rstan::stan_model(model_code = stancode)

I get:

Error: plot found in 2 packages. You must indicate which one you want with ::
* rstan::plot
 * graphics::plot

Presumably because rstan::stan_model internally uses plot without explicit namespace reference. But surely the internals of a package is not something one can expect users to be able to fix?

Prepare for release:

• devtools::check_win_devel()
• rhub::check_for_cran()
• Polish NEWS

Perform release:

• Bump version (in DESCRIPTION and NEWS)
• devtools::check_win_devel() (again!)
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Tag release
• Merge RC back to master branch
• Bump dev version
• Write blog post
• Tweet
• Add link to blog post in pkgdown news menu

Template from r-lib/usethis#338

Hi.

after updating to R 3.6.0 I'm expering in Rstudio that after loading conflicted, then I need to prefix library with base::

this was not the case before the update, which I did a couple of days ago.
is this an expected behaviour?

Greetings from Denmark
Dan Olesen

I use /usr/local/bin/R from command line on macOS and TAB key for code completion, which seems not compatible with this package. It shows superfluous errors on parameter name completion. For example, if I press TAB key after this,

library(conflicted)
library(dplyr)
dplyr::lag(

then the following error is printed:

dplyr::lag(Error: [conflicted] `lag` found in 2 packages.
Either pick the one you want with `::`
* dplyr::lag
* stats::lag
Or declare a preference with `conflict_prefer()`
* conflict_prefer("lag", "dplyr")
* conflict_prefer("lag", "stats")

The position of a package in the search path depends solely on the load order, disregarding dependencies. In the first example, dplyr comes after tibble in the search path, even though dplyr imports tibble. Perhaps it doesn't matter much, but it feels more consistent if the packages are ordered topologically (w.r.t. to the dependency graph) in the search path.

library(dplyr)
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
library(tibble)
search()[1:4]
#> [1] ".GlobalEnv"     "package:tibble" "package:dplyr"  "package:stats"

Created on 2018-06-27 by the reprex package (v0.2.0).

library(tibble)
library(dplyr)
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
search()[1:4]
#> [1] ".GlobalEnv"     "package:dplyr"  "package:tibble" "package:stats"

Created on 2018-06-27 by the reprex package (v0.2.0).

Could we do better with a C implementation that stores names in an environment

When a function in GEOquery Bioconductor package is run after loading the conflicted package, R session terminates. As I couldn't see any error messages before R terminated in Rstudio, I ran the same lines at the command line.

> library(conflicted)
> library(GEOquery)
Loading required package: Biobase
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following objects are masked from ‘package:parallel’:

    clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
    clusterExport, clusterMap, parApply, parCapply, parLapply,
    parLapplyLB, parRapply, parSapply, parSapplyLB

The following objects are masked from ‘package:stats’:

    IQR, mad, sd, var, xtabs

The following objects are masked from ‘package:base’:

    anyDuplicated, append, as.data.frame, cbind, colMeans, colnames,
    colSums, do.call, duplicated, eval, evalq, Filter, Find, get, grep,
    grepl, intersect, is.unsorted, lapply, lengths, Map, mapply, match,
    mget, order, paste, pmax, pmax.int, pmin, pmin.int, Position, rank,
    rbind, Reduce, rowMeans, rownames, rowSums, sapply, setdiff, sort,
    table, tapply, union, unique, unsplit, which, which.max, which.min

Welcome to Bioconductor

    Vignettes contain introductory material; view with
    'browseVignettes()'. To cite Bioconductor, see
    'citation("Biobase")', and for packages 'citation("pkgname")'.

Setting options('download.file.method.GEOquery'='auto')
Setting options('GEOquery.inmemory.gpl'=FALSE)
> gset <- getGEO("GSE39549", GSEMatrix =TRUE, AnnotGPL=FALSE, destdir = ".")
terminate called after throwing an instance of 'Rcpp::eval_error'
  what():  Evaluation error: evalq found in 2 packages. You must indicate which one you want with ::
 * BiocGenerics::evalq
 * base::evalq.
Aborted (core dumped)

Session info after loading the packages but before running getGEO()

> sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.4 LTS

Matrix products: default
BLAS: /usr/lib/atlas-base/atlas/libblas.so.3.0
LAPACK: /usr/lib/atlas-base/atlas/liblapack.so.3.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8    
 [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods  
[8] base     

other attached packages:
[1] GEOquery_2.46.15    Biobase_2.38.0      BiocGenerics_0.24.0
[4] conflicted_0.1.0   

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.17     tidyr_0.8.1      crayon_1.3.4     dplyr_0.7.5     
 [5] assertthat_0.2.0 R6_2.2.2         magrittr_1.5     pillar_1.2.2    
 [9] rlang_0.2.0.9001 bindrcpp_0.2.2   limma_3.34.9     xml2_1.2.0      
[13] readr_1.1.1      glue_1.2.0       purrr_0.2.4      hms_0.4.2       
[17] compiler_3.4.4   pkgconfig_2.0.1  tidyselect_0.2.4 bindr_0.1.1     
[21] tibble_1.4.2    

RStudio lets you control/command-click on functions to jump to their definition.

I just tried it on filter(), after running conflict_prefer("filter", "dplyr"). I get an error

Error in loadNamespace(name) : there is no package called ‘.conflicts’

and it opened a tab with the message

# ERROR: Definition of function 'filter' not found
# in namespace '.conflicts'

Don't know if this can be circumvented with how conflicted works, but it surprised me when it happened.

I am finding it frustrating to need to choose winners on a pure function-by-function basis. Loading conflicted requires that I immediately make decisions on 41 functions or expect long-running jobs to bomb; that's a lot, especially because I don't have to (knowingly) use a function myself for it to crash my code. For me at least. I'd like to be able to give a general preference for the all of the functions in one package over those in another. Alternatively or in addition, I'd like conflict_prefer to take a vector of functions for which a specified package should defeat all comers.

Running conflict_scout() after loading the packages I am using for my current project gives me 119 conflicts, 60-some-odd percent of which are resolved automatically by your rules. (Impressive, that). Of the remainder, about 60 percent involve at least one package in the tidyverse family or near associates (notably magrittr) and about 40 percent involve two tidyverse packages, particularly rlang and purrr, which show up with 11 conflicts just with one another. Within the tidyverse I see the most conflicts with pryr, tidyr, purrr, and dplyr. Other packages that show multiple conflicts with the tidyverse or one another are Hmisc,, Matrix, pracma, survey, and maps.

Right now, based mainly on my uninformed guesses about the role of certain packages in the tidyverse ecosystem, I am resolving within-tidyverse conflicts by the following priority ordering, top first: rlang, purr, tidyr; any tidyverse package over magrittr, and dplyr over all non-tidyverse packages. If these orderings are clearly egregiously wrong, I'd like to know.

Great package! I am the author of the elliptic package,

https://github.com/RobinHankin/elliptic.git

The package defines a function sd() which is one of a systematic set of functions with names such as sn(), ds(), ss() and so on which means that the name sd() is unalterable. So this creates an unavoidable conflict with base::sd(). What I would like is to have an option to make the help system respect the conflict resolution:

R % R --vanilla --quiet
> library(conflicted)
> library(elliptic)
> conflict_prefer("sd","elliptic")
[conflicted] Will prefer elliptic::sd over any other package
> ?sd
Help on topic ‘sd’ was found in the following packages:

  Package               Library
  stats
/Library/Frameworks/R.framework/Versions/3.5/Resources/library
  elliptic              /Users/rhankin/Library/R/3.5/library

I don't like to have to choose which option I want here: I want to go
directly to the elliptic::sd helppage. Is this possible?

Why does the following code returns an error even though I am explicitly calling rstan::extract and not extract. Actually the error already appears in the rstan::stan( ) call, but only if there is the rstan::extract(fit) statement in the script afterwards. When conflicted is not loaded the code runs without error.

library(conflicted)
library(magrittr)
library(rstan)
#> Loading required package: StanHeaders
#> Loading required package: ggplot2
#> rstan (Version 2.21.2, GitRev: 2e1f913d3ca3)
#> For execution on a local, multicore CPU with excess RAM we recommend calling
#> options(mc.cores = parallel::detectCores()).
#> To avoid recompilation of unchanged Stan programs, we recommend calling
#> rstan_options(auto_write = TRUE)
#> Do not specify '-march=native' in 'LOCAL_CPPFLAGS' or a Makevars file

data <- list(N = nrow(mtcars),
             y = mtcars$mpg,
             x = mtcars$wt)

fit <- rstan::stan(model_code = "data {
  int<lower=0> N;
  vector[N] x;
  vector[N] y;
}
parameters {
  real alpha;
  real beta;
  real<lower=0> sigma;
}
model {
  y ~ normal(alpha + beta * x, sigma);
}", data = data)
#> Error: [conflicted] `extract` found in 2 packages.
#> Either pick the one you want with `::` 
#> * rstan::extract
#> * magrittr::extract
#> Or declare a preference with `conflict_prefer()`
#> * conflict_prefer("extract", "rstan")
#> * conflict_prefer("extract", "magrittr")

posterior <- rstan::extract(fit)
#> Error in h(simpleError(msg, call)): error in evaluating the argument 'object' in selecting a method for function 'extract': object 'fit' not found

^{Created on 2020-08-31 by the reprex package (v0.3.0)}

Once conflicted is loaded, tidyverse_conflicts() doesn't work. I don't think it's meant to be called directly, but something to keep in mind in case it is indicative of other issues.

library(conflicted)
library(tidyverse) #prints correctly
tidyverse_conflicts()
#> Error: filter found in 2 packages. You must indicate which one you want with ::
#>  * dplyr::filter
#>  * stats::filter

Created on 2018-06-08 by the reprex package (v0.2.0).

search()
#> [1] ".GlobalEnv"        "package:stats"     "package:graphics" 
#> [4] "package:grDevices" "package:utils"     "package:datasets" 
#> [7] "package:methods"   "Autoloads"         "package:base"
library(conflicted)
search()
#>  [1] ".GlobalEnv"         ".conflicts"         "package:conflicted"
#>  [4] "package:stats"      "package:graphics"   "package:grDevices" 
#>  [7] "package:utils"      "package:datasets"   "package:methods"   
#> [10] "Autoloads"          "package:base"
library(dplyr)
search()
#>  [1] ".GlobalEnv"         ".conflicts"         "package:dplyr"     
#>  [4] ".conflicts"         "package:conflicted" "package:stats"     
#>  [7] "package:graphics"   "package:grDevices"  "package:utils"     
#> [10] "package:datasets"   "package:methods"    "Autoloads"         
#> [13] "package:base"
library(tidyr)
search()
#>  [1] ".GlobalEnv"         ".conflicts"         "package:tidyr"     
#>  [4] ".conflicts"         "package:dplyr"      ".conflicts"        
#>  [7] "package:conflicted" "package:stats"      "package:graphics"  
#> [10] "package:grDevices"  "package:utils"      "package:datasets"  
#> [13] "package:methods"    "Autoloads"          "package:base"

Created on 2018-09-26 by the reprex package (v0.2.1.9000)

Prepare for release:

• devtools::check()
• devtools::check_win_devel()
• rhub::check_for_cran()
• revdepcheck::revdep_check(num_workers = 4)
• Polish NEWS
• Polish pkgdown reference index

Submit to CRAN:

• usethis::use_version()
• Update cran-comments.md
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()

I can't really tell what's going on here, but I'm getting an error about setdiff() when I haven't used it at all.

library(conflicted)
library(tidyverse)
library(lubridate)
library(memoise)

tib <- tibble(x = 1:2, y = 3:4)

f <- function(tib) {
  mutate(tib, z = if_else(x == 1, y, x))
}
mf <- memoise(f)

f(tib)
#> # A tibble: 2 x 3
#>       x     y     z
#>   <int> <int> <int>
#> 1     1     3     3
#> 2     2     4     2

mf(tib)
#> [conflicted] `setdiff` found in 2 packages.
#> Either pick the one you want with `::` 
#> * lubridate::setdiff
#> * dplyr::setdiff
#> Or declare a preference with `conflict_prefer()`
#> * conflict_prefer("setdiff", "lubridate")
#> * conflict_prefer("setdiff", "dplyr")

^{Created on 2019-07-23 by the reprex package (v0.3.0)}

When I load the 'zoo' package, this line of code:

base::as.Date(x = foo, format = "bar")

persistently gives me this warning message:

Error: as.Date found in 2 packages. You must indicate which one you want with ::
* zoo::as.Date
* base::as.Date

This message is later present after every line of code I execute.

The fact that conflicted issue an error can break many things, to the point where conflicted cannot even be loaded. For example, the IDE RKWard overwrites require to account for its own way to install packages and that breaks loading conflicted:

> library(conflicted)
Error: package or namespace load failed for ‘conflicted’:
 .onAttach failed in attachNamespace() for 'conflicted', details:
  call: NULL
  error: require found in 2 packages. You must indicate which one you want with ::
 * rkward::require
 * base::require

This is just one example, but as far as I like the idea behind conflicted, having scripts being stopped "just" because of namespace conflicts is not a cost I would like to pay for using the package. I would find it most useful if it was throwing warnings instead (then I know I have to take care of the conflict, yet my script still runs if this is what I need right now).

So I'm humbly suggesting either to yield warnings instead of errors by default, or make the level of output (warning/error) configurable.

Prepare for release:

• devtools::check()
• devtools::check_win_devel()
• Polish NEWS
• Polish pkgdown reference index

Submit to CRAN:

• usethis::use_version('patch')
• Update cran-comments.md
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()

For example this code:

library(conflicted)

library(geepack)
library(PairedData)
library(Matrix)

timeorder <- rep(1:5, 6)
tvar <- timeorder + rnorm(length(timeorder))
idvar <- rep(1:6, each=5)
uuu <- rep(rnorm(6), each=5)
yvar <- 1 + 2*tvar + uuu + rnorm(length(tvar))
simdat <- data.frame(idvar, timeorder, tvar, yvar)

mod1 <- geeglm(yvar~tvar, id=idvar, data=simdat, corstr="ar1")

summary(mod1)

output:

Error: [conflicted] `summary` found in 2 packages.
Either pick the one you want with `::` 
* Matrix::summary
* PairedData::summary
Or declare a preference with `conflict_prefer()`
* conflict_prefer("summary", "Matrix")
* conflict_prefer("summary", "PairedData")

In fact there are 3 sammary functions here: base::summary, Matrix::summary and PairedData::summary. But only Matrix::summary and PairedData::summary are reported. Is it bug or there is any solution for it?

Certain packages, like tidylog and wisegroup, are designed to mask multiple functions in another package. If these packages are used with conflicted, the user will have to include numerous calls to conflict_prefer() to avoid errors. An alternative is to provide a function, e.g. conflict_always_prefer(), that allows the user to prefer all functions exported from a package.

One way to implement this would be:

conflict_always_prefer <- function(winner, losers = NULL, quiet = FALSE) {
  invisible(
    lapply(getNamespaceExports(winner), conflict_prefer, winner, losers, quiet)
  )
}

# For example
conflict_always_prefer(winner = "tidylog", losers = c("dplyr", "tidyr"))

https://developer.r-project.org/Blog/public/2019/03/19/managing-search-path-conflicts/

e.g. this shouldn't be a conflict:

conflict_scout(c("base", "ggplot2"))
#> 1 conflict:
#> * `Position`: base, ggplot2

Thanks @hadley for releasing this really useful package!

Was just testing this out with the README examples and found a couple of text render issues (w/ junk characters):

e.g. 1

e.g.2

I cannot use the conflict_prefer function at all, while it works perfectly on my collegue's computer. Here is my call of the first example in the help:

library(conflicted)
conflict_prefer("filter", "dplyr")

Tthis throws this error:

[conflicted] Removing existing preference
[conflicted] Will prefer stats::filter over any other package
Error: fn must be an R function, not a primitive function

Here is the error trace:

> rlang::last_error()
<error>
message: `fn` must be an R function, not a primitive function
class:   `rlang_error`
backtrace:
 1. conflicted::conflict_prefer("filter", "stats")
 2. conflicted:::conflicts_register()
 3. conflicted::conflict_scout(pkgs)
 4. conflicted:::map2(names(conflicts), conflicts, superset_principle)
 5. base::mapply(.f, .x, .y, MoreArgs = list(...), SIMPLIFY = FALSE)
 7. conflicted:::is_superset(fun, non_base, base = base)
 8. rlang::fn_fmls(base_obj)
 9. rlang:::check_closure(fn)
Call `rlang::last_trace()` to see the full backtrace

> rlang::last_trace()
    x
 1. \-conflicted::conflict_prefer("filter", "stats")
 2.   \-conflicted:::conflicts_register()
 3.     \-conflicted::conflict_scout(pkgs)
 4.       \-conflicted:::map2(names(conflicts), conflicts, superset_principle)
 5.         \-base::mapply(.f, .x, .y, MoreArgs = list(...), SIMPLIFY = FALSE)
 6.           \-(function (fun, pkgs) ...
 7.             \-conflicted:::is_superset(fun, non_base, base = base)
 8.               \-rlang::fn_fmls(base_obj)
 9.                 \-rlang:::check_closure(fn)

> packageVersion("conflicted")
[1] ‘1.0.4’

> session_info()
- Session info ------------------------------------------------------------
 setting  value                       
 version  R version 3.5.2 (2018-12-20)
 os       Windows >= 8 x64            
 system   x86_64, mingw32             
 ui       RStudio                     
 language (EN)                        
 collate  French_France.1252          
 ctype    French_France.1252          
 tz       Europe/Paris                
 date     2019-09-06                  

- Packages ----------------------------------------------------------------
#[... a lot of packages...]

Related to #4 and #12 (and tidyverse/lubridate#705)
I posted some code in a lubridate "issue" that, if used within library packages, could be used to limit function masking by later-loaded libraries.

tidyverse/lubridate#742 (comment)

I'm sure there are better ways to go about this, but perhaps this will plant a seed in someone's mind.