- Method 1: doesn't really improve layer caching, but it provides a familiar way (via Dockerfile) to use Nix packages. As with any Dockerfile, the creator is in charge of creating layers and making sure those layers are as small (cleaning cache, ...).
- Method 2: Nix language is used to describe (in a declarative way) what the end image should look like. Layers are then calculated based on the dependency tree (or as Nix calls it, dependency closure). The algorithm that creates layers[1] makes sure that there is higher likelihood of cache hits without the user needing to worry about layers, but you can even roll-up your own algorithm that fits your project better.
- Method 3: Using Flox you would get sort of both. An easy way to configure the final docker image via toml configuration and using Method 2 under the hood.
There are other ways how to improve caching efficiency, but those are very use case specific (eg. big "builder" images) and would probably require a completely separate blog post.
- Method 2: Nix language is used to describe (in a declarative way) what the end image should look like. Layers are then calculated based on the dependency tree (or as Nix calls it, dependency closure). The algorithm that creates layers[1] makes sure that there is higher likelihood of cache hits without the user needing to worry about layers, but you can even roll-up your own algorithm that fits your project better.
- Method 3: Using Flox you would get sort of both. An easy way to configure the final docker image via toml configuration and using Method 2 under the hood.
There are other ways how to improve caching efficiency, but those are very use case specific (eg. big "builder" images) and would probably require a completely separate blog post.
[1] https://github.com/NixOS/nixpkgs/blob/63f0da03a3b2c323ea924b...