Significant number of package conflicts in the brms package

[benscarlson]

When running the brms package with other packages that I usually have loaded (e.g. tidyverse, assertthat) as well as other less standard packages (e.g. maxnet) I received so many messages about package conflicts that I was forced to run brms in an environment with very few packages loaded.

In general, if there are one or two conflicts between packages, I can use conflicts_prefer() to resolve the issue. The problem I experienced with brms is that it is often unclear which package I should prefer. For example, I received the message that tibble::has_name and assertthat::has_name created a conflict in brms. But which has_name function does brms use? Similar questions for Matrix::expand and tidyr::expand. Before I stopped trying to resolve conflicts, I had received messages about conflicted functions with maxnet, glmnet, Matrix, tidyr, and assertthat packages.

Is there a preferred technique for running brms while other packages are loaded? Or perhaps the brms package code needs to prefix the package name to reduce conflicts? e.g., tibble::has_name() instead of has_name()?

[paul-buerkner]

I don't think these are an issue since brms does not load these packages into the global env upon loading brms. So these conflicts should not affect you. They would perhaps affect brms internal code if I wasn't clear on which functions to use, but that is not something a user needs to worry about.

[benscarlson]

You are right. The problem seems to be that the conflicted package is overeager to spot potential conflicts. There does not seem to be a way to tell the package to ignore putative conflicts in a single package or function, so I just unloaded the whole package. Once conflicted was unloaded, everything ran fine.