![]() ![]() Tried replacing this with calls to Rscript -e "packrat::packify() etc. The source/ readRenviron calls should really be restarts to R. Source( ".Rprofile") readRenviron( ".Renviron") Using a bit of a hack we can just version manage/ship the packrat.lock file and let packrat try and restore the rest. Not huge but more than you might want in a Git repo all the same. Note that there are 711 packages over 1 MB, for a total weight of over 2.8 GB. SetAs( "character", "", function(from) as.numeric( gsub( ",", "", from) ) )Īns = read.table( textConnection(txt), colClasses= c( "character", "", "Date", "character")) The first discussion led to an interesting question about just how big are CRAN packages these days anyhow? Thanks to this clever rsync trick from Duncan, I could quickly explore this: txt = system( "rsync -list-only ::CRAN/src/contrib/ | grep. tar.gz files? packrat/issues/59 (Summary: option coming)ĭo I really need to restart R packrat/issues/60 (Summary: yes). Renviron, and the tar.gz sources for all the dependences (in packrat.sources) seems heavy and clunky, and logging in and out all the time feels like a hack.Īm I really supposed to commit the. Having a single packrat.lock file (think Gemfile.lock I suppose) seems like a great idea. Packrat isn’t yet on CRAN, and for an RStudio package I admit that it feels a bit clunky still. So I finally got around to playing with packrat. The install script feels like a bit of a hack, and makes me think that RStudio’s packrat may be what I actually want for this. Consequently, I’ve had to add an install.R script to my template, to make sure these packages are installed before a user attempts to run the document. I’ve been relying on the R package mechanism itself to handle dependencies, though I list all packages loaded by the manuscript but not needed by the package functions themselves as SUGGESTS, as one would do with a vignette. The rmarkdown::render workflow doesn’t cover installing the dependencies, or downloading the a pre-built cache. ![]() Rmd file and say “load this in RStudio” rather than passing along a whole working directory. In light of these developments, I wonder if I should separate my manuscripts from their corresponding R packages entirely (and/or treat them as vignettes?) I think it would be ideal to point people to a single. This exposes the features of the rmarkdown package to the RStudio IDE buttons, but more importantly, seems like it will simplify the pandoc/latex dependency issues cross-platform. Notably, a lot of the pandoc configuration can already go into the document’s yaml header (bibliography, csl, template, documentclass, etc), avoiding any messing around with the Makefile, etc.Įven more exciting is the pending RStudio integration with pandoc. I’m pretty happy with the way rmarkdown looks like it can pretty much replace my Makefile approach with a simple R command to rmarkdown::render(). ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |