[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).

[qazxcvbnm]

Pinning in nix is rather easy; either `nix registry pin nixpkgs` or explicitly `nix registry add nixpkgs github:NixOS/nixpkgs/925b70cd964ceaedee26fde9b19cc4c4f081196a` does the job. For specific packages, flakes and flake locks manage this fairly automatically as well. Do they not suffice for you?

For grabbing a package from another version of nixpkgs, its quite straightforward to only use that specific nixpkgs for one package and nothing else. NixOS also keeps old generations around in case the new configurations break anything, so I'm not very worried about the OS being rendered unbootable in any case (although I've never managed to break my NixOS, so I can't attest to having made use of this personally).