Linux

what if a package’s dependencies are out of date?

This is rarely the case as we usually don't keep older patch versions or whatever. Most packages will just be updated "in-place". We might keep a few major versions of some major packages though if some other packages have a hard dependency on some older API/ABI. When that happens and an old major version goes EOL/has security issues, it's marked as insecure and you'd have to explicitly opt into using it by allowing its version in your config.

it’s (nearly) impossible to actually do your own manual imperative editing of packages to solve a quick problem since everything is declarative.

You can do your own declarative "editing" of packages: Overrides allow you to override any dependency of a package and receive a package where that dependency is the other thing you put in.

Overlays allow you to "edit" packages in the context of a package set where the package's dependants in the set also receive the "edited" package as their dependency.

It's fairly normal to have an overlay in your config to customise a few packages to your liking. Anything that needs youtube-dl gets yt-dlp with the youtube-dl executable alias in mine for example: https://github.com/Atemu/nixos-config/blob/b79f42793a709db083cf53867f85d5d46e41eb69/overlays.nix#L29-L33. Stuff like that.

Also note that, if a package is broken, it's usually best to fix it upstream rather than patching around upstream in your own config. The package being unbroken for every NixOS user instead of just yourself is one PR away; it's super easy to contribute to Nixpkgs.

Nix uses mostly its own configuration methodology, so isn’t this a maintenance nightmare as config files change and options are added/removed?

In NixOS, this doesn't happen very often. Most options have been there for years and go unchanged for years aswell. At least in terms of API; they might do different things internally to achieve the options' goal but you don't need to care about that; you just state your intent. There are many ways to install i.e. systemd-boot to your ESP but you only care that it's installed, not how.

When a breaking change happens in the options' API, you'll know about it at eval time. It'll show you an error stating that e.g. the option has been renamed to so and so and perhaps the semantics changed. Many times it'll just be an eval warning even, stating that the option has been renamed and has been set to your old option's value but you should move over because this fall-back will be removed in the next release.

Note that if you don't like breaking changes coming in willy-nilly, the stable channel (23.05 currently) would be for you: It restricts such option changes and you only have to change your config to accommodate option changes twice a year when a new release comes out. As I said though, breaking changes don't happen very often for your average NixOS config even on the unstable channel. This isn't really as much of an issue as you might think.

Can't really speak for home-manager as my use of it is quite limited and it's a nix-community project, not a NixOS one (different quality standards).

I have come to the realiziation that, unlike a traditional distro like Arch/Alpine which I used previously, if maintenance dies I cannot feasibly maintain it myself, since it's mostly "magic".

That's just because you don't have experience packaging or maintaining Nix packages yet. If you didn't know how to package Arch/Alpine packages, you would be just as screwed if maintenance was dropped.

Once you've done a few patches to packages or even packaged something yourself, this "magic" will become more and more disenchanted.

The upkeep of all the configurations plus all the dependency packages, and making sure each package compiles and matches the build configuration is a nightmare.

Not quite sure what you mean here. Could you point out some concrete examples of that?

I do overlays of software to patch it all the time. Eventually I'll package it, but it needs upstream fixes, so I'll try to package my own fork

The way NixOS is, the initial setup of all the different things you would want is incredibly time consuming and it has a very very steep learning curve. It was incredibly difficult for me to set everything up. I tried to make it work and then ran away 4 times now, each time starting from the configuration I've had so far, and building up on it. I still haven't been able to perfect my configuration, and I've been on NixOS (this time) since mid-June. I haven't been working on it actively, but I have done some work on it. NixOS is just too complex and too much for me to wrap my head around. Personally, I'm leaving it for something else, I'm thinking of Void, and I might go back to Arch for a while, I don't know. Fedora seemed promising, but after the recent telemetry stuff, I crossed it off my list. Tumbleweed seems alright? I'll see. But I totally get it.

I too think that NixOS is amazing. It is really unique (Guix is similar but not quite) yet it is very difficult to learn and maintain properly.

The out of date problem you mention is something Nix contemplates. As of a couple hours ago, if you try to install Etcher (Balena Etcher, that is), you will get a message saying there's an out of date dependency: Electron.

You can still try to install End of Life packages, but you have to type an instruction the 'compiler' tells you to type out. In other words, you have to be deliberate about installing out of date dependencies.

The other problem I understood it as "if I declaratively do this and then imperatively do that, how do I keep track of it all?". If that is indeed what you're asking, you're right. That's a problem. That's why I try to keep everything in the config.

I've been using Nix now for a couple of months and the configuration file has been a great friend. Sometimes I don't know how to configure something and I get lost and worried, but the community has helped me to fix my problems- .

Most derivations are pretty flexible; the ones that aren’t, however, will require you to write your own overlay to fix them. Or just fork them entirely. This is one of the advantages in Nix in that you can create reproducibility at any granularity. Writing and using your own derivation is complex though. Most packages provide more than enough knobs to change their configuration on their own in my experience though — my current Nix build uses no derivations I had to write myself.

Home Manager and Nix itself are versioned so I don’t understand your complaint about config changing. If you’re happy with how your system works just don’t update it to a newer version. If you do, as in any other software, you risk breakage. The advantage of Nix in this scenario obviously is that rolling back in the case of an upgrade going wrong is incredibly trivial.