0

I am developing an R package but I would like to break it down into two packages, say A and B, where B depends on A.

In the course of development I have created a number of internal utility functions, say .util1(), .util2(), etc. They are useful to keep my code tidy and avoid repetitions, but I don't want to export them and make them available to other users.

Rather than having one copy of these functions in both A and B, my idea was to put all of them in package A, and then access them from A using B:::.util1(), ... etc. On the other hand that doesn't look very neat, and I will have to document all these "hidden" dependencies somewhere (given that I will not explicitly export them from A). Are there other alternatives? Thanks!

Matteo Fasiolo
  • 541
  • 6
  • 17

1 Answers1

2

How about this, using the "zoo" package and its internal variable ".packageName" for illustration purpose. You may replace them with the names of your package and internal variable/function when testing.

library(zoo)                              # Load a library
zoo:::.packageName                        # Access an internal variable
.packageName                              # A test - Fail to call without the Namespace
pkg.env <- getNamespace("zoo")            # Store the Namespace
attach(pkg.env)                           # Attach it
.packageName                              # Succeed to call directly !
detach(pkg.env)                           # Detach it afterward

(Edited)

## To export an internal object to the current Namespace (without "attach")
assign(".packageName",get(".packageName",envir=pkg.env))

## Or using a loop if you have a few of internal objects to export
for (obj_name in a_list_of_names) {
  assign(obj_name,get(obj_name,envir=pkg.env))
}
xb.
  • 1,617
  • 11
  • 16
  • Thanks Xiaobei. But if I don't explicitly use zoo::: a user who is trying to debug a function might wonder where .packageName comes from... Also I might want to use just few functions from zoo, but here you are attaching everything so there might be conflicting names. – Matteo Fasiolo Dec 10 '13 at 16:19
  • @MatteoFasiolo The library "zoo" is for illustration purpose here. I will add a note shortly. In thinking of the Namespace conflict, I'd strongly suggest to use ":::" instead of "attach/detach". But for a neat syntax you preferred, one have to choose the latter but be sure to detach as soon as not in use. Maybe someone has a better choice? – xb. Dec 10 '13 at 16:35
  • Yes I got that zoo is for illustration. The fact is that both solutions (using ::: or "attach") are workarounds in my opinion. Another solutions could be to explicitly export those function from package B, but leave the "." in front of their names to signal that they are meant to be use internally only. – Matteo Fasiolo Dec 10 '13 at 19:56
  • Yes, you can export them explicitly (see my edit above). If you have the internal objects prefixed with a "." in your package A, you can either keep their names (as in the example) when exporting to B or change names where appropriate. – xb. Dec 10 '13 at 20:40
  • Actually my idea was to export them explicitly from package A, by adding a line "export(.util1)" in the NAMESPACE file of the package, and importing it by adding "importFrom(.util1, A)" to the NAMESPACE file of package B. So what is exported and imported is explicitly documented. The problem is that then (as I understand), CRAN will require me to provide documentation regarding what the function .util1() does. – Matteo Fasiolo Dec 10 '13 at 22:18
  • Um, then I understand you! Have you tried roxygen2 to handle R package documentation? By adding `@import` or `@export` to the documentation header, the namespace directives are automatically added for packages/functions you import. – xb. Dec 10 '13 at 23:18
  • Yes I'm using roxygen2, probably explicitly exporting and documenting all those functions is the best solution. – Matteo Fasiolo Dec 11 '13 at 16:12