Empty check dirs and error on revdep_details

[vspinu]

Some packages in the revdep_summary are labeled E and the package's folder within checks is empty:

✔ AdhereR 0.1.0                          ── E: 0     | W: 0     | N: 0    
✔ aemo 0.2.0                             ── E: 0     | W: 0     | N: 0    
E alfred                                 ── E: ?/?   | W: ?/?   | N: ?/?  
E alphavantager                          ── E: ?/?   | W: ?/?   | N: ?/?  
✔ antaresRead 1.1.4                      ── E: 0     | W: 0     | N: 0    
E antaresViz                             ── E: ?/?   | W: ?/?   | N: ?/?  
E aoristic                               ── E: ?/?   | W: ?/?   | N: ?/?  
✔ APSIM 0.9.2                            ── E: 0     | W: 0     | N: 0    
✔ apsimr 1.2                             ── E: 0     | W: 0     | N: 1    
...

and

> revdep_details(revdep = "alfred")

══ Reverse dependency check ═════════════════════════════════════════ alfred  ══

Error in switch(x$status, `+` = green("OK"), `-` = red("BROKEN"), i = red("INSTALL FAILURE"),  : 
  EXPR must be a length 1 vector

This is on recent R-devel and revdepcheck * 1.0.0.9000 2017-10-07 Github (r-lib/revdepcheck@2081161).

[hadley]

It would be good to figure out why the checks aren't being run. Do you see any other errors?

[vspinu]

Nope. Everything is silent as far as I can judge. Nothing is printed to stdout. The corresponding checks sub-folders are empty.

[bbolker]

I have a similar issue (at least I think it's similar; if it's judged different I can open a new/separate issue or you can direct me to somewhere else appropriate ...)

This happens a lot in my checks (right now I'm trying to set up a new platform for revdep-checking lme4, and out of the first 12 packages attempted (out of 229), 8 have failed:

E afex                                   ── E: ?/?   | W: ?/?   | N: ?/?  
E agRee                                  ── E: ?/?   | W: ?/?   | N: ?/?  
E agridat                                ── E: ?/?   | W: ?/?   | N: ?/?  
E AICcmodavg                             ── E: ?/?   | W: ?/?   | N: ?/?  
E ANOM                                   ── E: ?/?   | W: ?/?   | N: ?/?  
✔ aod 1.3                                ── E: 0     | W: 0     | N: 0    
✔ aods3 0.4-1                            ── E: 0     | W: 0     | N: 0    
✔ ArfimaMLM 1.3                          ── E: 0     | W: 0     | N: 0    
✔ arm 1.9-3                              ── E: 0     | W: 0     | N: 0    
E ARTool                                 ── E: ?/?   | W: ?/?   | N: ?/?  
E AzureML                                ── E: ?/?   | W: ?/?   | N: ?/?  
E bapred                                 ── E: ?/?   | W: ?/?   | N: ?/?  

I get a slightly different error from revdep_details():

Error in if (nrow(rows) == 0) { : argument is of length zero

I'm 99% sure that these cases are ones where something went wrong in the installation of the package.

• For example, when I manually install.packages("ANOM"), I get an install issue with the upstream dependency MCMCpack (not sure what the issue is here; it might be some kind of race condition, because MCMCpack takes a long time to build. (Indeed I think this is the case, because after re-installing MCMCpack I can install MCPAN and then ANOM ...)
• In the case of agRee, the problem is an upstream dependency (agRee -> rjags -> JAGS).

It would be super helpful if there were a way to report on/diagnose these sorts of problems without having to manually install.packages() and see what goes wrong.

I have a hazy memory that a previous version of revdepcheck kept the install directories/logs around, so that one could poke around in them for clues ...

[gaborcsardi]

Yes, we should definitely keep the installation logs for the packages that failed to install, and put them in the DB.

[bbolker]

It would be a really good start to keep any trace around of the packages that completely failed to be checked. I'm having a hard time sorting this out after the revdep_check() run is over, because it looks like packages that failed to install are instead reported as being OK. I think I'm going to have to capture a snapshot of the problems before the run ends - it looks like the database gets cleaned up at the end of the run?

Once again, to set up a test case I think one would need to make a small fake repo. On repo: package A version 0.1, package B (depends on package A and on a non-existent package C, so it can never be successfully installed). On system: package A version 0.2.

[gaborcsardi]

Yes, agreed, and I'll fix this soon.

[ghost]

As of today with revdepcheck * 1.0.0.9001 95fa560, I see

Error in if (nrow(rows) == 0) { : argument is of length zero

with, e.g., package broom.

[bbolker]

bump/cross-reference to #256 ... ?

[bbolker]

For what it's worth I still get this message from time to time. e.g. right now running lme4 revdep checks: so far BGData, car, DClusterM, broom (4/85 packages checked so far) have failed with status "E:?/0", revdep_details() reports the same error as above ("Error in if (nrow(rows) == 0) { : argument is of length zero"), and I can't see anything suspicious at all (or anything that gives me any more information about what to troubleshoot) in the 00check.log/00install.log files under the relevant revdep/checks/<pkg>/(new|old) directories ...

Unlike with my previous problems, running install.packages() manually for the problematic packages doesn't reveal any obvious problems ... manually grepping for ERROR doesn't find anything either ...

I'm running this on 20 cores, I wonder if there's a possibility of some kind of race condition?

[gaborcsardi]

I'm running this on 20 cores, I wonder if there's a possibility of some kind of race condition?

I always run it with 8-16 cores, and have never seen this, so it is unlikely.

I suspect that you are on Linux?

[bbolker]

Yes.

R Under development (unstable) (2023-02-22 r83890)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;  LAPACK version 3.10.0