[Nix-dev] Design Patterns for Achieving what Nix is Advertized for

[joachifm at fastmail.fm]

On Fri, Nov 27, 2015, at 03:09 AM, Martin Vahi wrote:
> 
> In the light of the instability of the Nix
> 
> https://github.com/NixOS/nix/issues/718
A single bug report is hardly evidence of the "instability of Nix". For
many (most?) of us, Nix works as advertised and has done so for a long
time. The fact that a build fails in an arbitrary build environment is
an argument in *favour* of the Nix approach, where environments are
precisely defined. The state space of a modern OS boggles the mind and
it really is mad to expect anything to work consistently. That things
actually work and work so well is amazing.

Anyway, your best bet is to read
https://nixos.org/~eelco/pubs/phd-thesis.pdf and similar material on
nixos.org.That should give you an idea of what you need to achieve
feature parity and beyond.

A few remarks:

> Nix sales argument:
>     Multiple versions of the package can
>     be used simultaniously and each of the
>     packages can use its own set of dependencies.
> [....]
> Proposed workaround design pattern:
> [...]
With Nix, you get cryptographic hash signatures which exactly denote
arbitrary build configurations and their combinations, no DSL required
(unless you consider Nix itself a DSL). Also, Nix solves the general
case, not only traditional software packages.

> Nix sales argument:
>     It is possible to select, what packages
>     are available in the environment(PATH, libs), the
>     environment is versioned(allowing rollbacks, branches, etc.)
>     and the environments are reproducible on
>     different computers by having the clone computer
>     go from state 0 (the "hello" has been installed)
>     to the destination environment state by
>     going through all those state tree vertices
>     that are on the path from the root (the "hello")
>     to the leaf or some vertex in between.
The design of Nix allows precisely computing a component's runtime
dependencies (the closure), which in turn enables replication by dumb
byte transfer. A NixOS system configuration is just a component, like
any other, and can be replicated in the same fashion. I find it
unhelpful to think about this in terms of the recipient going through a
sequence of state transitions to reach an end state.

Regards,
Joachim