Tex and solaris

[mebrooks]

I'm trying to get the package running on solaris while testing using the rhub package. I was getting errors about missing .sty files, so I added them to a new branch called tex_files. Now I get the error

#> Error: processing vignette 'model_evaluation.Rnw' failed with diagnostics:
10413#> Running 'texi2dvi' on 'model_evaluation.tex' failed.
10414#> LaTeX errors:
10415#> ! Package siunitx Error: Support package expl3 too old.
10416#> See the siunitx package documentation for explanation.

I tried replacing sinunitx.sty with an older one that says

\RequirePackage{expl3}[2015/09/11]

but I still get the error. I don't know how to update expl3 on DTU's HPC without asking for help. Also, I wonder what version rhub / solaris is using for the testing and is there a way to control that.

Alternatively, can the vignettes be simplified so that they don't need sinunitx.sty?

Here's the output from the latest test.

[bbolker]

96250d8073427b41 tries to address this. siunitx.sty is needed for some huxtable functionality, but not needed for the stuff we're doing.

However, apparently not working yet (I haven't gotten the e-mail back from r-hub yet ...)

check_on_solaris(email = "bbolker@gmail.com")
─  Building package
Error: Build failed, unknown error, standard output:
* checking for file ‘glmmTMB/DESCRIPTION’ ... OK
* preparing ‘glmmTMB’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... ERROR
--- re-building ‘covstruct.rmd’ using rmarkdown
--- finished re-building ‘covstruct.rmd’

--- re-building ‘mcmc.rmd’ using rmarkdown
--- finished re-building ‘mcmc.rmd’

--- re-building ‘miscEx.rmd’ using rmarkdown
--- finished re-building ‘miscEx.rmd’

--- re-building ‘parallel.Rmd’ using rmarkdown
--- finished re-building ‘parallel.Rmd’

--- re-building ‘sim.rmd’ using rmarkdown
--- finished re-building ‘sim.rmd’

--- re-building ‘troubleshooting.rmd’ using rmarkdown
--- finished re-building ‘troubleshooting.rmd’

--- re-building ‘glmmTMB.Rnw’ using knitr
Loading required package: stats4
Warning in qt((1 - level)/2, df) : NaNs prod
> 

[mebrooks]

This is weird. Now r-hub is complaining about DHARMa being unavailable.

#> * checking package dependencies ... ERROR
10298#> Package suggested but not available: ‘DHARMa’
10299#> The suggested packages are required for a complete check.
10300#> Checking can be attempted without them by setting the environment
10301#> variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
10302#> See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’
10303#> manual.

[mebrooks]

Does this mean we add _R_CHECK_FORCE_SUGGESTS_ = false to src/Makevars?

[bbolker]

It would be a reasonable workaround, but I think you would need

check_on_solaris(env_vars = c(_R_CHECK_FORCE_SUGGESTS="false"))

[bbolker]

It could be a pain to test without DHARMa present, as at least the "model evaluation" vignette won't build. (This is allowed by CRAN rules - all tests and examples should run if "suggested" packages are missing, but it's not required to be able to build the vignettes with suggested packages missing ...)

If all else fails I say we should submit without further testing - document what we've done to try to test.

Also possible that the missingness of DHARMa on r-hub is a transient problem ... ?

[mebrooks]

The error with DHARMa on Solaris is circular! Its check gets

Error: processing vignette 'DHARMa.Rmd' failed with diagnostics:
there is no package called 'glmmTMB'
--- failed re-building ‘DHARMa.Rmd’

I pasted check_on_solaris(env_vars = c(_R_CHECK_FORCE_SUGGESTS="false")) into src/Makevars and reran the check, but I still get the same error. From what I can tell, the "Writing R Extensions" manual doesn't say how to set environmental variables to be used during checks.

[bbolker]

You misunderstood my suggestion. Those environment variables don't belong in src/Makevars. I'm currently trying this:

library(rhub)
check_on_solaris(env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false"), email = "bbolker@gmail.com")

but I suspect that, without DHARMa available, it's going to fail unless we also tell it not to try to build/test vignettes.

[bbolker]

Failed, as predicted. Now trying

check_on_solaris(env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false"), 
   email = "bbolker@gmail.com", check_args = "--no-vignettes")

[bbolker]

PS still doesn't work, even with

rhub::check_on_solaris(env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false"), 
     email = "bbolker@gmail.com", 
     check_args = "--no-vignettes --ignore-vignettes --no-build-vignettes")

Either I have the syntax for check_args wrong, or ...
Next try is going to be building the tarball locally and sending it to rhub for checking ... maybe that will skip the problematic step?

[bbolker]

Trying one more time: (1) including --no-manual in check_args (this is part of the check_on_solaris() default); (2) enclosing the check_args values in another set of (single) quotes (this isn't clearly documented, but appears in the check_on_solaris() defaults); (3) making sure that DHARMa is installed locally (so that if the first step is to build the package locally before sending it off, this will work).

rhub::check_on_solaris(env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false"), 
      check_args = "'--no-vignettes --ignore-vignettes --no-build-vignettes --no-manual'",
      email = "bbolker@gmail.com")

Now it's running, at least ...

[florianhartig]

Hey guys, I'm just checking on you -it's a complete hunch, but CRAN wrote to me about problems with glmmTMB, and I misunderstood them as saying that I should move glmmTMB from suggest to import (which I did with an update yesterday), which could be related to your problem with DHARMa, I don't know.

[mebrooks]

@mmaechler can you offer any advice? You're the CRAN expert.

[mebrooks]

If it works with rhub::check_on_solaris(, check_args =) we still need to get that into the CRAN checks. That's why I thought we needed to use src/Makevars to set environmental variables. Like I said, I can't find that info in the manual. Maybe I'll ask the developer list.

[mmaechler]

Mollie Brooks writes:

@mmaechler can you offer any advice? You're the CRAN expert.

Well, I know Uwe well ... so I would ask @.*** for advice in a polite e-mail.

As you may know, this week is useR! 2021, and I'm pretty busy because of that.... so I can't spend time on this at least not before Thursday.

Martin

[mebrooks]

We have to correct this before 2021-07-08 to keep it on CRAN. So that gives us 1 day.

[bbolker]

My understanding of where we are:

• glmmTMB is failing to install/check on Solaris because of a type/casting ambiguity, which we fixed in 5f266765a635e0
• testing on rhub, we found a problem with TeX packages which we fixed in 96250d807
• we are now running into problems testing on rhub because DHARMa is (at least temporarily) absent.
  • We "Suggest" DHARMa. That means that all examples and tests must run successfully if DHARMa is missing. I guess that also means that the vignettes have to run successfully if any suggested packages are missing. I've modified model_evaluation.Rnw so that it doesn't need DHARMa.

We do not need to enforce _R_CHECK_FORCE_SUGGESTS=false. If CRAN wants to run with the variable 'true', then they need all the suggested packages installed.

I'm trying again on rhub, with _R_CHECK_FORCE_SUGGESTS=false, but without all of the vignette-disabling switches (now that I have tried to make the model evaluation vignette DHARMa-safe). It would also be worth checking whether the package passes R CMD check without DHARMa available (i.e. build the package, then remove.packages("DHARMa"), then run R CMD check --as-cran

[mebrooks]

Before you wrote back, I tried

rhub::check_on_solaris(env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false"),
check_args = "'--no-vignettes --ignore-vignettes --no-build-vignettes --no-manual'")

I got

  Package suggested but not available: ‘DHARMa’

   The suggested packages are required for a complete check.
   Checking can be attempted without them by setting the environment
   variable _R_CHECK_FORCE_SUGGESTS_ to a false value.

   See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’
   manual.

with more output here.

[bbolker]

Two questions:

1. are you sure you included/got the env_vars = c("_R_CHECK_FORCE_SUGGESTS"="false") incantation right? I'm running on rhub and it's getting farther than that.
2. It's a little bit worrisome that this shows up in the install logs:

glmmTMB.cpp:385:47: error: call of overloaded ‘pow(int, int)’ is ambiguous 8841#> int rank = (2*p + 1 - sqrt(pow(2*p + 1, 2) - 8*nt) ) / 2 ;

as this is the old code, not the updated version ...

[mebrooks]

Yes, I copied and pasted my call to rhubin R. I'm on the branch tex_files. I'm still running R 4.x on the cluster. I can't imagine what's going on.

[bbolker]

trying again here. You're right, it fails after 10K+ lines of installing packages:

10301#> Package suggested but not available: ‘DHARMa’ 10302#> The suggested packages are required for a complete check. 10303#> Checking can be attempted without them by setting the environment 10304#> variable _R_CHECK_FORCE_SUGGESTS_ to a false value.

I have no idea why the env_vars setting doesn't seem to be honored ... ?

[bbolker]

I might be making a tiny bit of progress. This issue suggests

rhub::check(platform = "solaris-x86-patched", env_vars = c("_R_CHECK_FORCE_SUGGESTS_" = "false"))

(rather than check_on_solaris()), and this time I get as far as the error below. I've made an attempt to work around this, will try again

---

10427#> Error: processing vignette 'model_evaluation.Rnw' failed with diagnostics: 10428#> Running 'texi2dvi' on 'model_evaluation.tex' failed. 10429#> LaTeX errors: 10430#> ! Missing \endcsname inserted. 10431#> 10432#> \egroup 10433#> l.268 \begin 10434#> {threeparttable} 10435#> ! Missing \endcsname inserted. 10436#> 10437#> \egroup 10438#> l.268 \begin 10439#> {threeparttable} 10440#> ! Extra }, or forgotten \endgroup. 10441#> \egroup 10442#> 10443#> l.268 \begin 10444#> {threeparttable} 10445#> ! Extra \endcsname. 10446#> \reserved@a ...n@line }\csname \egroup \endcsname 10447#> 10448#> l.268 \begin 10449#> {threeparttable} 10450#> ! LaTeX Error: \begin{centerbox} on input line 267 ended by \end{threeparttable 10451#> }. 10452#> See the LaTeX manual or LaTeX Companion for explanation. 10453#> Type H for immediate help. 10454#> ! LaTeX Error: \begin{table} on input line 266 ended by \end{centerbox}. 10455#> See the LaTeX manual or LaTeX Companion for explanation. 10456#> Type H for immediate help. 10457#> ... 10458#> ! Missing } inserted. 10459#> 10460#> } 10461#> l.317 \end{threeparttable}\par\end{centerbox} 10462#> 10463#> ! Extra }, or forgotten \endgroup. 10464#> \color@endbox ->\color@endgroup \egroup 10465#> 10466#> l.319 \end{table} 10467#> 10468#> ! LaTeX Error: \begin{knitrout} on input line 252 ended by \end{table}. 10469#> See the LaTeX manual or LaTeX Companion for explanation. 10470#> Type H for immediate help. 10471#> ... 10472#> ! LaTeX Error: \begin{document} ended by \end{knitrout}. 10473#> See the LaTeX manual or LaTeX Companion for explanation. 10474#> Type H for immediate help. 10475#> ... 10476#> ! Extra \endgroup. 10477#> \endgroup 10478#> 10479#> l.320 \end{knitrout} 10480#> 10481#> --- failed re-building ‘model_evaluation.Rnw’ 10482#> SUMMARY: processing the following file failed: 10483#> ‘model_evaluation.Rnw’ 10484#> Error: Vignette re-building failed.

[bbolker]

argh, missing underscore at the end of _R_CHECK_FORCE_SUGGESTS_!

[mebrooks]

Based on reading a bit more about writing R extensions, I'm guessing that we're going to need a configure file to get past the checks on CRAN. So would it make sense to go ahead and test with it now, instead of the arguments to rhub::check?

[bbolker]

I honestly don't see why we need to do that (again, _R_CHECK_FORCE_SUGGESTS_ is independent of/handled at a different step from src/Makevars; the latter is only relevant to C++ compilation). Judicious skipping of vignette stuff on Solaris should do it, I think. I think we're getting closer (it's too bad that it takes 30+ minutes to do a single round of testing on r-hub/solaris ... current round here)

[mebrooks]

I'm confused because I don't think CRAN will run rhub::check(platform = "solaris-x86-patched", env_vars = c("_R_CHECK_FORCE_SUGGESTS_" = "false")) (or something like it) if we ask them to. So how do we tell CRAN to use the right environmental variables? I found this r-package-devel email that indicates that we "have no control over what env vars are set on cran machines".

EDIT: I also haven't learned how to tell CRAN to do things like

check_args = "'--no-vignettes --ignore-vignettes --no-build-vignettes --no-manual'"

[bbolker]

It is not our problem if packages that are in good status on CRAN (i.e. not archived or otherwise generally missing) are unavailable on a particular CRAN testing platform. The CRAN maintainers can either

• test with _R_CHECK_FORCE_SUGGESTS_ = false and yell at us if we have used any missing packages unconditionally or
• test with _R_CHECK_FORCE_SUGGESTS_ = true and make sure that all suggested packages are installed.

It would be unreasonable to reject package A because it has a Suggests: dependency on package B that is in good standing on CRAN but is not available on a particular CRAN testing platform, as long as package A only uses package B conditionally.

At least, that's my understanding of the rules.

If you want I could ask about this on r-package-devel.

This is what the CRAN policies say:

Packages on which a CRAN package depends should be available from a mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ fields are not from such a repository, where to obtain them at a repository should be specified in an ‘Additional_repositories’ field of the DESCRIPTION file (as a comma-separated list of repository URLs) or for other means of access, described in the ‘Description’ field.

A package listed in ‘Suggests’ or ‘Enhances’ should be used conditionally in examples or tests if it cannot straightforwardly be installed on the major R platforms. (‘Writing R Extensions’ recommends that they are always used conditionally.)

[mebrooks]

Yes, I'm going to sleep soon. If you feel like it could help to ask r-package-devel then I think that's a great idea.

[bbolker]

Success, sort of.

This r-hub test passes with two NOTEs, one about DHARMa being unavailable (of course) and one about the installed package size (which we expect and can be excused for).

[florianhartig]

I assume that the DHARMa problem is indeed a circular dependency error, because the current DHARMa version on Solaris fails because it depends on glmmTMB. I am currently preparing a DHARMa version without glmmTMB to solve this problem!

[bbolker]

I think we're good to go. (Uwe Ligges confirmed my suggestion above on r-package-devel ...)

[florianhartig]

Hey guys, good on you for the all the work - just to let you know that I have for now submitted a new version of DHARMa for which the glmmTMB import was removed completely. If glmmTMB is back on CRAN without errors, I will submit another update with glmmTMB moved back into suggest and ideally used conditionally, but in the short time it was impossible for me to ensure that every use of glmmTMB is conditionally and also recognised as such by CRAN checks (which is what CRAN wanted from me).

I wonder if this new situation resolves the "Package suggested but not available: ‘DHARMa’" notes that you received?