dplyr:: combine masking s3 combine function

[KateSenior]

We are trying to create a new s3 method called combine in a package, however the combine function is the same name as dplyr::combine and its being masked by this regardless of how we set it up.

Is there a way to force dplyr::combine to take a backseat (i.e. without using conflicted calls) or do we just have to accept that we need to change the name of our function?

Reprex here: GitHub - njtierney/democombine: What the Package Does (One Line, Title Case)

Similar issue documented here: Avoding s3 method collisions

[josiahparry]

You unfortunately cannot work around this easily. It’s unfortunate. You can use an .onAttach function which will use conflicted_prefer() or, if this an appropriate place, you can consider using c() orrrrr bite the bullet and rename the function.

[Gabor]

What exactly is the issue? It seems to work fine for me:

❯ pak::pkg_install("https://github.com/njtierney/democombine")

→ Will install 1 package.
→ The package (0 B) is cached.
+ democombine   0.0.0.9000 👷🏾🔧 (GitHub: 1d2dac9)
ℹ No downloads are needed, 1 pkg is cached
✔ Got democombine 0.0.0.9000 (source) (5.42 kB)
ℹ Packaging democombine 0.0.0.9000
✔ Packaged democombine 0.0.0.9000 (1.2s)
ℹ Building democombine 0.0.0.9000
✔ Built democombine 0.0.0.9000 (688ms)
✔ Installed democombine 0.0.0.9000 (github::njtierney/democombine@1d2dac9) (19ms)
✔ 1 pkg: added 1, dld 1 (NA B) [5.6s]

❯ library(democombine)
❯ democombine::combine
function (x, ...)
{
    UseMethod("combine")
}
<bytecode: 0x1051d7f48>
<environment: namespace:democombine>

❯ combine
function (x, ...)
{
    UseMethod("combine")
}
<bytecode: 0x1051d7f48>
<environment: namespace:democombine>

Is there anything wrong here?

[arangaca]

I think his problem is that if you load dplyr after his package, dplyr::combine will mask democombine::combine when OP would like to have his function prioritized over dplyr in all cases.

I don't think there's much you can do apart from specifying that your package must be loaded after dplyr, importing your function explicitly with ::, using packages such as conflicted or box (which can attach functions in specific namespaces), or renaming your function.

Unless you use a very uncommon name, it's usually a good practice to prefix functions with the package name/abbreviation or something that characterizes the package/data (e.g. str_ for stringr or gs4_ for googlesheets4).

[jdblischak]

@arangaca

I don't think there's much you can do apart from specifying that your package must be loaded after dplyr, importing your function explicitly with ::, using packages such as conflicted or box (which can load functions in specific namespaces), or renaming your function.

Exactly this. Because R doesn't separate the namespaces of the loaded packages, as a package author, there is not much you can do to influence the global environment of the end user running your code. The one I used to always run into was biomart::select() and dplyr::select() (example).

@arangaca

Unless you use a very uncommon name, it's usually a good practice to prefix functions with the package name/abbreviation or something that characterizes the package/data (e.g. str_ for stringr or gs4_ for googlesheets4).

I also recommend this strategy. Especially for a popular package like {dplyr}, if your package use a function with the same name, your users are going to run into a lot of problems.