error: could not find function "getNimbleOption"

[Brook Milligan]

I am working on a package with a function that calls nimble::nimbleModel(). In this case, the nimble package is an Import, so (as I understand it) my functions can call nimble::foo() with the namespace qualifier and expect success. However, I am getting the following error when I test the function with devtools::test():

# Error ('test-nimble_test.R:6:3'): nimble_test works
# Error in `getNimbleOption("determinePredictiveNodesInModel")`: could not find function "getNimbleOption"
# Backtrace:
#. ...
# 5. └─nimble::nimbleModel(...)
# 6. └─md$newModel(...)
# 7. └─nimble (local) modelClass(name = modelName)
# 8. └─global newClass(inputList = inputList, name = name)
# 9. └─methods::new(`<chr>`, ...)
# 10. ├─methods::initialize(value, ...)
# 11. └─methods::initialize(value, ...)
# 12. └─.Object$initialize(...)
# 13. └─init_isDataEnv()

I have not been able to discover in documentation anything about the function getNimbleOption(), so I am wondering if this is something internal and why it is not found when other nimble functions are.

I can fix this with a call to library(nimble) in my package, but (again as I understand it) that should not be necessary and indeed R CMD check complains about that.

Can you give any direction regarding how this should be resolved?

Thanks a lot for your help.

Cheers,
Brook

[Chris Paciorek]

Hi Brook,

Yes, that should work. It looks like we need to tweak how `getNimbleOption` is called when the model is built. I'll plan to fix this in our release of version 1.4.0 which should occur this week or next.

-chris

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/nimble-users/E04E6D01-49BE-46EE-AAB5-D5A97ED5F6A3%40biology.nmsu.edu.

[Chris Paciorek]

Hi Brook,

I wrote a bit too hastily. We can tweak things to make this work somewhat, but we can't tweak things so that everything works. We have a long discussion of this issue.

The key text is that GitHub issue discussion says:

"""

The status of this is that dependent packages generally need to have nimble in Depends (rather than in Imports) in NAMESPACE. The result is that nimble is attached when the nimble-relying package is loaded, and therefore all objects in the nimble namespace can be found at the user level. [CRAN doesn't encourage this, but it is allowed] (https://cran.r-project.org/doc/manuals/R-exts.html#Package-Dependencies).

This is needed because the node functions (i.e., simulate, calculate, etc.) for model nodes are part of generated reference classes that don't live in the nimble namespace, but those node functions use functions in the nimble namespace such as nimSwitch and distributions that are not native R distributions (such as dinvgamma). Such functions can't be found unless the nimble package is actually loaded, for which Depends rather than Imports is needed in NAMESPACE.

"""

What could go wrong for certain models is that calls to `calculate` and `simulate` on the uncompiled model will give an error. E.g., it would occur if a model has a `dinvgamma` declaration, since the model is created as part of the user's objects and `dinvgamma` can only be found in the nimble namespace but the call to `dinvgamma` in the code we generate doesn't have "nimble::dinvgamma' (having that "nimble::" be inserted would be a much larger project in the nimble compiler). Things should work fine for compiled operation, so I think whether the tweaks would work for you depends on what you end up doing with nimble in your package. We are in the middle of rewriting the nimble compiler, and I think that considerations like this may be handled differently with the rewrite.

I think we probably want to make the tweaks anyway, but I wanted to let you know of the larger context and that you may still need to use `Depends` even with the tweaks.

-chris

[Brook Milligan]

Hi Chris,

Thanks for the clarification. It helps to understand why this doesn’t work.

As for my package, I’m now not certain what is required besides the Depends: part.

Suppose I have a package (mypkg) with a function foo() that calls nimble::bar().

Should my *.R files include “library(nimble)”? Should the examples in the documentation include “#’ library(nimble); foo()”?

From a user perspective, if someone calls “mypkg::foo()” in their own script will the Depends: be enough?

What about if they do “library(mypkg); foo()”? Is the Depends: enough?

It seems that there are a few use cases (did I miss any?) and I don’t really understand how they all interact with getting nimble calls to work successfully.

Thanks for any help you can offer.

Cheers,
Brook

[Chris Paciorek]

Hi Brook,

You should only need Depends plus `import(nimble)` in NAMESPACE. You won't need `nimble::` and you won't need `library(nimble)`.

If a user does `mypkg::foo` instead of `library(mypkg); foo()`, I think it may not work because the objects in the nimble namespace won't be available if `mypkg` (and therefore `nimble` via Depends) is not attached.

-chris