Highlight packages that error early on

[hadley]

I'm not exactly sure what "early on" means, but sometimes issues with system dependencies (or cached packages) cause R CMD check to fail early for both CRAN and dev versions, causing a false negative (since the errors match).

e.g. from a recent gargle revdepcheck by @jennybc:

✓ gmailr 1.0.0                           ── E: 0     | W: 0     | N: 0            
✓ boxr 0.3.5                             ── E: 0     | W: 0     | N: 0            
✓ bigrquery 1.2.0                        ── E: 1     | W: 0     | N: 0            
I googleCloudStorageR 0.5.1              ── E: 1     | W: 0     | N: 0            
✓ googleAuthR 1.2.1                      ── E: 0     | W: 0     | N: 0            
✓ googledrive 1.0.0                      ── E: 1     | W: 0     | N: 0            
✓ googlesheets4 0.1.1                    ── E: 1     | W: 0     | N: 0            

bigrquery, googldrive, and googlesheets4 all failed on both with

* installing *source* package 'googleCloudStorageR' ...
** package 'googleCloudStorageR' successfully unpacked and MD5 sums checked
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/Users/jenny/rrr/gargle/revdep/library.noindex/gargle/old/openssl/libs/openssl.so':
  dlopen(/Users/jenny/rrr/gargle/revdep/library.noindex/gargle/old/openssl/libs/openssl.so, 6): Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
  Referenced from: /Users/jenny/rrr/gargle/revdep/library.noindex/gargle/old/openssl/libs/openssl.so
  Reason: image not found
Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
Execution halted
ERROR: lazy loading failed for package 'googleCloudStorageR'
* removing '/Users/jenny/rrr/gargle/revdep/checks.noindex/googleCloudStorageR/old/googleCloudStorageR.Rcheck/googleCloudStorageR'

(which turned out to be a problem with an old cached package, but should've caused more obvious failures here)

[bbolker]

+1000. I'm having huge headaches getting a revdepcheck pipeline spun up - first with a badly set up cache, then with dozens of packages that fail to install because some system-level dependency is missing (gmp, gdal, geos, imagemagick, v8, etc etc etc) ... the capability to get a streamlined report of which packages failed to install, and why, would be amazingly useful. I am resorting to this strategy:

find lme4/revdep/checks -wholename "*/new/*.log" -exec grep -l "Status: . ERROR" {} \; | sort

to find the problematic packages (any package that ERRORs with the old version of the package is probably caused by a configuration problem, not by an actual package problem - unlikely that a CRAN version of a downstream package would error with the CRAN version of the package ... ?)

2. Examine the logs (or pipe results from previous to grep) to find unavailable packages

3. Figure out why the packages were unavailable by attempting to install them

4. Install whatever bits are missing

5. Rinse, repeat ...

This is on a CentOS system, I guess could be made easier if there were binary packages to point to? (I'm aware of that for Debian/Ubuntu, but ...)

[bbolker]

PS: I could hack this myself, but it would be very convenient to have a small utility that automatically marked packages in this category as still needing checking (so one could iteratively fix upstream problems, retest only on the subset of packages that still failed, etc)

[MLopez-Ibanez]

Same as #219. There are several reports about failures to install being unreported.