News for hackers. Stuff that matters.

A comment on Groundhog: Addressing the Threat That R Poses to Reproducible Research.

Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by st1x7 on Thursday January 07, 2021 @03:33AM (#25668674)
Either I'm misunderstanding or this is a non-problem. You can specify older versions of a package when you install it. You can also manage them with packrat. As long as researchers share their language and package versions, you can fully reproduce their environment. (And the base language is really stable, almost to a fault.)

This is just a bad way for the author to promote their own library for dealing with this. The way their library seems to approach this (using dates instead of versions) seems horrible too - on any given date I can have a random selection of packages in my environment, some of them up-to-date, some of them not. So unless all researchers start using the author's library (and update to the latest versions of everything just before they publish), it's only making things worse and not really solving the problem it claims to solve.

[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by kumarsw on Thursday January 07, 2021 @10:38AM (#25672199)
The impression I get is that this tool has a forensic bent to it. You ask for the code for a paper and Joe grad student with no programming knowledge emails you a zipped folder of R scripts. He just finished his dissertation, is starting a new job somewhere on the west coast, and no longer has access to the computer in his old advisor's lab where he did the work. The implementation may (or may not be) be lousy, but the use case sounds plenty valid.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by dash2 on Thursday January 07, 2021 @10:01AM (#25671800)
Yeah, this seems half-thought-through. renv works at project level and isolates the dependencies of a project from your main library. groundhog.library() tramples over your library installing multiple versions. It also has the "cute" feature of auto-installing libraries if they aren't on your system already. Yuck. If you really wanted this script-only solution then you could go with the `versions` library, which already lets you specify an installation date.[1]

[1]: https://cran.r-project.org/web/packages/versions/index.html

[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by meztez on Thursday January 07, 2021 @08:33AM (#25670791)
Fully agreed. Add `sessionInfo()` output as an appendix to your publication. Should not be too hard to rebuild from that.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by _Wintermute on Thursday January 07, 2021 @08:16AM (#25670622)
Correct me if I'm wrong but specifying an older package version in R still pulls the newest packages from CRAN for any dependencies, which is quick way to run into a load of incompatibilities.

I've not tried renv yet but packrat was a pretty poor solution.

[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by jcheng on Thursday January 07, 2021 @11:45AM (#25673362)
If you need to use an older version of a package and don’t have a packrat/renv lockfile already, then packrat/renv are not going to help you. mran/checkpoint could though.

I agree packrat (which I created) was a poor solution for most users. renv is far better and more usable.

[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by mslip on Thursday January 07, 2021 @10:49AM (#25672339)
You can specify version numbers in renv, you take snapshots of your dependencies into a lock file and can always restore from there or make a new snapshot.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by kwertzzz on Thursday January 07, 2021 @05:17AM (#25669382)
I full agree. With version number you can have a good sense whether a package update breaks your code or not (as long the package authors following semantic versioning).

I think in julia this problem is solved quite nicely with the Project.toml (list of package that you directly dependent) and Manifest.toml file (the version numbers of the complete dependency tree which is automatically generated).

It seems that in groundhog you declare only direct dependencies. Is there a way to store the full dependency tree in R ?

[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by Hasnep on Thursday January 07, 2021 @08:59AM (#25671073)
Using renv (or packrat) generates a renv.lock file with the version of every dependency.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by mslip on Thursday January 07, 2021 @10:48AM (#25672324)
Not really relevant but just to note packrat had been soft-deprecated and is superseded by renv, which comes standard with rstudio.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by ekianjo on Thursday January 07, 2021 @08:13AM (#25670598)
Packrat is deprecated now. It is recommended to use renv instead.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by st1x7 on Thursday January 07, 2021 @08:16AM (#25670627)
Thanks, I just checked renv out (I haven't had to work with R in over a year). Renv looks much better than packrat at a first glance.
[ Parent | on HN ]
Re:Groundhog: Addressing the Threat That R Poses to Reproduc... by ekianjo on Friday January 08, 2021 @07:56AM (#25684176)
Look at recent Rstudio videos on youtube, they explained why they moved away from packrat.
[ Parent | on HN ]