4 ms·

Even updating once per year is still a battle. It avoids the constant breakages from using unstable, but the problem is even the mainline “stable” nixpkgs will

Even updating once per year is still a battle. It avoids the constant breakages from using unstable, but the problem is even the mainline “stable” nixpkgs will break because there really isn’t a good integration story for all of these components. Case in point: I just spent an hour this week pointlessly updating my home manager config because home manager just decided that a breaking api change would go in. The nix people have designed the ecosystem in such a way that everyone’s bespoke configuration can break at any given point and there is not an easy way to integration test even every common scenario. In other words, the old adage still rings true. The beauty of Nix is that you can do anything. The ugliness of nix is that you can do anything

inahga 1y ago
What's been driving me batshit is when nixos-rebuild decides it wants to build from source. I just burned an hour the other day trying to update, and getting stuck because Nix decided my little old laptop needed to compile node.js from source. Had to trial-and-error remove packages to figure out which one was transitively pulling in node.js. It turned out to be ansible... which is a pure python tool. Beats me. There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM. I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.
- SOLAR_FIELDS 1y ago
  Less than a week ago I complained about nearly the exact same issue and received the typical “nixy” response “that’s what the cache is for”. Well, that’s excellent news, when the cache actually works as expected. I see this a lot with my flake.nix per repo configurations too. The flake.nix never changes, yet it inexplicably rebuilds packages sometimes
  - sshine 1y ago
    I've been wondering about that too. I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild? I don't know. I try to `nix flake update` my system configuration every 2-3 months. Arguably, running Arch and not updating frequently is a pain, too.
    - pshirshov 1y ago
      > eventually the nixpkgs of the project is garbage collected You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)
      - sshine 1y ago
        Are you saying that the presence of a result/ symlink means the sources are kept, and if I remove the result/ symlink, it gets gc’ed?
        pshirshov 1y ago
        Yes, gc root links are accounted at the moment they are written by nix and they retain the graph while they are continue to exist.
- pshirshov 1y ago
  > Had to trial-and-error remove packages There are introspection tools for that. > Build from source That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)
- ghthor 1y ago
  This happened across the board to everybody as there was some change that went into unstable that broke 1000s of packages, everybody was rebuilding nodejscause it failed to build (thus wasn’t in the upstream cache). It’s a good idea to pin you nixpkgs with with flakes or fetchgit in your config and not use channels. Or stick to stable(can’t do this on macOS as easily though, this is where I learned this). You can use hydra to observe the ebb and flow of broken packages getting fixed and pick good git hashes to pin to. Once I figured that out I was very happy and had a good time glancing through hydra to monitor this. Now I can make informed decisions about what hash I build from and still keep unstable train, upgrading more often then I was before.
pshirshov 1y ago
> a battle Everything is a battle and nix battle is bit less hopeless than the imperative distro battle, but again, nix is bad but noone wants to build a better thingy. I've seen countless attempts and I'm trying to make my own build system (not targeting linux distros though). The problem is extremely hard. Essentially you have to build a general purpose PL which is better (more introspectable/debuggable/extensible) than other GPPLs.

inahga 1y ago

What's been driving me batshit is when nixos-rebuild decides it wants to build from source. I just burned an hour the other day trying to update, and getting stuck because Nix decided my little old laptop needed to compile node.js from source. Had to trial-and-error remove packages to figure out which one was transitively pulling in node.js. It turned out to be ansible... which is a pure python tool. Beats me. There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM. I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.

SOLAR_FIELDS 1y ago
Less than a week ago I complained about nearly the exact same issue and received the typical “nixy” response “that’s what the cache is for”. Well, that’s excellent news, when the cache actually works as expected. I see this a lot with my flake.nix per repo configurations too. The flake.nix never changes, yet it inexplicably rebuilds packages sometimes
- sshine 1y ago
  I've been wondering about that too. I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild? I don't know. I try to `nix flake update` my system configuration every 2-3 months. Arguably, running Arch and not updating frequently is a pain, too.
  - pshirshov 1y ago
    > eventually the nixpkgs of the project is garbage collected You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)
    - sshine 1y ago
      Are you saying that the presence of a result/ symlink means the sources are kept, and if I remove the result/ symlink, it gets gc’ed?
      - pshirshov 1y ago
        Yes, gc root links are accounted at the moment they are written by nix and they retain the graph while they are continue to exist.
pshirshov 1y ago
> Had to trial-and-error remove packages There are introspection tools for that. > Build from source That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)
ghthor 1y ago
This happened across the board to everybody as there was some change that went into unstable that broke 1000s of packages, everybody was rebuilding nodejscause it failed to build (thus wasn’t in the upstream cache). It’s a good idea to pin you nixpkgs with with flakes or fetchgit in your config and not use channels. Or stick to stable(can’t do this on macOS as easily though, this is where I learned this). You can use hydra to observe the ebb and flow of broken packages getting fixed and pick good git hashes to pin to. Once I figured that out I was very happy and had a good time glancing through hydra to monitor this. Now I can make informed decisions about what hash I build from and still keep unstable train, upgrading more often then I was before.

pshirshov 1y ago

> a battle Everything is a battle and nix battle is bit less hopeless than the imperative distro battle, but again, nix is bad but noone wants to build a better thingy. I've seen countless attempts and I'm trying to make my own build system (not targeting linux distros though). The problem is extremely hard. Essentially you have to build a general purpose PL which is better (more introspectable/debuggable/extensible) than other GPPLs.