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: github.com/Atemu/nixos-config/…/overlays.nix#L29-…. 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?