This is surely a trivial observation, and probably not the one you’re hoping for here, but if updates regularly break your tools, an avenue of action is to look for tools that don’t do that.
5 Likes
From observing this thread, I think the best solution for you is to use stable+overrideAttrs to get newer packages or a custom fork that cherry-picks from unstable if some changes you want need more involved derivation updates (or just vendor the new callPackage file in that case and use upstream stable+overrideAttrs for simpler package version changes).
Or, not what you’re looking for, but makes finding package updates easier before you rebuild, in case that’s useful to you as well:
I don’t need that to happen regularly for it to be a problem.
I used to use VIM distros and I had to stop using them because I can’t afford my editor stopped working for an entire work day because an update. As a freelance, a day not working is a day not making any money.
So yes, I am taking that decission when the friction becomes big enough, but I can’t do that for all the tools, because everything sooner or later will have a breaking change.
The problem is that the calendar of when someone else decides to launch a breaking change not always aligns with the time window you may have to deal with it.
in your flake.nix my understanding is that
you can declare a specific version and keep it at that specific commit in your input - for example firefox like this:
inputs = { firefox-pinned.url =
“github:NixOS/nixpkgs/0123456789abcdef0123456789abcdef01234567”;
};
then in your outputs you would just have to declare
firefoxPkgs = import firefox-pinned {
inherit system;
};
and finally in the environment.systemPackages you would have to refer to that package as
firefoxPkgs.firefox
I can’t speak to production grade reliability for this method as I would suggest rather sticking to stable updates and only specify unstable for newer packaging you want as I answered earlier.
Just mentioning, because no one did up to now, and you mentioned you want to check latest version of a specific tool. For testing out new stuff, you can create ephemeral shells: $ nix-shell -p <your-desired-package>, but I’m not sure if this is also easily expandable to an example where you pin the version.
Another thing to keep in mind, some tools are evolving so quickly (maybe because of cheap claude code) that even nix’ unstable lags behind. Being on a mac, maybe it’s sensible to add them in the imperative way (cloning the source, build, etc, …, like in the old days). If it’s about small cli stuff, it may be the most time-efficient approach.
For what it’s worth, I’m also a contractor and the reason I use Nix (OS) in the first place is so I have quick time to recovery in the event of work machine failure.
I’m facing the same constraints as you and my own answer has been update regularly and defer / rollback updates in case there happens to be a problem. It’s worked for me because with the set of software I use, problems happen to be rare.
It’s somewhat off topic to what you’re asking for, but it’s just highlighting the general software principle where if you’re not getting the results you’re hoping for, one avenue is to change the system and another is to rephrase your requirements in some sense.
5 Likes
That is a good advice, and is what I do when I want to test a new package before deciding if I want to add it permanently to my setup or not. But never thought about using it for a “new” version of an existing package.
Yes, or just using brew. However I want to minimize the number of “manual steps” to get a new machine to a working state equal to the one I’m currently using.
Thanks for the advice. System so far it’s good. Maybe I should opt-out certain things from it, but I don’t want to change the whole system again.
Changing my requirements is also a sensible thing. It’s another way of saying “subvert your expectations” 
1 Like
Should look similar to this (assuming flakes usage):
# Installs ripgrep exactly at version 13.0.0 using Nixhub's Flake registry
nix shell github:jetpack-io/nixhub/ripgrep-13.0.0
1 Like
You might be interested in `nix profile`s are hard to reproduce · Issue #7965 · NixOS/nix · GitHub
As part of your ‘profile’ a manifest.json file is created and maintained by the nix profile cli. It holds all packages and versions to reproduce the full profile. See manifest.json - Nix Reference Manual
Nix just doesn’t allow reading/writing this file from/to any other place than $XDG_STATE_HOME/nix/profiles, which is kind of a bummer.
In general Nix profiles just don’t get much love as everyone is using home-manager and nixos configuration, which have a uncomfortable ux compared to package managers new Nix users are used to. This is a more general issue being tracked in `nix profile` has bad UX · Issue #7966 · NixOS/nix · GitHub
3 Likes
I do other things in my life apart from fixing my nixos config, and I was annoyed by having to fix stuff during regular updates too. But I’m not anymore.
I switched to nixpkgs-stable about 2 years ago, and I’m not sure if I ever had problem during regular updates of my system since. Of course, I still have to do breaking channel updates every 6 months, but these give me 1 month window to pick when I want to do that. If there are multiple breaking updates it’s also possible to fix them one by one, not all at once, though it’s a bit easier to do that all at once. I’m using neovim daily for work too, never had problems with it during regular updates as well.
When I want to update one specific package/module to latest version I pick package/module from unstable. If possible via separate flake or shell, not by adding it to my system configuration.
If there are too many breaking updates so you can’t find any good time to fix them, then unfortunately the only solution is to use different packages.
9 Likes
Funny, I switched from stable to unstable, as I had easily 5 minutes to spare as I update to also fix any configuration problems. While I regularly don’t have a full day to sit down and fix all the breakages at once that commonly occurred when updating from stable-prev to stable-now.
5 Likes
I switched to stable when unstable updated from KDE Plasma 5 to 6. This was very breaking update for me that I was fixing over multiple day long sessions. So it can be 5 minutes, or it can be 5 days. Stable gives you a month of time, during which you still receive security updates. With unstable you would not get any updates until you’ll fix your config.
Yeah, the plasma update was very disruptive for me as well.
It broke my awesomwm setup, and I used plasma for the last half year or so. Last week I switched to mango + noctalia.
It’s not perfect yet, but much better than plasma…
I’ll just note that I’ve migrated many of my packages from the .nix files to Nix Profile.
I’ve had to many issues where a Nix Package name changed, or a CVE for a program I absolutely had to use. This allowed my system to always be updated (as i was concerned about my system especially web browser) being out of date. (I don’t manually update my system.)
For the Nix Profile, I have a systemd timer (via nix) to cycle thru each package added thru Nix Package and update that way it doesn’t error out if one package fails. (If I had to redo, I would might consider grouping them together.)
Theoretically, I could have a systemd to do a oneshot on the packages that I need, but I’m okay if its not reproducible.
What I’ve learned for my specific needs, I need it to just work & update.
Just my journey, as I’m not the most adept. I had to use AI to help write the code for me to do the above, and I’m sure its slop but it is working okay.
2 Likes
OP, does Flatpak solve any of your woes? It’s mentioned 0 times in this thread. I know not all Flatpak apps work great under NixOS, but what’s important is yours do.
Then you can manage your base OS with nixos-<vv.vv> and I think few OS are as stable as that.
/e This is my dumb ass not reading you’re on Mac. I’m completely off topic, sorry
/e Flatpak itself works great under NixOS, btw
Have you tried this - GitHub - zhaofengli/nix-homebrew: Homebrew installation manager for nix-darwin · GitHub
I’m pretty sure this also solves your problem with a nice Nix API (at the expense of more closure bloat):
2 Likes
What a great tool, thanks.
1 Like
Thank @fzakaria! All I did was remember this thread and share it here. 
1 Like
If the specific usecase here is that tools breaking is disruptive for you, what about an alternative solution of rolling back if changes are disruptive?
For example, if you are using home-manager, you can restore the previous generation of installed packages, instantly reverting to whatever you had previously installed. You would still be updating everything at once, but the ability to rollback would mean breakages wouldn’t interfere with your flow. If something breaks, you can just rollback and then address it later.
Secondly, you may want to consider development environments per project. I use dev shell’s for each project, each with their own packages that I can update all at once, or I can roll back via the flake.lock. This means that when I update, breaking changes only affect one project, instead of every.
As other users have mentioned, it’s a huge technical challenge to provide specific package versions for a whole Linux distro, due to how integrated how many components are. Nix doesn’t really try to do that, but still manages to fulfill that usecase via alternatives.
2 Likes