-
-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use each blog post's renv environment when rendering #469
Comments
That sounds like a great suggestion! We'll definitely consider it in the future. Thank you! |
We've been working hard on a new blogdown version and we will make release of 1.0 soon. Part of the change we made and features we had may help in your usage:
By any chance, have you tried the new version yet ? If not, can you give it a spin (on a demo site maybe) to see if it changes thing for you ? It will not be the same as having a "project" library for each of your Rmd post but old post won't be rendered anymore so new packages for new posts won't alter the results of previous posts as it could before in some cases. About a library per post, this could lead to an heavy blog with all the duplicated libraries. However, with renv cache mechanism and renv lockfile I could see the advantage of having a lockfile per post that you could use to rerendered a post. maybe by recreating the library temporarily for the post rendering 🤔 Anyway, eager to here how the new stuff could change (or not) your existing workflow and your need of renv project for each blog post. Thanks! |
Thanks for your kind words @cderv It took me a while to get around to it, but I have finally upgraded R (v4.0), blogdown (v1.1) and now my blog. And I must say the changes to blogdown makes blogging with it significantly easier. Nice work! Not building Rmd posts by default works very well, and creates peace of mind compared to before, just like you indicated. Also, asset bundling is awesome! It took a little work to edit image paths and whatnot in my existing blog posts, but bundling assets inside each blog post directory is clearly the better approach. I think that thanks to asset bundling, now more than ever, each blog post becomes its own little stand-alone project. As such, it becomes even more rational to have each blog post be its own renv project, and it would be just awesome if blogdown actually used such renv environments when rendering. As to the risk for bloated renv directories, I think I can put you at ease. Like you said, with the renv cache mechanism (I have set In practical terms, I see two approaches: blogdown can either In any case, congratulations on a significantly improved v1.0+! |
We had a meeting with Kevin (renv's author) today. He mentioned a few interesting methods related to using renv for individual Rmd documents: |
Are there any updates on this? I'm trying to revitalize an old blog post that relies on some archived packages and would love pointers on how to use |
Just to clarify, are you using Quarto and |
I'm starting to write blogposts in |
I am asking because Quarto has a Also, since blogdown v1, post are not rerendered by default. Which prevent so difficulties to manage blog with old post. However, if you want to rerun some R code from old blog post, then renv should be indeed quite useful. We are thinking that the recent feature |
There's a recent blog post with an example of using |
Right now (and please correct me if I'm wrong) blogdown uses the global R environment 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:
build_rms() -> render_page() -> render_page.R -> rmarkdown::render()
shouldcd
into each blog post directory, and read any./.Rprofile
so as to loadrenv
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 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):
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:
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
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')
.The text was updated successfully, but these errors were encountered: