←back to thread

68 points Keats | 8 comments | | HN request time: 0.663s | source | bottom

We have been building a package manager for R inspired by Cargo in Rust. The main idea behind rv is to be explicit about the R version in use as well as declaring which dependencies are used in a rproject.toml file for a given project. There's no renv::snapshot equivalent, everything needs to be declared up front, the config file (and resulting lockfile) is the source of truth. This avoids issue where renv might miss information about the installation and is also easy to tweak some packages, eg install one from source and install suggests from another.

If you have used Cargo/npm/any Python package manager/etc, it will be very familiar.

1. mbeavitt ◴[] No.44007409[source]
Can this be used to effectively create R environments? I’m desperate for such a solution.
replies(5): >>44007427 #>>44007510 #>>44007561 #>>44008773 #>>44009817 #
2. goosedragons ◴[] No.44007427[source]
You can do that with Nix or Guix.
3. scrappyjoe ◴[] No.44007510[source]
Doesn’t renv do that? What need does renv not meet for you?
replies(1): >>44008424 #
4. Keats ◴[] No.44007561[source]
By default, rv will create a library folder in the same folder as your rproject.toml and there's rv activate/deactivate to add it to your loaded libs. Pretty much the same stuff as a virtualenv in Python.
5. arbutus8 ◴[] No.44008424[source]
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.

replies(1): >>44009148 #
6. okanat ◴[] No.44008773[source]
I used pixi for that. It uses Conda ecosystem but you get proper lockfiles and great native binary package support.
7. aquafox ◴[] No.44009148{3}[source]
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.
8. pupperino ◴[] No.44009817[source]
{renv} is pretty solid, I've been using it in production for years now and have no complaints.