writing user packages that depend on nCompiler: summary

[paciorek]

At present, basic use of nCompiler in a dependent package (e.g., written by a developer who wants to use nCompiler) works if the package has nCompiler in Imports in DESCRIPTION and import(nCompiler) in NAMESPACE.

I think this satisfies our basic requirement and improves upon nimble, which needs to be in Depends. This seems to be because Perry has set up the scoping in nCompiler such the nested parent envs of a class method or nFunction include imports:testImportPkg:

> objs <- fun_using_nClass(1, returnObj = TRUE)
To-do: Care needed to filter interfaced methods by exportMembers names.
> parent.env(environment(objs[[1]]$Cfoo))
<environment: 0x5ca08b53e6e8>
> parent.env(parent.env(environment(objs[[1]]$Cfoo)))
<environment: 0x5ca08b68c370>
> parent.env(parent.env(parent.env(environment(objs[[1]]$Cfoo))))
<environment: namespace:testImportPkg>
> parent.env(parent.env(parent.env(parent.env(environment(objs[[1]]$Cfoo)))))
<environment: 0x5ca08b741f60>
attr(,"name")
[1] "imports:testImportPkg"

In NIMBLE we were finding nimble namespace objects based on the search path.

What does not work is the use of importFrom(nCompiler, nClass, nFunction, nCompile) in NAMESPACE or the use of nCompiler::nCompile (etc.) without any import in NAMESPACE. This fails if a user were to use nCompiler operators without use of nCompiler::. This would happen if a user used rep, e.g., not realizing that this is changed to nRep or if they use nCompiler operators in models (e.g., dinvgamma).

What works and what does not work is documented extensively via dependent_package_tests/test-packaging.R. This includes a package that gives its users (a) output from running nFunctions/nClass methods, (b) nClass objects, and (c) nClass generators.

@perrydv and I discussed enhancing nCompile to inject nCompiler:: as needed for R execution and stripping out nCompiler:: during compilation. This seems like it would be a good idea and reasonably straightforward. However, given that import(nCompiler) is a standard, CRAN-approved dependency approach, I think it makes sense to leave this aside for a time closer to release or an enhancement in a later release.

I will file a separate issue to note the need for namespace resolution functionality in nFunction compilation.