namespace/lookup issues if using nimbleHMC in third-party package via suggests (possibly imports?)

[paciorek]

For reasons discussed here, nimble-using packages need nimble in requires.

A related issue is that if a 3rd package wants to use nimbleHMC, it cannot use nimbleHMC::configureHMC based on suggests and requireNamespace(nimbleHMC) because sampler_NUTS cannot be found from within nimbles MCMC configuration steps.

A work-around might be that in nimbleHMC, when we invoke addSampler we do so with nimbleHMC::sampler_NUTS (e.g.) rather than "NUTS". We do in places in nimble use nimble::, so I think this can pass CRAN but not entirely sure.

I suspect similar issues would arise with addHMC, buildHMC, nimbleHMC.

And more generally, once we have a proposed solution, it would be good to exercise all of nimbleHMC functionality from a 3rd package with nimbleHMC in suggests to test things.

Now if a 3rd package has nimbleHMC in imports, it might work if configureHMCandsampler_NUTSare tagged withimportFrominNAMESPACE`. I haven't checked but this would be worth an experiment.

I am happy to investigate, but also raising this for @danielturek to consider/weigh in on.

Tagging @kenkellner given this arose from a nimbleEcology issue.

[danielturek]

@paciorek Thanks for tagging me. I agree, whatever solution we decide on, it would be good to do the test you mentioned, writing a 3rd package using nimbleHMC functions, while having nimbleHMC in suggests and see if it works.

If you want me to make changes to nimbleHMC to preface things with nimbleHMC::, I could make those changes. I'd also make sure to handling the printing of samplers (if that's not already taken care of), to maintain things looking reasonable. Apologies, but I'm not going to jump into my own investigation of this right now, but I'm happy to help with the code, if we identify a path forward.