New vignette for using Nix and {rix} alongside Docker for package development

[rpodcast]

My journey with Nix and more recently with {rix} has been quite a ride, but I have learned so much in the last few months for my open-source R development. Once I read the using Nix inside Docker vignette, I immediately pursued a use case of using those principles to develop a Shiny app as an R package with {golem}, which I have been doing for many years in a VS-Code & devcontainer workflow using Docker as the container runtime. In a recent project under R Weekly, I created a Shiny app with {golem} using {rix} to bootstrap the development environment, which works perfectly for the user case. I presented this alongside my general impressions of Nix and {rix} at the 2025 Shiny conference, and you can find the source code for the project here.

Now to the main point: I was struggling with how the Docker builds would take a ton of time (even with using caching) whenever I made a small change to the application source code itself, but not making changes to the dependencies used for the app package. It only occurred to me recently that {renv} users leveraging Docker also encountered similar issues (myself included), and one of the key points in the Using {renv} with Docker vignette was to leverage multi-stage builds in the Dockerfile such that the dependencies are taken care of in the first stage, and have the second stage only be concerned with the specific "package" development changes. I revised my Dockerfile for the application I'm building, and it worked perfectly! With all of this said, I propose that we add additional material (either to the existing Nix & Docker vignette or perhaps a new vignette) that covers this tweak. I think it will be a huge help to those coming to {rix} for the first time and want to leverage containers for either CI/CD or deployments. Does that sound reasonable?

[b-rodrigues]

Hi Eric, many thanks for your input and for spreading the gospel about Nix!

What you describe would indeed be helpful, but I wonder if we shouldn't present this in two ways:

• first, by telling the users that they need to be careful about the order in which they copy the files. If they start by copying the default.nix, and then only the required files for the shiny app, editing the shiny app and then rebuilding the image should not trigger a new rebuild, right?
• second, the multi-stage approach.

I think it would make the most sense to write that in the existing vignette. Do you want to take a shot at it?

[rpodcast]

Thanks @b-rodrigues! I'll be happy to draft the material for the existing vignette and send a PR.

Great advice about order considerations when constructing the Dockerfile. My situation was a bit unique in that I am actually installing the custom Shiny app package in the same Dockerfile. In my previous attempts, I did that a single configuration which checked for the presence of a simple environment variable to indicate if the app package should be installed. It's entirely possible that I could simple call the build twice (once without the env var defined, and the next with the env var defined) without having to necessarily do the multi-stage build. My problem was that I only called this a single time, so every time I modified the app package source it would re-install all of the dev environment. I'll test this approach out before writing the vignette just in case.

[b-rodrigues]

ok I see why in this case going for the multi-stage build is definitely the better approach!