Yes, I think that I use it but I had to stop using it because it was too cumbersome to get all my brew programs updated/checked every time I was doing changes to my nix config (wich at the beginning was quite often)
That looks interesting. Can it be used with flakes?
That is the beauty of nix, right? However when I want to update atuin to it’s latest version, I am not going to test all other programs to see if they broke. Therefore, I may find the problem in 2 days or 2 weeks when I try to use the other program that broke, and at that time will I be able to remember the problem was that I “recently” updated? Or will I waste time trying to figure it out? Maybe I can get used to it, but, I don’t trust myself that much
That is exactly what I do, and works nice for packages. For applications though, I can’t have applications that I use globally (atuin, fish, zsh, firefox…) to be defined per environment, and that is where my issue actually is.
Yes, I understand that. That is precisely why I opened this question, hoping to get workarounds from people smarter than me (as I was not able to figure out) to be able to keep using nix for as much as possible while reducing the drawbacks as much as possible
Ah, yes.
I already bookmarked the package search, but because you pointed to the API I got confused.
Really good resource, thanks. Really reduces the tedious task of finding the right nixpkgs version to use
But I usually avoid doing actual home manager modules/configs, trying to stick to only using home manager for installing packages via adjustinghome.packages itself.
Mentioned briefly already, but I think this really needs to be stressed:
I agree that nixpkgs-multiverse painlessly enables exactly what @danielo515’s workflow looks like.
But I would like to stress that this is a potentially dangerous approach from a security standpoint. Unless one regularly checks for CVEs and security patches in all of the pinned and manually updated packages and all of their dependencies (since they will be pinned, downloaded, and executed as well; all the way down to glibc), you open yourself up to a potentially insecure system and packages (as eventually one will stop updating a package here and there, either by not having the time to update or forgetting about it). This is dangerous, especially in this era of LLMs, where CVEs are popping up like mushrooms after rain. Everyone, do as you will (the beauty of FOSS), but be mindful of your actions and their repercussions, and make an informed decision based on the trade-offs and your preferences
Agreed. In my opinion, the really correct solution is to use a stable distro (Red Hat Enterprise, Debian, or Ubuntu), that do minimal/no feature updates, or major bugfixes, in order to avoid breaking changes.
And then they can safely automatically ship security security updates. The fact that they try to stay away from changing any other system behavior than security related issues in components, means that, there is a guarantee that your system will work the same tomorrow, as it did yesterday. You get the same, predictable bugs, instead of a changing set of them.
For this reason, those solutions are popular in enterprise environments, where they have servers that they want to stay working the same, users that lose their mind if a button was moved, and not enough funding for security to manually handle every machine or CVE.
Unfortunately, OP seems to be on a Mac, and “switch to Linux” is probably an even worse answer than “Don’t use tools that break on updates” (Even though I agree with both answers)
