r-lib / conflicted Goto Github PK
View Code? Open in Web Editor NEWAn alternative conflict resolution strategy for R
Home Page: https://conflicted.r-lib.org/
License: Other
An alternative conflict resolution strategy for R
Home Page: https://conflicted.r-lib.org/
License: Other
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)
Submit to CRAN:
usethis::use_version('patch')
cran-comments.md
devtools::submit_cran()
Wait for CRAN...
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 ::
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()
conflict_scout(tidyverse::tidyverse_packages(FALSE))
#> Error in body[[2]][[2]] : subscript out of bounds
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 ::
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()
Perform release:
devtools::check_win_devel()
(again!)devtools::submit_cran()
Wait for CRAN...
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)
Submit to CRAN:
usethis::use_version()
cran-comments.md
devtools::submit_cran()
Wait for CRAN...
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()
Submit to CRAN:
usethis::use_version('patch')
cran-comments.md
devtools::submit_cran()
Wait for CRAN...
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"))
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):
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.