Why I use nixpkgs-unstable
In the majority of my flake.nix files, such as the one I've been experimenting with for Drupal projects, I use nixpkgs-unstable as my primary input.
The nixpkgs package manager has two major releases a year, in May and November, which would be 24.05 and 24.11 for 2024 respectively.
Using nixpkgs-unstable, I get the latest packages and NixOS options and don't need to wait for the next major stable release.
But doesn't that make things more likely to break when updating?
The number of backwards incompatible changes and breakages on unstable are minimal, but I'd rather deal with small issues and updates regularly rather than only twice a year.
Small updates more often are better, in my opinion.
But, what if there is an issue with a package that I'm using, such as a build issue, regression or incompatibility?
With flakes, I can import multiple versions of nixpkgs in the same configuration and use them where the configuration I need to.
I need to in one project, I've added an input with nixpkgs pinned to a specific Git commit in the nixpkgs repository as some packages are using outdated versions and are no longer present in the latest releases.
It's not all or nothing, I can pick which packages to be unstable and which I want to use stable or use older versions.
See my dotfiles repository for an example, where I have four versions of nixpkgs imported - including unstable and master, which is even newer.
Every input is still locked in the flake.lock file, so everything is still reproducible whichever versions of nixpkgs I decide to use.
- Oliver
