# My how-to - Step 1: `renv::activate()` to create a local .Rprofile - It looks like this is pretty respectful and should just tack on `source("renv/activate.R")` at the end of an existing one - Then, if you're in an environment where you for some reason can't compile packages from source and need to rely on binaries, add `options(pkgType = "win.binaries")` *before* the activation. This way, {renv} will pick this up as the default for `renv::install()`. - Step 2: install packages using {renv} - The docs are pretty good for standard CRAN and GitHub packages. - To do anything more unorthodox you can use the spec from {remotes} (which I think {renv} is built on top of, more or less) - For example, Azure DevOps would be something like: ``` renv::install('git::https://dev.azure.com/your-org/_git/your-package') ``` - Step 3: profit - Optionally commit to the repository, or .gitignore if you don't want to spook other contributors... # Other edge cases? - So in some corporate / managed environments, there's quite aggressive whitelisting for things like .dlls - One time, I was using a `remotes::install_*` function, which seemed like it kinda worked? But what it was doing was using the {renv} configuration - which changes a bunch of global options - and so installing packages into the project library, *but skipping the {renv} machinery of installing in the cache and symlinking*. - This meant that when the final package was being installed *using*(?) a .dll from a dependency, the .dll was getting blocked (presumably because it was in Documents - maybe this is just a UAC-type problem?) and the target package would fail. - Doing the same thing outside of {renv} worked - it looked like .dlls were OK in the default R package library location. - So long story short - make sure you're using {renv} when using {renv}. Just seemed like this anecdote was worth recording. - OK: so there *is* something useful here... - End of Sep 2024, {crew} (0.9.5) and its dependencies {nanonext} and {mirai} were no longer getting updated binaries on CRAN for R 4.2 (presumably this is about the 'vulnerability'?) - So {renv} ends up with {crew} 0.9.2, {nanonext} 0.13, {mirai} 0.13 - which on paper should work - However, {crew} did *not* work! - Trying to forcibly use the binaries for newer R versions (by specifying the path to the Windows binary .zip, as linked to on the CRAN package landing page) all produced errors - Straight compiling from source using `renv::install` landed a .dll whitelist blocking - *but* only at the 'testing if installed package can be loaded from temporary location'. *That* location *was* in the project directory (under renv/staging) - which is consistent with the '.dlls are blocked in Docs but not in AppData' theory. - Going into a non-renv-enabled session and just going `renv::install('nanonext', type = 'source')` *worked*, however! It installs it into the default user library under AppData/Local/R/win-library/4.2 - so this is all still consistent: this is able to install here, so it *actually* installs it into the global cache, then symlinks to the global cache *within the user library*. - {renv} *was* then able to symlink to this *from within the project*, but we had to specify the version `renv::install('[email protected]')` to make sure it didn't get confused (by looking at what was on paper available on CRAN as a binary already, and thinking it had to use that - which would then mean we end up with both 1.2.1 and 0.13 in the global cache) - So long story short this is *hell*, and highlights: - The {renv} philosophy, which is that *you* need to make sure stuff is in a working state before 'snapshotting' it. - You can't always get away from compiling packages from source, *if* you're not going to stay on top of updating R. - Specifically, if you actually want reproducibility, you will need to *maintain access to* multiple versions of R. - This all might have worked for some set of crew/nanonext/mirai package versions on 4.2; if we had found that and locked that in, then we'd be laughing, and could potentially use binaries for those version under 4.2, which RStudio could let us easily pick if we had multiple R versions installed. - However, in the world where you only have the latest R version installed, AND you can't compile from source, there's no point in using {renv} - reproducibility becomes a vice, not a virtue. - You wouldn't necessarily be able to use binaries for an *older* version of R either, so suddenly you'd have to go through the work of finding compatible sets of binaries or just giving up altogether. Either way that involves reprosecuting a lot of things - and checking that your results are consistent... # Headaches 1. Minor: If you're using a different version of R than a colleague, you'll keep tick-tacking updates to the lockfile. 2. It seems like there are some weird dynamics with the caching system such that you might also keep tick-tacking other semi-irrelevant changes to the lockfile: - If I make a lockfile with a package installed/cached from repo A, but you have a (newer?) version of that package cached from repo B, I *think* {renv} takes your newer package from your cache and updates the lockfile with repo B. - This was most notable when I was trying to move from CRAN to P3M (which I set up as a custom repository, named PPPM instead, via .Rprofile, in order to force {renv} to look there); I set up {toolbox.mjk} at home with PPPM, then pulled it on my work computer, which updated the repos on a bunch of packages *away* from PPPM (to, variously, RSPM, CRAN, and other CRAN mirrors). - I'm not 100% sure what's going on here. However, I strongly suspect we'd see some weird/annoying updates to the lockfile when collaborating, and maybe even the tick-tacking like we sometimes see with the {targets} meta file... # More drama! - https://github.com/rstudio/rstudio/issues/15110: turns out it seems to be an issue when creating the lockfile for the first time within RStudio! - And the issue is a lockfile one: setting via .Rprofile doesn't work if the lockfile then doesn't have that info copied in; {renv} actually looks at the *lockfile* repos as the ultimate truth. So it needs adjusting there!