INLA dependent R packages on CRAN

[Rafael Lopes]

Hi all,

Leo (cc'ed and also a member of the list) and I have developed an R package for nowcasting that is built with INLA within. I've been trying to have the package published on CRAN but it never passses the test there, though it passes the tests locally. 

We would like any help or advice from any who have encountered such difficulties and how to best set the package so that it can be published on CRAN. The package is widely used by governments on producing nowcasting estimates given observation date and a notification date of the event, mainly infectious diseases cases of a notifiable disease of interest.

Package website: https://covid19br.github.io/nowcaster/

Package GitHub repo: github.com/covid19br/nowcaster

Best regards,

Rafael Lopes
lope...@gmail.com
rafael.lop...@yale.edu
Cellphone: +55(11) 97559-1996 (Brazil)

                  +1 475 300 8455 (USA)

Postdoc Yale,
PhD. in Physics

[Denis Rustand]

Hi Rafael,

You need to avoid having anything that requires INLA in the package check. You can wrap examples in "\donttest{}" and "requireNamespace("INLA")" as done line 170-197 here: github.com/DenisRustand/INLAjoint/blob/main/R/joint.R

You can test locally by removing or temporarily hiding INLA and run R CMD check --as-cran to verify if it passes.

Best,
Denis Rustand

[Finn Lindgren]

Hi,

There are a few general things to consider:

1. Any example or test using a Suggests: package needs to run only conditionally on that package being installed, so need to wrap in if (requireNamespace(“packagename”)) { … }

2. Long running examples need to be avoided or wrapped in \donttest{}. But such test may still be run by CRAN, so one needs to do step 1 regardless. (There’s also the nuclear option \donrun{}, but CRAN tends to really frown upon that if it’s applied to many examples in a new package, so avoid if you can, since it also prevents reverse dependency checks from noticing potential problems.)

3. Examples and tests need to limit use of parallelism to 1 or maybe 2 threads. This means that requireNamespace(“INLA”) is _not_ sufficient, as inla by default uses the maximum available number of cores. On CRAN this is usually not a direct problem in the inla context as _usually_ inla isn’t installed, but any package that your package relies on will be affected when they/we run reverse dependency checks. For example, the reverse dependency checks for fmesher can take over an hour on my system, when run in parallel. If inla is allowed to grab all cores for each of those parallel tests, it would overwhelm my laptop.

So please make sure that you limit parallelism (I’ll need to have a look at the package Denis referred to, as he didn’t mention this, and therefore that package might not play well with our reverse dependency checks…). Have a look at the examples and tests in the inlabru package, where I use bru_safe_inla() and local_bru_safe_inla() to automatically limit parallelism when run in testing contexts.  https://github.com/inlabru-org/inlabru/

I believe some other packages calls these functions from inlabru and/or have their own versions. (Calling from inlabru may be preferable, as that takes advantage of future fixes and improvement to the safe loading logic.)

If you use bru_safe_inla() in the functions that actually need to use inla (i.e. not just to guard an example) you need to supply multicore=TRUE, which means “allow inla multithreading, unless already limited by option settings”). See the code for inlabru::bru() for how it’s meant to be used.

Since inla usually isn’t installed on CRAN machines, safely conditionally loading inla would normally be sufficient, but to guard against falling victim to a CRAN test system having a broken inla installation, I guard all testthat tests that uses inla with skip_on_cran() in addition to the local_bru_safe_inla() guard.

Sometimes CRAN also runs “check if the package passes checks when suggested packages aren’t installed”. See the inlabru github actions for the approximate method for that I use to attempt to replicate that test.

Generally, inlabru has the most extensive inla tests and has been polished over time to play nicely with CRAN checks while still allowing the full range of tests to run outwith CRAN, both locally and in GitHub actions.

If the checking errors you encountered with CRAN aren’t related to the above points, you need to show what the actual errors were. Are they still available online? If so, supply the link.

Finn

On 22 Jun 2026, at 19:46, Rafael Lopes <lope...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/r-inla-discussion-group/CAFHzx877WJdiNtYKuuDtQGUx4q5nBKk%2BHXFro7fuiCY6VFnDYQ%40mail.gmail.com.