[Nix-dev] [***SPAM***] Thoughts on the Nix model

[Kosyrev Serge]

Good day folks!

The growth in popularity Nixpkgs enjoys, as exemplified by the continuing
uptake in the unmerged pull requests, is the evidence that directs us away
from the kind of issues I feel like raising in this message.

Yet, after a year and a half of my personal experience of using and
occasionally contributing to NixOS, it's becoming hard to dismiss them.

First, let me start with an empathic agreement that the ideas underlying
NixOS make it almost unique in the fundamental soundness of its system
composition and configuration management.

Nothing, however, comes for free, and the operational complexity of
traditional Linux distributions shifts into an unparallelled descriptive
complexity in the support infrastructure of NixOS [1].

                      -   -   -

But, what is the evidence for this descriptive complexity?

The simple fact that Turing-complete code is used to describe
/everything/.

One could say, of course, that the leaf 'default.nix' files are mostly
declarative.

The response is that, of course, this is an observation the
meaningfulness of which can be judged by the awful state of the tools
that are supposed to query the package database.

With all due respect, in comparison with traditional distributions,
they are either atrocious or non-existent.

And I don't mean only user-facing tools here, but mostly tools to
support the developer -- things like the 'dpkg-*' suite, for
example.

We all know about the hard limits to program analysis, and of course the
retreat used by Nix to support these tools, is an introduction of
regularity that is barely sufficient to sustain a pretense of automatic
processing outside of the default mode of execution -- derivation.

Let's not fool ourselves -- with the exception of the core path of the
Nix deriver, which they were designed to support, the 'default.nix'
files are perpetually hovering on being barely declarative enough for
the meager assortment of other tooling to work.

                      -   -   -

Another thing that could be said, is that there is no need for
declarativity at all, since the code can be executed, and the
returned derivations can be queried for the desired properties.

Unfortunately, limiting analysis to execution (if one can be excused for
uttering such blasphemy) has the following undesirable properties, among
others:

  - it makes validation nigh impossible, for example due to the returned
    data structures /themselves/ containing executable functions

  - crucially, it leaves no choice but to use Nix for writing tools
    manipulating the what-ought-to-be-declarations

  - deriving from the above, it also means the analysis is going to
    be /slow/, at least with the current implementation of Nix

  - the attempts to hide this slowness already results in warts,
    like haskellPackages being a separate namespace

The second point is, without question, the gravest, because while Nix
might be an adequate language for expressing derivations, I think it's
in unarguable that it's ill-suited for writing tooling.

And yet, the meat of the information contained in the "package database"
is either unavailable, or has restricted availability to anything outside Nix.

In my perception, this situation can't be good in the long term.


--
1. Don't get me wrong -- one could say that in comparison, the traditional
distributions mostly don't even attempt to formalize their composition.
NixOS is clearly without precedent here.
--
с уважениeм / respectfully,
Косырев Серёга
--
“And those who were seen dancing were thought to be insane
by those who could not hear the music.”
– Friedrich Wilhelm Nietzsche