3

I am actually working on a stats/ML community website and I plan to use the blogdown package to ease the relationship between our main language (R) and web development.

I read some posts regarding possible deployment strategies. The most popular one seems to use continuous deployment with GitHub and Netlify. The thing I am wondering is how should we treat different versions of R packages within the same website. For example, if I wrote a post 3 years ago with a specific version of a package at that time, and now I wanna write another one with the same package (but with today's version) and there is conflicts between some functions, how is this gonna reflects in my website?

Should we consider the option of having different GitHub submodules for each post so that we can manage the package versions within each post, which would be a project on it's own?

I know it's a quite large question, feel free to give me your opinion on that.

stecaron
  • 101
  • 3

3 Answers3

2

The package liftr was designed specifically for this purpose. It uses Docker to containerize an Rmarkdown document together with all of its dependencies (which includes a specific version of R), ensuring that it always renders the same way on any new system. As described in their intro vignette, all of it can be done from within R.

Artem Sokolov
  • 13,196
  • 4
  • 43
  • 74
  • Seem's like an interesting package. I though about using submodules for each post and use `packrat` to manage my R package versions, but that may be an even more robust option of keeping my posts reproducible. I'll consider it, thank you. – stecaron Jul 24 '18 at 12:12
1

In your case, it seems that you should always use blogdown::serve_site(), which will only render new posts to html if necessary and leave old posts untouched. In this way you will not lose information from old R packages.

Do not use blogdown::build_site() because this will render all Rmd files with your current installed packages.

TC Zhang
  • 2,757
  • 1
  • 13
  • 19
  • 1
    That is absolutely correct. I deliberately avoided mentioning `blogdown::build_site()` in the book: https://bookdown.org/yihui/blogdown/workflow.html – Yihui Xie Jul 24 '18 at 05:08
  • I understand that old posts will remained untouched, but if I wanna update an old post while still using old packages, I would not be able to do it right? This is why I considered the option of using submodules in GIT and treat each post as a project on its own (with its own packages). Every post would use `packrat`to manage their package versions and would be responsible of compiling their .md that would then be added by the blog main website. I tried it, it works, but I always have a post with year "0001" in my main page and I don't know why. – stecaron Jul 24 '18 at 12:09
  • So.. what you are trying to do is to keep a record of all the old packages alongside with your rmd through submodule? some packages may depend on system libraries, so I think it's hard to perfectly replicate an old rmarkdown document – TC Zhang Jul 24 '18 at 23:42
1

Our approach below. It does not use blogdown but it gives full freedom as far as packages and R versions are concerned. We use R Suite (http://rsuite.io)

Development workspace:

  1. post directory with all posts. It is not necessary and one can have posts anywhere. Using R Suite templating it is very easy to control consistency.
    • Each post is a separarate R Suite project. We use R Suite for each post as you could have different R versions for each post.
  2. global hugo folder with content and static folders.
    • hugo server -D is watching this directory for development purposes.
  3. A simple deamon (using later package) watches if a Rmd file was changed in any post (from posts directory). If yes:
    1. It runs generate.R from this particular project. It is important to use external Rscript with proper R version - it is takes from a R Suite project's PARAMETERS file.
    2. This generates imgs and md files and copies them to hugo site. We use rmarkdown for this.
  4. deployment is simple copying public to the place you want.
  5. All codes are kept under version control and packages are taken using MRAN but to have long term support a local CRAN should be used.

I hope it helps you to find best solution for you. It works for us well.

Wit Jakuczun
  • 92
  • 4
  • Thanks for sharing your approach @Wit. I'm not really familiar with R Suite, but your comment convinced me to take a look at it. – stecaron Aug 06 '18 at 00:39