packrat

[wcornwell]

Wills-Air:wood wcornwell$ make packrat-enable
curl -L -o .packrat/packrat.sources.tar.gz https://github.com/richfitz/wood/releases/download/v1.0/packrat.sources.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   598    0   598    0     0    359      0 --:--:--  0:00:01 --:--:--   359
100 20.5M  100 20.5M    0     0   353k      0  0:00:59  0:00:59 --:--:--  443k
cp .packrat/.Renviron .packrat/.Rprofile .packrat/packrat.lock .
tar -zxf .packrat/packrat.sources.tar.gz
Rscript -e "library(methods);if(exists('initPackrat')) initPackrat()"
Creating private package library at /Users/wcornwell/wood/library/x86_64-apple-darwin13.4.0/3.3.1

--
This project uses Packrat, a tool for managing package dependencies.
Run initPackrat() to install the packages this project needs.
Initializing packrat... OK
Warning: unable to access index for repository http://cran.csiro.au/src/contrib:
  cannot open URL 'http://cran.csiro.au/src/contrib/PACKAGES'
Installing assertthat (0.1) ... OK (built source)
Installing BH (1.54.0-1) ... OK (built source)
Installing bitops (1.0-6) ... OK (built source)
Installing deSolve (1.10-8) ... Error: Command failed (1)
In addition: Warning message:
In packrat::restore(appRoot) :
  The most recent snapshot was generated using R version 3.1.0
Execution halted
make: *** [packrat-enable] Error 1

Is there a better tool for this these days?

[richfitz]

Haha, I doubt it. It's probably for the best because with python virtual environments anything nontrivial begins with a massive installation of a local set of packages. This was my first and last exercise in evaluating packrat and I decided that it was not really what I was looking for.

I know that @cboettig is working on (has worked on) versioned R docker containers going way back and we can probably pull an appropriate R version. I've confirmed that this does not work with 3.1.2:

docker run -it r-base:3.1.2 bash

apt-get update && apt-get install -y curl git

git clone https://github.com/richfitz/wood
cd wood
make packrat-enable

which gives the same error as you were getting

Have some packages broken the workflow? I'd be curious what does not work it's interesting to see code rot in action.

[wcornwell]

It's dplyr: pipes changed from %.% to %>%

[richfitz]

Ah, yes. I remember when that happened. I wish that "tidyverse" included "not breaking the API every version" (I don't think that it's a coincidence that both dplyr and packrat come out of the same company :stuck_out_tongue_closed_eyes:)

I've updated the code to use %>% (which will break the packrat version of course). I'm getting frequent errors while downloading TPL data; I guess they have set up some sort of rate limiting.

This does compile the ms still. Packrat support looks totally broken as that has changed its API (but in fairness it was experiemental when we tried using it)

[cboettig]

Thanks for the ping, actually just been reviving the https://github.com/rocker-org/rocker-versioned images and could use some feedback.

I now have a rocker/tidyverse image that pins the R version and installs the R packages from a fixed MRAN snapshot date, https://hub.docker.com/r/rocker/tidyverse/ . (These images also build on the stable debian release instead of debian:testing which should eliminate some of the apt-get breaking issues that rocker images currently face as debian:testing repos keep chaning. It does mean versions of things like compilers and libraries will be a bit older).

Like @richfitz I've found packrat not my cup of tea for various reasons; though I also haven't used it since it's pre-release days. Anyway, didn't mean to hijack the thread.

[wcornwell]

Works for me too, now. The reason why I was checking this out is this (@cboettig @dfalster and/or @mwpennell might also be interested). I thought it might be worth throwing the wood project in there as one of the earlier efforts. Or maybe you'd rather do something with a remake workflow? Any thoughts?