Comment by rgoulter
1 month ago
Right.
Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front.
I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: until you've felt what a comfortable design is, you cannot imagine it.
Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds.
At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working can be a real headache. Like recently when CMake was upgraded to 4.0, it took down a healthy handful of packages, which meant you couldn't update anything until things were resolved or you were really fluent in Nix hackery. (I was the former)
I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.
It's really easy to pull those handful of packages from an older version of nixpkgs. I had to do that when there was some buggy firmware in the latest (at the time) version of linux-firmware. You just:
1. Add a new input to your flake of nixpkgs pinned to a specific commit or branch. For example:
2. Add an overlay where you replace those packages with versions from the older nixpkgs. For example:
Thanks! I will write this down so I can try it out next time. I really want to get better at these little things but it can be tough sometimes without concrete examples like this.