Hi Sean,
thanks for your thoughts!
I slightly disagree with your first point because everything you do with the R code must come after the package installation. And if I just fix e.g. one typo or small bug in a script I do not want to have the packrat::restore reexecute which takes 95% of the building time. Or did I misunderstood you here?
I think the question is, what does final environment mean? If it is software project which continously evolves there could be releases every week or I am testing every commit with some CI solution and then it would be nice if I can nearly immediately preview my shiny app on a testing server etc. Now I have to wait 45-60 minutes until the dockerfile is built. My solution is currently to change the lockfile as few times as possible.
Hmm, I think separate lock files could be possible without too much effort without looking too deeply into the code (but I could also be completely wrong
). The packrat::restore function just would need to check if a package is already installed and install it only if necessary.
In your example the first packrat lockfile would contain shiny and httpuv, so a first packrat::restore call would install those packages. Then the second time restoreis called with the second lockfile, which contains httpuv and plumber, only plumber has to be installed. Of course it would not be possible to have different httpuv versions.