Best practices for managing long-term Quarto sites (e.g., blogs) using multiple docker images

[wetlandscapes]

Description

For one-off Quarto projects it is pretty easy to use a single docker container, or possibly a couple containers and just switch between them. However, for long-term projects, like blogs or books, that might require maintenance over years, I'm wondering if there are strategies for incorporating new versions of Linux, R, quarto, Julia, etc. that preserve the original environment a notebook or site was written in, while still allowing for upgrades in the context of new quarto outputs, all for the same project, and without making a hundred different containers.

I realize I can just freeze notebooks (which is my current work around), but that doesn't seem ideal if I ever want/need to re-run that notebook, as I'm not really guaranteed to get the same output (e.g., there may have been a breaking change in my new environment).

In the context of working outside of a container and using a single language, like python, I might just create individual environment.yml files and store them with their respective notebooks, but that seems like it could get a bit unruly after a while and I'm not sure how well that would work in the context of have lots and lots of renv (R) and toml (julia) files, as well, or how that would work at all in the case of Observable. Maybe I should just try?

Long story short, curios if others have strategies they've found useful for managing their blogs, books, etc. in the context of shifting docker images and other software requirements.

[mcanouil]

There are no such things right now.
What you can do is freeze computations, save dependencies to be later reuse for single document rendering as Quarto only uses one global setup, i.e., it won't use single document (blog post) environment. So you will have to restore, render/freeze each document in the future.

For short, whatever allows you to work as you want is the way to go.