Can you use {renv} on a per-blogpost basis?

matt · May 9, 2021, 12:41pm

I'd like to use {renv} on a per post basis in a {blogdown} or {distill} blog. Is this possible and is there a recommended workflow?

I want to be able to rebuild individual posts (or the entire blog) in future, but I know that it might fail if I've updated packages globally since the original publication.

I assume this would involve a renv.lock file within the page bundle for each given post (i.e. in _post/YYY-MM-DD-post-name/ for a {distill} blog), but is there a way to install/load packages on a per post basis with {renv} when it comes to rebuilding a post/the whole site?

Feels like this is necessary for a truly reproducible experience. Or perhaps I'm missing something?

Edit (2022-03-22): I wrote about an approach using {renv} 'profiles' that you might find useful.

cderv · May 26, 2021, 9:05am

FWIW there is an open discussion about this in blogdown

github.com/rstudio/blogdown

Use each blog post's renv environment when rendering

opened 10:33AM - 06 Aug 20 UTC

solarchemist

feature

Right now (and please correct me if I'm wrong) blogdown uses the global R enviro…nment when it's rendering each blog post. Would it be possible to make blogdown use each blog post's local R environment (specifically `renv`) instead? I am suggesting something along these lines: + blogdown's render "chain" `build_rms() -> render_page() -> render_page.R -> rmarkdown::render()` should `cd` into each blog post directory, and read any `./.Rprofile` so as to load `renv` if it is used for that blog post. This way, I think blogdown would achieve several benefits. In particular, re-running blogdown would be less prone to break stuff (making blogdown behave a little more like [distill](https://rstudio.github.io/distill/) in that regard, effectively inoculating each blog post against changing package versions). But it would also make it much easier to have only certain blog posts use specific package versions without having to muddle the global R installation. What follows are the steps I took to test if blogdown uses `renv`'s environment if a blog post specifies one (please correct me if I'm missing something). As a simple test, I have created a new blog post for my existing blog using RStudio 1.3 (by creating a new project, and checking "use renv"). Then I created a plot that uses ggrepel's `segment.curvature` functionality (which is available in the latest dev version, but gives a warning message "unknown parameter" in the CRAN version). So inside the project/blog post (which uses renv): ``` > renv::install("slowkow/ggrepel") > packageVersion("ggrepel") [1] ‘0.9.0’ ``` and compiling the blog post using RStudio yields the expected curved ggrepel segments and no warning messages. But when re-compiling the site with blogdown, the warning message is seen in the CLI output, and the resulting plot uses straight segments instead of nicely curved ones. And I can easily confirm that my global R environment uses the CRAN version of ggrepel: ``` > packageVersion("ggrepel") [1] ‘0.8.2’ ``` To re-iterate my point: would it be possible to make blogdown support `renv` for each blog post? --- By filing an issue to this repo, I promise that - [X] I have fully read the issue guide at https://yihui.org/issue/. - [X] I have provided the necessary information about my issue. - If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there. - If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included `xfun::session_info('blogdown')`. I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: `remotes::install_github('rstudio/blogdown')`. - If I have posted the same issue elsewhere, I have also mentioned it in this issue. - [X] I have learned the Github Markdown syntax, and formatted my issue correctly.

Currently there is no built in way but I believe you could use a main R script (or a Makefile) that would allow to do that, but maybe that is not easy.

For blogdown, new v1 version has better workflow and does not rebuild by default. So once your post is built, it won't be rebuild unless you change something. That reduce the need for locking R environment. See Announcing blogdown v1.0 - Posit

One of the drawback of having one renv environment per post is that the project would become heavy and not so easy to render. Each post would need to be rendered separatly in its own document. But as I said I thing this would be possible by improving the tooling both in renv and rmarkdown ecosystem.

system · June 2, 2021, 9:05am

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.