muschellij2 · March 12, 2018 18:33
diff --git a/NAMESPACE_R_Packages.Rmd b/NAMESPACE_R_Packages.Rmd
 ## Initial Question
 

 From my understanding, there are three general ways to replace "library" statements in R packages:
 1. List all packages on which our package relies in the "Imports" section of the DESCRIPTION file, and use the "@imports" statement in the NAMESPACE file to attach these packages to R.
 2. List all packages on which our package relies in the "Imports" section of the DESCRIPTION file, and use package::function in our R code whenever we want to call a function from another package. For example, if we wanted to use the mutate() function from dplyr, we would write: dplyr::mutate().
 3. List all packages on which our package relies in the "Depends" section of the DESCRIPTION file.

 ## Answer
 I combo option 1 and 2 and heavily suggest not using option 3:

 I use #' @importFrom directives for roxygen2.  (Note, it is @import not @imports, so that may actually throw an error).   This allows you to import only a set of functions from a package.  I tend to do this even with things like dplyr, but I end up importing like 20 different functions from that package.  Make sure the namespace is getting generated by roxygen (should have a roxygen comment header at the top).

 Also, note from https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
 > Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available.


 Can you point me to your package so I can take a look?

 Questions/comments:
 1) More specifically, it skips the first function in our R code entirely.  Have you checked the .Rbuildignore file to see if that function is in there?  How do you know it was skipped?
 2) Using `package::function` isn't a bad idea but there are a few times where that can come into trouble.  
 1) The code works on your machine, but fails R CMD check or fails on someone else's.  This is usually because you have pkg::function, where you have pkg installed, but it's not properly defined in DESCRIPTION (may accidentally be in Suggests or left out), but other person/machine doesn't have pkg installed.
 2 - pretty technical and I'm not even sure it's a problem) If something is passed into a function that is a general function  For example, package A defines function func() for data.frames.  Package B has this new cool class of objects (call them widgets) that aren't data.frames.  Package B extends func to work with widgets.  I'm not sure if pkgA::func(widget_thing) will work out of the box without careful importing.
	## Initial Question


	From my understanding, there are three general ways to replace "library" statements in R packages:
	1. List all packages on which our package relies in the "Imports" section of the DESCRIPTION file, and use the "@imports" statement in the NAMESPACE file to attach these packages to R.
	2. List all packages on which our package relies in the "Imports" section of the DESCRIPTION file, and use package::function in our R code whenever we want to call a function from another package. For example, if we wanted to use the mutate() function from dplyr, we would write: dplyr::mutate().
	3. List all packages on which our package relies in the "Depends" section of the DESCRIPTION file.

	## Answer
	I combo option 1 and 2 and heavily suggest not using option 3:

	I use #' @importFrom directives for roxygen2. (Note, it is @import not @imports, so that may actually throw an error). This allows you to import only a set of functions from a package. I tend to do this even with things like dplyr, but I end up importing like 20 different functions from that package. Make sure the namespace is getting generated by roxygen (should have a roxygen comment header at the top).

	Also, note from https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
	> Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available.


	Can you point me to your package so I can take a look?

	Questions/comments:
	1) More specifically, it skips the first function in our R code entirely. Have you checked the .Rbuildignore file to see if that function is in there? How do you know it was skipped?
	2) Using `package::function` isn't a bad idea but there are a few times where that can come into trouble.
	1) The code works on your machine, but fails R CMD check or fails on someone else's. This is usually because you have pkg::function, where you have pkg installed, but it's not properly defined in DESCRIPTION (may accidentally be in Suggests or left out), but other person/machine doesn't have pkg installed.
	2 - pretty technical and I'm not even sure it's a problem) If something is passed into a function that is a general function For example, package A defines function func() for data.frames. Package B has this new cool class of objects (call them widgets) that aren't data.frames. Package B extends func to work with widgets. I'm not sure if pkgA::func(widget_thing) will work out of the box without careful importing.