Should I worry about dplyr triple-color imports for new CRAN package that imports dplyr?

Package development
#1

Hello,

I'm writing a package that extends dplyr to work with another data type, similar to sparklyr. It loads dplyr onAttach().

I really want the interface to be as similar to dplyr as possible, so I'm using some of dplyr's unexported functions. When I use the check functionality in the build tab it gives me a warning about using these triple colon imports from the likes of dplyr, tidyselect, and tibble.

My first instinct was to just go ahead and copy/paste all of these in from github, but then I noticed functions like:

check_valid_names <- function (names, warn_only = FALSE) {
    invisible(.Call(`_dplyr_check_valid_names`, names, warn_only))
}

would force me to also importing the C++ counterpart.

Question is, I know that these are just WARNings in the CRAN check. Will CRAN still accept my package if I don't include all of these in my code? It seems pretty excessive to spend time on copy/pasting like so.

Dan

1 Like
#2

I see in the CRAN submission guidelines it states:

  • CRAN packages should use only the public API. Hence they should not use entry points not declared as API in installed headers nor .Internal() nor .Call() etc calls to base packages. Also, ::: should not be used to access undocumented/internal objects in base packages (nor should other means of access be employed). Such usages can cause packages to break at any time, even in patched versions of R.

When it says should does it mean should or must?

#4

Thank you so much @jdblischak for the insightful response.

I am indeed using the depends section for attaching dplyr. Will reach out to dplyr and see if they can export a thing or two.

1 Like
#5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

#3

You will have a hard time getting a package accepted on CRAN if R CMD check throws a WARNING.

A common strategy for this problem is to open an Issue on the package's GitHub repository to ask the authors if they are willing to export the internal function you would like to use. If the API of the internal function is stable, they may agree. But if the API isn't stable, they will decline, and then you definitely don't want to use it in your package since it could break at any time.

Are you explicitly loading dplyr using the onAttach() function? This common use case of loading a package can be accomplished by listing the package in the Depends field of DESCRIPTION. From Writing R Extensions:

The ‘Depends’ field gives a comma-separated list of package names which this package depends on. Those packages will be attached before the current package when library or require is called.