4 ms·
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
by st1x7 6y ago
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.
- kwertzzz 6y agoI 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 ?
- Hasnep 6y agoUsing renv (or packrat) generates a renv.lock file with the version of every dependency.
- ekianjo 6y agoPackrat is deprecated now. It is recommended to use renv instead.
- _Wintermute 6y agoCorrect 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.
- mslip 6y agoYou 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.
- jcheng 6y agoIf 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.
- meztez 6y agoFully agreed. Add `sessionInfo()` output as an appendix to your publication. Should not be too hard to rebuild from that.
- dash2 6y agoYeah, 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 https://cran.r-project.org/web/packages/versions/index.html
- kumarsw 6y agoThe 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.
- mslip 6y agoNot really relevant but just to note packrat had been soft-deprecated and is superseded by renv, which comes standard with rstudio.