renv::install(type = "binary") still using source?

[mthieu]

Hi there,

I've been transitioning my projects over to renv and in general have been pleased with the experience. I ran into the following hiccup while updating packages.

I noticed that renv::update() fails out when attempting to compile some packages from source. I couldn't find an option to force update() to update from binary where possible, so I went in by hand with renv::install() to install the offending packages (at least the ones I encountered).

Then, when using renv::install(pkg, type = "binary"), I noticed that for these offending packages, setting type = "binary" didn't seem to change the CRAN package link that renv was installing from.

For example:

renv::install("mgcv", type = "source")
Retrieving 'https://cran.rstudio.com/src/contrib/mgcv_1.8-33.tar.gz' ...
	OK [file is up to date]
Installing mgcv [1.8-33] ...
	FAILED
Error installing package 'mgcv':
================================
 errors here

renv::install("mgcv", type = "binary")
Retrieving 'https://cran.rstudio.com/src/contrib/mgcv_1.8-33.tar.gz' ...
	OK [file is up to date]
Installing mgcv [1.8-33] ...
	FAILED
Error installing package 'mgcv':
================================
same errors here

renv appears to be retrieving the source tarball in both cases.

I encountered the problem with the following packages:

• binary version is older than source:
  • conquer, mgcv
• binary version is equal to source:
  • data.table, rstanarm

I was able to get these packages to install by copying the direct link to the binary, e.g. renv::install("https://cran.rstudio.com/bin/macosx/contrib/4.0/mgcv_1.8-32.tgz").

While I don't know how update() works under the hood, it does seem to be correctly sourcing the binary links for most packages, so I'm guessing the default behavior is indeed to update from binary where possible. renv seems not to be detecting binary links for these packages in particular, either for install() or update(). Not sure what's happening with some of these guys!

Is there something I should be changing, or is this an issue for others as well?

[kevinushey]

I believe this issue should be resolved in the development version of renv. Can you try installing it, with e.g.

renv::install("rstudio/renv")

and let me know if you have better luck after?

[mthieu]

Yep, the GitHub version appears to work! After installing from GitHub and restarting my R session, I decided to use data.table to test the new installation setup. I ran remove("data.table") and then purge("data.table") to force installation from the Internet and not from cache. Then:

> renv::install("data.table", type = "binary")
Retrieving 'https://mran.microsoft.com/snapshot/2020-04-24/bin/macosx/el-capitan/contrib/3.6/data.table_1.12.8.tgz' ...
	OK [downloaded 2 Mb in 1.2 secs]
Installing data.table [1.12.8] ...
	OK [installed binary]

Works, hooray! I notice that the particular MRAN snapshot path (Mac OS X El Capitan, R 3.6) is sourcing (at least in this case) the n-1th version of data.table binary, as CRAN has data.table@1.13.0 available for binary as well. Not a breaking issue on my machine, but it might be nice to get the newest binary version if it's available?

[kevinushey]

Are you sure binaries of data.table 1.13.0 are available on CRAN for R 3.6? If I look here:

https://cran.r-project.org/bin/macosx/el-capitan/contrib/3.6/

I see that 1.12.8 is available (while 1.13.0 is available for R 4.0.2).

I think the only minor issue here was that renv downloaded the package from MRAN when the same copy of that package was actually available from the current CRAN repository.

[mthieu]

Oh whoops, you're super right. I was looking in the "newest release" section, which obviously is for R 4.0.x at the moment. Didn't realize that renv was using the system R version to detect which package version to download. I realize now that it was a feature, not a bug!

[kevinushey]

Awesome!

And I'm also happy to say that renv 0.12.0 is now available on CRAN, so this fix should now be available in the latest release.