It’s also a nice check to confirm that our dependencies are really what we think they are - i.e. we don’t have stray lib:: or library(lib) calls hiding in the code somewhere. Why did we not let packrat do this for us? Installing many libraries at once can take a longish time and can occasionally throw errors we would like to know about or prompts we would like to answer. Next we install our packages into local library as we normally would with install.packages(). # - rmarkdown, lubridate, dplyr, readr, drake, ggplot2 # Snapshot written to '/home/miles/repos/packrat_demo/packrat/packrat.lock' # Initializing packrat project in directory: gitignore so that the library itself excluded from our repository. Crucially we instruct packrat to update our. In this step we initialise a project-local library which will automatically have packrat installed into it. Here I describe the workflow I used to create this example repo. It turns out the kind of workflow I was looking for is possible, but you have to deviate from the default options and workflow advertised in the documentation. From reading around online this seems like a common experience - the packrat API is a bit confusing, much of it seems geared toward enterprise-level dependency management, rather than project-level. Packrat was the last thing I tried because I had already tried it a long time ago and found it a struggle - it seemed to want me to place all the source code of all my dependencies under version control(!!!). The rest of this post describes my packrat workflow and some of the issues with the other two packages. ![]() ![]() I tried: checkpoint, jetpack, and packrat and eventually settled on packrat. I decided to research dependency management in R for something simple and light that could provide a foolproof end user experience i.e. ‘a button’ or a one-liner could be run once the repo had been cloned to set up an environment with the exact same package versions I had used in development. This was somewhat of a relief, but my eyes were now fully opened to what can happen when dependencies are not stated in explicit enough detail. My colleague is new to R, and I cringed and fretted for his user experience as the code basically blew up on the launchpad, spewing alien error messages the likes of which I had never seen.Īs I dug into his sessionInfo() it turned out he had installed Microsoft R Open, which runs an R version and CRAN package versions that are quite behind the current releases. Well let me tell you it was a catastrophic failure. The code was only weeks old, had maybe 40 recursive dependencies and used only CRAN versions… what could possibly go wrong right? A couple of weeks ago I proudly shared a drake pipeline with a colleague along with some basic instructions: “Install R -> clone this repo -> install these packages -> run this file”.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |