The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works.
Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.
> Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.
Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine.
You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code.
Put those tools in your systemd service before launching your app, and you're good to go.
(NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I haven't seen the final picture. I imagine it's lovely compared to what we had before)
I don’t feel it introduces too much abstraction. The only thing it does basically is patch linked libraries to a hardcoded nix store path, so that your whatever exe will not look in a standard place for an ambiguous lib, but one that is identified by a hash. Similarly, it often wraps programs with specific env variables, like set JAVA_HOME to a nix store contained java install. It’s quite elegant that it gets away with such ordinary methods, instead of docker/flatpak-like run it in a specific low-overhead vm, overlayed fs, whatever.
It does cause all sorts of problems with non-nix-aware software, but most software can be tamed, and what absolutely refuses to run, can be run with steam-run or by a user-created environment mimicking a “normal” distro.
The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works.
For me, the big benefit is that even though I have to read the upstream documentation, I can use the same syntax for everything and do not have to learn and use N different configuration file syntaxes.
I wonder if something like that for nix would help you.
E.g. have the nix config in consul; and have the local daemon `watch` the consul config (And services) and build and acitvate the nix thing every time the consul config changes.
Could maybe even do automatic rollbacks based on consul health checks.
What the hell is the second part? Are people really installing software as part of the normal workflow of some deployment? Unless the thing is supposed to be some sort of heroku like thing, that's insane.
Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.