restore() shoud not fail if only one package installation fails

[DanChaltiel]

Hi,

I'm painfully trying to use renv in a quite restricted IT context, with little control over my environment.

I'm sharing renv.lock on the cloud (renamed to renv.json because IT thought this was ransomware BTW) and I'm running renv::restore() to download my files back.

However, due to IT "not allowing downloading encrypted archives", some GitHub packages download always fail during untar:

Do you want to proceed? [Y/n]: y

# Downloading packages -------------------------------------------------------

- Downloading MASS from CRAN ...                OK [548.4 Kb in 0.61s]
- Downloading rpart from CRAN ...               OK [839 Kb in 0.33s]
- Downloading codetools from CRAN ...           OK [37.3 Kb in 0.031s]
- Downloading nlme from CRAN ...                OK [787.9 Kb in 0.53s]
- Downloading lattice from CRAN ...             OK [390.1 Kb in 0.2s]
- Downloading boot from CRAN ...                OK [231.3 Kb in 0.2s]
- Downloading DBI from CRAN ...                 OK [744.7 Kb in 0.22s]
- Downloading EDCimport from GitHub ...         OK [82.7 Kb in 3.7s]
Error in untar2(tarfile, files, list, exdir, restore_times) : 
  incomplete block on file

This failure was unfortunately expected, as even manual installation using remotes::install_github() fails for this particular package (not for all GitHub packages).

Though, wouldn't a warning be sufficient here, as this package not being available prevents all the many other packages to be installed?

I have no clue how I will manage to deal with this package, but I would think it should not make all the pipeline fail.

[kevinushey]

I empathize, but I'm not sure there's much I can reasonably do to accommodate hostile IT infrastructure in this scenario.

Are you able to manually download / retrieve the package in another way, and then place it into the renv cellar? See https://rstudio.github.io/renv/articles/package-sources.html#the-package-cellar for details.

[hadley]

Duplicate of #1109

[DanChaltiel]

@kevinushey thanks for your empathy :-)
I can manually download the file but the result is an aborted tarball that cannot be extracted, hence the error.
My point was not really about my precise case but more about wrapping each install process in some sort of try-catch so this error would not stop the whole installation.
I think I've seen a package ending in an ERROR status but it seems to be not untar-proof.