Yes! Absolutely in the plans to have a corresponding R package. In the meantime, we've created a `.rv` R environment within rv projects that allow users to call things like `.rv$sync()` and `.rv$add("pkg")` from the console. Our internal user bases is primarily not CS based and have found these functions extremely helpful
Ultimately, you're right that `rv` and `renv` get you to the same spot, both create reproducible, isolated projects. `renv` has a few issues that we often hit that lead to `rv`.
`renv` is an iterative process of installing some packages, then snapshotting your project state, and then trying to reproduce. The time between the installation and snapshot can often lose information (think `install.packages("my_pkg", repos = "https://my-repo.com")`, your repo source is lost by time the snapshot occurs). You can also install incompatible versions over-time.
rv solves both of these problems because it will lock the source at the time of installation. Additionally, because it is declarative, we are able to resolve the full dependency tree before installing packages to ensure everything will be compatible.
While I am a big proponent of using rv, if renv fits your needs, then switching to rv may not be worth it. For our organization, we did have multiple issues with renv, so created a replacement for it that we hope others in the community will find useful to address their needs.
I had similar issues in the past. Setting up renv, everything seems good, but after working in a project for a few weeks and installing packages, renv constantly complains about the library being out-of-sync and resolving these complaints took way longer than new ones came around. I think renv has good intentions, but there are just too many edge cases (Bioconductor, installing an experimental package from Github, weird package dependencies etc.), that it always failed me in a real-world scenario.
You're hitting one of my (and many people's) main issue with the R package distribution system. In CRAN, only one package version is available at a time, which makes things like version pinning quite difficult. Now the benefit of that is that CRAN guarantees all packages will work together at any moment in time, but then trying to reach back into the Archive breaks that guarantee.
What the CRAN time machine (and now Posit Package Manager) does is take that compatibility guarantee, and freeze it so you have access to all the same, compatible, packages at any moment in time.
While I personally do use PPM fairly extensively, I do understand the paywall concern for long-term reproducibility so `rv` can help you here, with a bit of manual massaging. I'd recommend setting the repositories section of the config file to be a snapshot date in PPM that contains the package version(s) you're interested in and then installing using that repository (taking the benefit of that CRAN guarantee), then in both the config file and `rv.lock`, replace all the references to the PPM repo with your preferred CRAN mirror. This will allow you to resolve to compatible package versions, but then for your POSIT concern, will still be able to reproduce using the CRAN archive.
