WISH: install.packages had option to throw error code if install fails about wishlist-for-r

[HenrikBengtsson]

A reproducible example is:

> install.packages("DeepBlueR", repos = "https://bioconductor.org/packages/3.18/bioc")
Installing package into '/home/alice/R/x86_64-pc-linux-gnu-library/4.3-CBI-gcc11'
(as 'lib' is unspecified)
trying URL 'https://bioconductor.org/packages/3.18/bioc/src/contrib/DeepBlueR_1.27.0.tar.gz'
Content type 'application/x-gzip' length 1701602 bytes (1.6 MB)
==================================================
downloaded 1.6 MB

* installing *source* package ‘DeepBlueR’ ...
** using staged installation
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
status 
 "503" 
Error in xml.rpc(deepblue_options("url"), "list_column_types", user_key) : 
  Problems
Error: unable to load R code in package ‘DeepBlueR’
Execution halted

ERROR: lazy loading failed for package ‘DeepBlueR’
* removing ‘/home/alice/R/x86_64-pc-linux-gnu-library/4.3-CBI-gcc11/DeepBlueR’

The downloaded source packages are in
	'/tmp/alice/Rtmp6QSSLu/downloaded_packages'
Warning message:
In install.packages("DeepBlueR") :
  installation of package 'DeepBlueR' had non-zero exit status

A refined alternative to withCallingHandlers(warning = stop), would be to inspect the condition message and only escalate to an error if it matches the above message. Here's a non-internationalized proof-of-concept;

globalCallingHandlers(warning = function(w) {
  msg <- conditionMessage(w)
  if (grepl("package .* is not available for this version of R", msg) || 
      grepl("installation of package .* had non-zero exit status", msg)) {
    stop(paste("[WARNING->ERROR]", msg), call. = conditionCall(w))
  }
})

With this global handler in place, the warning is now escalated to an error:

> install.packages("DeepBlueR", repos = "https://bioconductor.org/packages/3.18/bioc")
Installing package into ‘/home/henrik/R/ubuntu22_04-x86_64-pc-linux-gnu-library/4.3-CBI-gcc11’
(as ‘lib’ is unspecified)
trying URL 'https://bioconductor.org/packages/3.18/bioc/src/contrib/DeepBlueR_1.27.0.tar.gz'
Content type 'application/x-gzip' length 1701602 bytes (1.6 MB)
==================================================
downloaded 1.6 MB

* installing *source* package ‘DeepBlueR’ ...
** using staged installation
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
status 
 "503" 
Error in xml.rpc(deepblue_options("url"), "list_column_types", user_key) : 
  Problems
Error: unable to load R code in package ‘DeepBlueR’
Execution halted
ERROR: lazy loading failed for package ‘DeepBlueR’
* removing ‘/home/henrik/R/ubuntu22_04-x86_64-pc-linux-gnu-library/4.3-CBI-gcc11/DeepBlueR’
Error in (function (w)  : 
  [WARNING->ERROR] installation of package ‘DeepBlueR’ had non-zero exit status
> 

To make this agile to language settings, the warning message needs to be compared to the expected string pattern in the specific language.

[gaborcsardi]

We did this in remotes with options(warn = 2), but then we had to remove it because install.packages() throws warnings for all kind of things, e.g. if there are no binary packages in some configured repository. So successful installations errored as well.

[sneumann]

+1 from my side as well, it is quite confusing if your docker build succeeds, only to realise that the packages I want in there are, in fact, not in there. If that is a large build with many packages, I want the build to break as early as possible and not burn useless CPU cycles. Yours, Steffen

[HenrikBengtsson]

If someone has the spare cycles, I would recommend posting a proposal to R-devel on having install.packages() produce an error if one or more packages fail to install. Hopefully there will be some useful discussion around this, and possibly even a change in behavior.

PS. FWIW, I don't really see why install.packages() shouldn't always give an error when it fails, just like all other functions in R. The one case where I can see we want it to be liberal, is when installing Suggests:ed packages. It might be that everyone, including R Core, agrees and this is a quick update.