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.
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?
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)