Add alternate container engine support to Justfile

[chris-t-jansen]

Overview

PR for #7324. Adds alternate container engine support to the justfile for TWiR. This PR was written with Podman in mind and was tested with that, but should work with any drop-in Docker replacement. Use it with any recipe that previously called Docker like so:

$ just <recipe> <container engine>

For example:

$ just website podman

$ just email podman

Warning

Though I feel that what I've written is sound, additionally testing is immensely appreciated just to be sure, especially by the TWiR editors since they are the people who will use it the most.

Docker by default

Docker remains the default container engine, so passing in no arguments (i.e. just website, just email) will use Docker as it always has. This is achieved by having Docker set as a global Just variable here:

default-container-engine := "docker"

Which then gets used as the default value for the newly added container-engine parameter on any recipe that used to call docker. For example:

# Build container engine image (Docker by default)
container-build container-engine=default-container-engine:
	cd .. && {{container-engine}} build -t twir -f publishing/Dockerfile . && cd -

Cons

A refactor like this usually comes with a downside or two, and this one is no exception. The obvious one here is that the justfile is fairly more verbose, with the inclusion of parameters and default values for most recipes. This makes it less easily readable, which may hurt maintainability in the long run.

The other downside has to do with the optimize-email recipe. This recipe originally just called a shell script (create_optimized_email.sh), which itself explicitly called docker. To make it engine-agnostic, I inlined the script into the justfile as a script recipe. Originally I implemented this as a shebang recipe, but due to noexec issues on WSL (see here and here), I had to opt for the unstable [script(COMMAND)] attribute instead. The default COMMAND of sh -eu didn't work for me in testing on WSL, so I opted for bash instead. This could cause issues with portability on machines that don't include or symlink a bash executable, but I had no trouble when testing it on my Windows machine with WSL and with my macOS machine.

The optimize-email recipe issue could also be resolved by refactoring the original script to support command line arguments (e.g. create_optimized_email.sh -c podman), but keeping things in the justfile seemed a more elegant solution to me.

Concerns

If you have any questions, comments, concerns, etc., feel free to let me know. As I said in the original issue I opened, I think this kind of compatibility support is important, but totally understand if the TWiR editors aren't interested in it.

[nellshamrell]

Thank you so much! I will review this this weekend!