| > I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Yea, i actually do that for a couple of my dependencies. My problem is there are dozens or hundreds in my OS that instantly upgrade if i change my `nixpkgs` ref. And i have no clue what version _any_ of those are at, off hand. Eg lets say i want to fix my X - because when i updated my `nixpkgs` pointer Xorg was using a lot of CPU for some reason. There's no lockfile that says what version X is at, or what dependencies X is using or associated with. Is it one package? Is it a half dozen? I could open the repo and dig through the configs to locate it and _try_ to infer what the hell version it's at, and what dependencies it has.. and then find what they're at and so forth - but it's convoluted imo. Much easier in Cargo.lock, for example - something i've done dozens of times before. In short, basically everything in my OS broke when i updated my nixpkgs ref, and it's non-obvious and maybe non-trivial to understand what versions everything is at. To incrementally try to un-screw my system when i change my nixpkgs. As i move forward, any packages i install i'm tempted to bind them to very specific inputs. So that when i want to upgrade one thing, only that one thing changes. But this workflow seems difficult in NixOS. Despite it being the workflow that i want. Well, maybe not difficult - but lots of LOC. Adding dozens of inputs just to change versions of stuff without breaking other things seems like a lot of work for a dependency management system.. imo. |
I have a script which I use [1] after updating my Flakes to do just that : know what has been upgraded.
[1] https://github.com/nix-community/nur-combined/tree/master/re...