nixery

I second that. Using nix for building docker images [1] is brilliant, especially when combined with flakes. You don't need messy shell scripts to set up the environment and can get 100% reproducibility. You just build a regular Nix derivation (aka package) with the software you need and then just specify that in your image. It does take some work to get the image size down though. I'll also mention Nixery [2], which is a Docker registry that automatically builds images based on Nix. [1] https://nix.dev/tutorials/building-and-running-docker-images [2] https://github.com/tazjin/nixery

Nix is <3. Here's a template where you can take it for a spin on Gitpod. https://github.com/gitpod-io/template-nix Personally I run all my software via nix, in a monorepo with a layout similar to google3, that generates/serves docker images via https://github.com/google/nixery, supports x64/m1, local development, codespaces and gitpod.

Also https://github.com/google/nixery is nice. I used to easily add a sidecar container to my k8s workload, with the tools I need, without having to maintain a dockerfile and setup an automation to build the container.

The system you describe seems close to Jib [1] or Nixery [2], which are dependency-aware tools built on top of Docker. I think neither they nor the prototype you've described could be as distro/language-agnostic as Docker and ostree/flatpack are. Debian could offer something like Nixery, any distro could, but then it wouldn't be a cross-distro solution. I personally like appimage, but I don't mind using flatpack because it is so similar to Docker and is also supported on most major distros. Distro repositories aren't going anywhere, and I think flatpack strikes the right balance for users and developers. [1] https://github.com/GoogleContainerTools/jib [2] https://github.com/google/nixery

> which essentially means that I'm maintaining a type of registry Mhm, there's no state that can't be thrown away and recreated, so I'd argue the overhead of running it is much lower than a full-blown registry. > Why not have a container runtime that, instead of downloading image layers, instead fetches from a Nix binary cache It depends on where you want to do this - Kubernetes for example has lots of opinions about images and how they're downloaded, so just replacing the runtime wouldn't be enough. Nixery is an incremental step towards the end-goal, but there's a lot of mindset shifting that needs to happen first I think. > Also Nixery is GCE-only Nope, you can use a disk as the storage backend and then there's no dependency on GCS. S3 support would also be relatively easy to add by just implementing this interface: https://github.com/g

> develop a container runtime that would allow a Kubernetes node to run pods that specify Nix expressions directly in the image field https://github.com/google/nixery I'm the author of this, and here is a talk about it: https://www.youtube.com/watch?v=pOI9H4oeXqA

Order doesn't matter to Nix, but images have ordered layers. After digging into the blog post, it sounds like the layers are sorted in a particular order, which suggests that the order in which you specify the packages doesn't matter. That said, I went ahead and pulled nixery.dev/shell/git/htop, and then pulled nixery.dev/shell/htop/git, and I actually got different results. I ran `docker info` on both images and diffed the results, and the layer lists were slightly different. I filed this as https://github.com/google/nixery/issues/38.