> With no way of splitting up the Nix dependencies into separate layers nix2container [1] is actually able to do that: you can explicitly build layers containi

> With no way of splitting up the Nix dependencies into separate layers nix2container [1] is actually able to do that: you can explicitly build layers containing a subset of the dependencies required by your image. An example is provided in this section: https://github.com/nlewo/nix2container?tab=readme-ov-file#isolate-dependencies-in-dedicated-layers https://github.com/nlewo/nix2container?tab=readme-ov-file#is... For instance, if your images use bash, you can explicitly create a layer containing the bash closure. This layer can then be used across all your images and is only rebuild and repushed if this bash closure is modified. > > pull in dependencies often results in massive image sizes with a single /nix/store layer This is the case for the basic nixpkgs.dockerTools.buildImage function but this is not true with nix2container, nor with nixpkgs.dockerTools.streamLayeredImage. Instead of writing the layers in the Nix store, these tools build a script to actually push the image by using existing store paths (which are Nix runtime dependencies of this script). Regarding the nix2container implementation, it builds a JSON file describing the Nix store paths for all layers and uses Skopeo to push the image (to a Docker deamon, a registry, podman, ...), by consuming this JSON file. (disclaimer: i'm the nix2container author) [1] https://github.com/nlewo/nix2container https://github.com/nlewo/nix2container