renv installation issues using remotes and local tar

Hi all.

I'm working in an airgapped environment where we have CRAN synced daily into a server we access.
I'm trying to set up a workflow but am encountering som unexpected issues with renv.

remotes::install_git vs renv::install

So, I've been using my usual remotes installation workflow when installing inhouse packages from our Gitea server using remotes::install_git. This works seeminly well, all the data in the lockfile for renv looks correct.
When I run renv::restore() during script run however, the installation for the packages from the remotes call fails, erroring with a message about the remoteSHA not existing. If I just switched to revn::install hoever, this worked just fine, even though the lock file looks kind of the same? (I couldnt spot the difference). I dont mind doing either or, just wanted to check if that was expected behaviour?

installing from tar and renv

Being airgapped means a crucial package for me, stringi, is unavailable to install by normal means. IT have been nice and placed the tar for stringi in a shared space were we can install from local file

install.packages("/path/to/shared/R/misc/stringi_1.4.6.tar.gz", repos = NULL, type = "source")

doing this works fine, package is installed and I can work. But it does not look like renv picks this up and can deal with it? I've also tried using `renv::install("/path/to/shared/R/misc/stringi_1.4.6.tar.gz", repos = NULL, type = "source") but this always fails (I've tried with and without extra arguments, no difference).

I'm I trying to use renv in a context where it just is not made to work?

ss of the stringi error code (sorry for cc, I cannot c+p text out of the server easily)

1 Like

Are you able to share the error you're seeing? It would also be helpful if you could file this as an issue at Issues · rstudio/renv · GitHub.

For stringi installation, you might have some luck if you place the tarball in the package cellar -- see Package sources • renv for more details.

I wrote up how I solved this on github, which was entirely not renv's fault at all!

The ability to add configure and install flags in renv is also just perfect. I had not noticed that particular section before today, and it was really the bit that made it all come together.