Closed adamaltmejd closed 5 years ago
You're exactly right. Packrat chose some default options / behaviors that time has shown to be sub-optimal in many ways.
I realize this is likely coming in a bit late for you, but you may want to take a look at renv -- we're developing this as a replacement for Packrat which aims to more explicitly support exactly the workflow you're suggesting.
Thanks! Too late for this class, but another one coming up in not too long. Will def. check out Renv.
Hi!
Have been working on setting up a simple collaborative workflow for reproducible research projects using R for a talk that I'm giving and Packrat seemed like a natural tool to use. The scaffold can be found here.
As you can see, I set
vcs.ignore.lib
,vcs.ignore.src
, anduse.cache
toTRUE
, as this seems much more reasonable to me. What is the reason for defaulting to creating a directory in the project folder and implying that repositories should be committed?To me it seems Packrat's default setup is geared towards creating a completely fail-safe reproducible bundle, where everything can be run exactly as it was when the code was originally written. However, since Packrat cannot control the external environment (the
R
version and a large set of external applications) this will never work. One needs something like Docker to achieve perfect reproducibility. A Packrat bundle could simplify the process of creating a Docker image, but is not necessary.The setup that I wanted to achieve is instead focused on the collaborative research process. In this stage I want to ensure that all my collaborators are using the same versions of packages. I also want to easily be able to update packages, and sometimes use beta versions directly from e.g. Github. Instead of cluttering the project directory, shouldn't it be enough for Packrat to rely on a file like requirements.txt or packages.json (and of course the initialization script in
.Rprofile
)?