dplyr:: combine masking s3 combine function

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

2 Likes

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.

1 Like

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?

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

1 Like

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

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.