search

ATFutures / hugo-site

0 stars 1 forks source link

blogdown #2

Open mpadge opened 5 years ago

mpadge commented 5 years ago

Extending from #1, hugo alone is not overly conductive to reproducibility since it does not directly offer or integrate with any way to execute code. blogdown does this, but suffers the shortcomings indicated in #1. AFAIK, blogdown can't do this because hugo's instant (re-)generation is driven by constantly monitoring changes to the .md files. To do an equivalent, blogdown would have to do the same for the .Rmd files, and then re-render on change. Yet even this would never be instantaneous, because rendering is very slow compared with hugo speeds.

What to do ... one hack solution would be to incorporate an R function within the standard hugo site which auto-inserted appropriate headers for .Rmd files and rmarkdown::render-ed them to .md. This is exactly how blogdown actually works, but is also equivalent to re-inventing that package, which seems redundant and unnecessary. Have to find a solution somehow ... ping @Robinlovelace

Robinlovelace commented 5 years ago

Could just set a recurring task to blogdown::build_site() if it's deployed on a server or if we build locally and push changes incrementally. I doubt we'll be running any chunky computations in the code on the website so I don't think build times are a priority for the website. That's my 10 cents anyway: the +s of .Rmd outweigh the -s of for me.

mpadge commented 5 years ago

Fair call. I'll get on to it, but it will require completely re-constructing the repo from scratch and copying everything into new blogdown structures. I've got other priorities for the mo, but will get onto it at some stage in the not-too-distant ...

layik commented 5 years ago

Reproducible Hugo.