On 08/01/2016 8:20 PM, Imanuel Costigan wrote:
Hi
I am looking to release an updated version of RSQLServer and noticed that when
checking the package, I was getting a large number of errors of the style:
* checking R code for possible problems ... NOTE
auto_copy: no visible global function definition for ‘same_src’
b
I have dplyr in Description > Imports and call dplyr functions such as
`same_src` without them being imported into my package’s NAMESPACE (or making
qualified calls using `::`, the latter being my usual preference). My thinking is
that my package’s (dplyr) backend functionality should fail if dplyr itself is not
attached on the search path (by for e.g. calling `library(dplyr)`). I think the
latter is the behaviour that Hadley has advocated elsewhere (I can’t find
reference in places I would expect).
If it makes no sense to use your package without dplyr on the search
path, you should have
Depends: dplyr
in your DESCRIPTION file rather than Imports: dplyr. You should
explain this choice when you submit to CRAN, because using this means
that calling library(RSQLServer) will add dplyr to the search path if
it's not there. That could mess up something else that a user is doing,
so should normally be avoided. It can also cause your functions to
fail, if a user has already got dplyr on the search path, as well as
another package that masks some of its functions. Your package will use
the first copies it sees (unless you use :: even in this case).
If your package has functions that users might want to use on their own,
then you should import the dplyr functions that you need, or call them
with ::.
It doesn't sound like this applies to you, but another possibility is
that most of your package doesn't need dplyr. Then you might use
Suggests: dplyr
and check for it (using "if (requireNamespace('dplyr'))" ) before each
use with ::.
Duncan Murdoch
I am looking for guidance on what to do in this circumstance. I see at least
two possibilities:
* I import all these dplyr functions into my package (or call with ::) and make
CRAN errors go away
* I stick with behaviour described above and risk wasting CRAN maintainers'
time and have package rejected.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
