I am getting started with collaborating with team members on R projects using renv. While I can (mostly) get it to work, I am a bit confused about whether and where to install renv itself. According to the documented workflow I basically need renv installed before I start a new project with renv.
However, when I do not have renv installed, and clone a repo that uses renv, it seems to install (bootstrap?) itself. But it does this within the local renv environment.
I have a couple of questions regarding this:
Do you recommend to have renv installed "outside" the renv virtual environment?
How do you deal with differences in versions of renv itself between what is e.g. installed on my machine and present in a repo that I clone, and which renv I would like to replicate? I ran into problems with this one, could not replicate a renv from a cloned repo with a different renv version.
On a more conceptual level: why is renv itself part of the virtual environment it creates? That's not the case for the python virtual environment managers I know.
Do you recommend to have renv installed "outside" the renv virtual environment?
We do. In fact, this is necessary if you want to initialize an renv project in the first place, since this is done by calling renv::init() -- and so the regular renv initialization workflow expects renv to be installed into the user library.
How do you deal with differences in versions of renv itself between what is e.g. installed on my machine and present in a repo that I clone, and which renv I would like to replicate? I ran into problems with this one, could not replicate a renv from a cloned repo with a different renv version.
Since renv is just an R package, you can install or upgrade (or downgrade) the version of renv used within a project as required, without affecting other projects. For example, installing the latest version from CRAN can be done with a plain install.packages("renv").
When working within an renv project, the version of renv installed in that project is normally the copy that is used -- so at this point, it should no longer matter what version of renv is installed in the user library.
On a more conceptual level: why is renv itself part of the virtual environment it creates? That's not the case for the python virtual environment managers I know.
This is done primarily to ensure existing renv projects can continue to function even if an update to renv happened to break some existing workflows. (We endeavor to make sure that will never happen, but want to make sure users have an escape hatch in case it does.)
However, when I do not have renv installed, and clone a repo that uses renv, it seems to install (bootstrap?) itself. But it does this within the local renv environment.
The "bootstrap" behavior here is done to help streamline the collaborative workflow. Rather than requiring users explicitly install renv before opening an renv project, renv knows enough to bootstrap itself in an existing project so that new users can get up and running quickly. (In addition, the bootstrapper script also tries to ensure that the version of renv that project was configured to use is installed.)
Related
In our team, we are sharing self-written functions (e.g. for connecting to our dbs) via a self-written package that I set up in a git-repository (non-public).
As a general rule, we avoid to install packages in our users' accounts. Instead we use renv to get reproducible environments. How can I best handle the private package with renv?
Can I somehow use renv::install() to install the package from the private git-repo with ssh-keys?
What I've done so far: I cloned the package and installed it via R CMD INSTALL path/to/folder_with_tar.gz. renv does not seem to pick up the package when running renv::init() / renv::snapshot(). I am working on using devtools to install from repository (currently waiting for IT to resolve git2r issue) but this would not solve the problem with renv.
Sorry for no MWE, I don't know how to produce one in this case.
EDIT 2022-11-08:
I want to keep this question open because this is not an answer to the question but rather a workaround. However, if using RStudio with a professional license, the best solution is to use the Package Manager. This circumvents the problem a bit: Instead of dealing with how to acces the private git from renv, the Package Manager manages the access.
What is the correct procedure to deploy packages using renv to an offline machine?
We have an internal CRAN-like repository, which is configured via options(repos = list(cran = "http://our.repo.url")) on both the development machine and the deployment machine. It is specified in renv.lock. The renv package itself is installed on both machines, and both are the same version (1.14).
After deployment, after starting R in the project directory, it hangs for a while, and returns an error:
# Bootstrapping renv 0.14.0--------
Warning: unable to access index for repository https://cloud.r-project.org/src/contrib/:
cannot open URL 'https://cloud.r-project.org/src/contrib/PACKAGES'
* Downloading renv 0.14.0 ... FAILED
How do I tell renv to either copy itself from the system library, or install from the internal repository?
Copying from the system library would be of course the preferred course of action, to save time compiling.
You might want to file an issue at https://github.com/rstudio/renv/issues since I think renv doesn't currently support loading the renv package from a non-project library path via the autoloader.
That said, you should be able to move forward by disabling the renv auto-loader. Before launching R, you can set the environment variable:
RENV_ACTIVATE_PROJECT = FALSE
Then, when R is started, the renv auto-loader (run via source("renv/activate.R") in the project .Rprofile) will be disabled. You can then later load renv from whichever library path is appropriate, and call renv::load() to manually load a particular project.
(The other alternative to setting that environment variable is simply removing the renv auto-loader from the project .Rprofile.)
I want to test the potential function of the collective maintenance of the R scripts across individuals. I try to work on Rstudio project together with the Could software eg. Dropbox and the version control (eg. Git), so we can have all the records of all the updates from different maintainers. Therefore, I try to test the new released R package renv.
On my Mac OS, my newly installed packages are available in the 1st directory as I listed below.
.libPaths()
## [1] "/Library/Frameworks/R.framework/Versions/library"
## [2] "/Library/Frameworks/R.framework/Versions/3.6/Resources/library"
However when I start the renv with the renv::init(). It only has the basic packages available. How can I move these installed packages into the global cache directly without the need to reinstall these pacakges?
You can simply call renv::install() (or renv::restore()) and renv will find packages already installed in the cache. It's possible because all the projects using renv share the global package cache, therefore, the project libraries are composed by symlinks associated to the global package cache.
In case that renv global package cache and the project library are installed in different disk volumes, renv will copy the package from the cache into the project library, instead of using a symlink.
In macOS, the default location of renv global packages caches is: ~/Library/Application Support/renv.
All the information was extracted from the following link: https://cran.r-project.org/web/packages/renv/vignettes/renv.html.
I hope it helps you. Good luck!
My Dockerfile includes a step that pulls from an unrelated, public git repository. Specifically, it's installing an R package using the R command
devtools::install_github("bmbroom/NGCHMR")
This should install the latest version of the package from the master branch of that repository, and on local builds that is exactly what it does.
On Dockerhub automated builds, however, I always get the version of the package that was current when I first built the image. There is otherwise nothing special about that particular version. It's as if github access is being cached. The docker build process itself is clearly not cached, based on authoritative replies to other questions here as well as the build logs, which show earlier steps in the build being executed in detail.
Any suggestions why I'm not getting the most recent version of the R package installed?
What all are the differences between install nginx from source and install as package ?
Well to define "all differences" would be near impossible because every OS package is built differently. However, with that said...
1) Package installs are pre-built with their own options configured which also gets installed wherever they decided to put that installation once it's installed.
2) With the source, you are able to define what is built, where it should be installed, etc...
So if you are going to install via a package, you are basically forced into whatever options they set. Unless of course you decide to take their package and then re-package it to fit your requirements. But that would pretty much be a pointless as you'd be better off just installing from source at that point.
Most if not all packages also comes not only with a simple install but a simple way to uninstall the software. Where-as if you compiled and installed via source then you'll need to manually remove the installation if you no longer need it on your machine.