revdepcheck icon indicating copy to clipboard operation
revdepcheck copied to clipboard

Empty check dirs and error on `revdep_details`

Open vspinu opened this issue 8 years ago • 11 comments

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).

vspinu avatar Oct 07 '17 22:10 vspinu

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

hadley avatar Oct 16 '17 15:10 hadley

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

vspinu avatar Oct 16 '17 15:10 vspinu

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 ...

bbolker avatar Nov 08 '17 21:11 bbolker

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

gaborcsardi avatar Nov 09 '17 01:11 gaborcsardi

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.

bbolker avatar Nov 15 '17 03:11 bbolker

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

gaborcsardi avatar Nov 15 '17 09:11 gaborcsardi

As of today with revdepcheck * 1.0.0.9001 r-lib/revdepcheck@95fa560, I see

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

with, e.g., package broom.

ghost avatar May 20 '20 13:05 ghost

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

bbolker avatar Sep 23 '20 23:09 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?

bbolker avatar Mar 12 '23 21:03 bbolker

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?

gaborcsardi avatar Mar 12 '23 21:03 gaborcsardi

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

bbolker avatar Mar 12 '23 22:03 bbolker