Is it expected that just calling `conflict_prefer()` one time turns on conflict resolution everywhere?

[DavisVaughan]

We got a report from a tidymodels user that our narrowly scoped internal calls to conflict_prefer() activate the conflicted machinery for everything https://github.com/tidymodels/tidymodels/issues/89

This does seem a little odd. In the below example I'm telling conflicted I just want it to care about dplyr::select(), but after conflict_prefer() runs it starts to care about everything - in this case that means it starts to care about the fact that mosaic overrides mean().

The original example in the tidymodels issue mentions that one issue with this is that you can't run the code suggestions because conflicted isn't actually attached yet. So if this behavior is expected then one way to improve this might be to namespace prefix the advice with conflicted::

library(mosaic) # masks mean and loads Matrix which also masks mean
#> Registered S3 method overwritten by 'mosaic':
#>   method                           from   
#>   fortify.SpatialPolygonsDataFrame ggplot2
#> 
#> The 'mosaic' package masks several functions from core packages in order to add 
#> additional features.  The original behavior of these functions should not be affected by this.
#> 
#> Attaching package: 'mosaic'
#> The following objects are masked from 'package:dplyr':
#> 
#>     count, do, tally
#> The following object is masked from 'package:Matrix':
#> 
#>     mean
#> The following object is masked from 'package:ggplot2':
#> 
#>     stat
#> The following objects are masked from 'package:stats':
#> 
#>     binom.test, cor, cor.test, cov, fivenum, IQR, median, prop.test,
#>     quantile, sd, t.test, var
#> The following objects are masked from 'package:base':
#> 
#>     max, mean, min, prod, range, sample, sum
library(dplyr)

mean(c(1, 2, 3))
#> [1] 2

conflicted::conflict_prefer("select", winner = "dplyr")
#> [conflicted] Will prefer dplyr::select over any other package

mean(c(1, 2, 3))
#> Error:
#> ! [conflicted] `mean` found in 3 packages.
#> Either pick the one you want with `::` 
#> * mosaic::mean
#> * Matrix::mean
#> * base::mean
#> Or declare a preference with `conflict_prefer()`
#> * conflict_prefer("mean", "mosaic")
#> * conflict_prefer("mean", "Matrix")
#> * conflict_prefer("mean", "base")

[kcarnold]

For a bit more context: some users of tidymodels::tidymodels_prefer() may not actually know about conflicted (what problem it solves, how it works, etc.), they're just following example code from tidymodels' documentation. The error message doesn't give any clue that tidymodels_prefer was the original cause.

(Can conflicted be configured to only care about conflicts that were explicitly preferred?)

[hadley]

In answer to the question in the title: yes.

[sanjmeh]

I faced the same problem so I switched to namespace prefix conflicted:: instead of attaching the package with library(conflicted) but this has landed me in a major performance problem, as raised as a separate issue here https://github.com/r-lib/conflicted/issues/75#issue-1419374461