- 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.
as nixos user i looked at habitat and the thing that i will never switch to habitat is that environments are not (build) reproducible. basically habitat is more like docker where it snapshots "successful" build and you use that input for further building.
what i loved about habitat is the supervisor part. i there is a way to use habitat's supervisor with nix. then you get best of both tools.
until then i'll just have to stick to python's supervisord.
with guix/nix you don't even care if they get adopted or not. you can use it in coexistence with any package manager.
very common scenario i come across few times a year: you get to work on an old CentOS/RedHat/Fedora box but you need to install latest package X which is only in next version of current distro. which would mean you need to upgrade or do a lot of manual work. with guix/nix you just install it without need to upgrade.
nix (and potentially guix) is working on windows, at least from what i heard. probably there are some issues with existing packages since nobody really pays much attention to windows but if somebody cared this could improved a lot.
you can rollback on debian? you can install packages as user on RedHat? i moved away from it just because things like .deb and .rpm don't do the job all the way
- 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...