rokgarbas

- 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.

[1] https://github.com/NixOS/nixpkgs/blob/63f0da03a3b2c323ea924b...

Thank you.

Would you be willing to give us a challenge in a form of example environment that your data analysts/engineers would use with only a `flox pull`?

an error (i think)

https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3...

i use nix to build my docker images and love it for that.

http://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools

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.

the major reason for poor package support is low number of osx users (hydra - nix build farm - builds binaries also for osx).

a redesign of nix command line is on the way. so thins should get easier.

give pypi2nix a try and ping me on irc if it fails (nick: garbas)

https://github.com/garbas/pypi2nix

with nix you can now build docker images ... docs are in the manual http://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools

and it is actually rather cool since you don't rely on any docker command :)

i think guix/nix solution (can) goes beyond ruby platform and you can define dependencies on non ruby components: postresql, mysql, mongodb, ...

nix has tools to convert gemfile into nix expressions http://lists.science.uu.nl/pipermail/nix-dev/2015-January/01...

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

havent try guix yet, but with nix you can simply do: nix-env -i vim or vimFull and it should install it.

look in documentation at http://nixos.org/nix/ on how to install nix and drop on irc.freenode.org#nixos if having problems

you have yet to give guix or nix a try. been using paludis in past and i can tell you that guix/nix is obvious evolution step :)