[OhSoHumble]

I have been running NixOS on my laptop and on my homelab.

I would not use it for a production system. Currently trying to migrate off of it to, I dunno, something else and Ansible. Nix has eaten hours of my life and upstream packages break all of the time. Couple of weekends ago the Mullvad module broke. Before that Virtualbox. Before that ZFS. You can have a perfectly fine configuration that you never touch but upstream instability will prevent a nixos rebuild from actually working.

[qazxcvbnm]

You don't have to use nixpkgs-unstable though? You can always pin your nixpkgs, which I do, and I've as long as one tests that that version runs fine, then it always runs fine.

[JamesSwift]

Or you can easily split between stable and unstable with an overlay to get the best of both worlds.

[thenobsta]

This seems like a bummer. I'm under the impression that one of the points of nix is to have pain free rebuilds. I wonder how to address this issue and what the source is -- is it a critical mass thing (more users/contributors solving problems)? or an issue arising from inexperienced module maintainers?

[noirscape]

From what I understand it's moreso nixpkgs maintenance policies by default significantly reducing the use you can get from nix' pretty solid dependency resolution.

Basically nixpkgs' maintenance policy is that only one version of a package should exist in their repositories. This being intended to reduce maintenance overhead since the nix package manager can freely switch package versions based on the nix channel (read: git branch or commit that nixpkgs is on).

The problem is that unless you meticulously start version pinning all your dependencies, your tooling will always run on the absolute latest version available, regardless of major/minor updates on either stable or unstable. Which can obviously cause problems.

It requires an extra step of care, one not particularly helped by the fact that actual version pinning for an individual package is done by the nixpkgs channel, rather than specifying the desired semver spec so unless you know beforehand what version is at which commit, it probably won't be helpful when it ends up rendering the OS unbootable (not to mention the questionable use in manually typing over git commit hashes but I digress on that).