That is something you can’t quite escape in Nix either. While it doesn’t use parenthesis like a Lisp, the nature of the language and the depths of the sets you are dealing with still makes you end up getting a lot of this at the end of your files:
];
};
};
};
}
Having one } too many or too few is a pretty common issue with Nix and feels very similar to Lisp, even when the rest of the language is quite different.
While some people love putting Lisp in everything, I really don’t get it. Guix is far uglier than Nix in the language department. Scheme is not a configuration language and thus has none of the nice things that Nix has (multi-line string handling, defaults, lazy evaluation, inline expression, etc.), instead you get multiple levels of macro spaghetti. Furthermore, Guix forces you to turn everything into Scheme, where you can just use plain Bash in your Nix build steps, in Guix that is all Scheme.
I had spent a lot of years with Scheme before starting with Guix and then spend quite a few years with that, but even after all that switching to Nix just felt so much better instantly. Instead of trying to hack a DSL onto of Scheme you just get a language that’s actually build for the task.
Where are the source packages?
It’s reproducible, so random updates are a no-no. You can however just dump the Git URL in your flake.nix inputs and then override the src of the package with that. The source gets updated when you do nix flake update next time. Something like this:
inputs {
...
mypackage_src.url = "github:myorg/mypackage";
mypackage_src.flake = false;
...
}
pkgs.mypackage.overrideAttrs (oldAttrs: {
src = mypackage_src;
version = "nightly-${mypackage_src.shortRev or "src"}";
})
The Nix language itself is the hardest part.
Let me disagree there, the language is trivial. It’s just JSON-lookalike with expressions, with a lot of nice touches that make using it much easier than all the alternatives (e.g. sane multi-line string handling, lazy evaluation, default values, powerful key/value sets, etc.). The only real stumbling for me when first encountering it was realizing that functions can only take a single argument (which can be a key/value set) and that functions are literally just : (e.g. (a: a + 5) 6 => 11). That’s easily missed if you just look at a file without reading the documentation.
The thing that makes it hard is just the complexity of the actual package collection, your configuration contains literally your whole system, and it’s not always obvious where to find the thing you need, since sometimes it’s a plain package, sometimes it is a services.foobar.enable = true and sometimes you have to fiddle with override or other package specific things. Knowing that
https://search.nixos.org/ exists is half the battle here.
There is also the lack of static typing that can lead to rather verbose error messages, but it’s not like many other configuration formats have that either.
I use bat sometimes, but how do you stop it from wrapping lines?
$ cat ~/.config/bat/config
--wrap=never
You can manage multiple machines with a single Nix configuration git repository and modularize the configuration as much as you want. You can have a config with a desktop environment that you skip on servers, override individual variables for a specific host or do whatever you want. You can even remote deploy it all with a simple
nixos-rebuild build --target-host "user@host"and it works across different architectures too (e.g. build on your fast x86 machine and deploy to a slow RaspberryPi).