| 15 Oct 2025 |
 piegames | But also, I think that we should probably look into module systems first to see if they can solve that better | 05:53:39 |
 eyJhb | Minor thing raitobezarius , but the ! at the end of the link in #announcements:lix.systems gets interpreted as part of the link in some clients :D | 05:58:38 |
 Charles | i would guess a module system would fulfill this desire, yeah | 06:04:16 |
 KFears (burnt out) | Is there anything that improves modules planned, btw? | 06:14:07 |
| Charles | In reply to @kfears:matrix.org
Is there anything that improves modules planned, btw? This is modules as in programming language module systems, not as in nixos modules | 06:18:38 |
| KFears (burnt out) | Ah
Well, anything for NixOS modules, as a treat? :) | 06:21:37 |
|  MrWildBunnycat joined the room. | 14:54:40 |
|  ellyse_e joined the room. | 17:10:09 |
 antifuchs | inspired by a conversation earlier, I got a f attribute on my lix repl now that loads the flake in the current directory, but using flake-compat (and searching upwards for a flake.nix). took a looong time, but yay (also, I guess the best thing about this is the realization that I could import nixpkgs/lib as a lib repl attribute too) | 23:00:58 |
| 16 Oct 2025 |
 somasis | sorry if this is too off topic, but i've been wondering lately (especially since the flakes feature freeze stuff was posted): do people have suggestions of best practices for organizing nixos configs without using flakes, involving niv, npins, or lon, or whatever? I started using nixos using flakes, but i'm interested in reorganizing my config to work without flakes now (ideally without channels ever being involved) | 01:51:58 |
 ekler | i find npins to be okay, it's also easy to use
| 02:21:41 |
| ekler | just note that there's two things called "channels": the things on channels.nixos.org (and you can manage references to those with npins which allows proper locking) vs the stuff on your local system that is managed via nix-channel + NIX_PATH (which is the impure, messy stuff that you don't want)
| 02:23:28 |
| somasis | indeed | 02:28:41 |
| somasis | I think one of the things that trips me up with flakes vs. non flakes is how nixos-rebuild finds the host you're trying to build, compared to when it's expecting a non-flake configuration; it seems like you're not expected to have multiple hosts in one configuration directory in non-flakes style, yet you are with flakes. so it makes me wonder if there's practices people have came up with for maintaining some of the nice stuff about flake-oriented configuration style without relying on flakes | 02:31:07 |
| ekler | i would still use the hosts/*.nix setup, where each file is an entry-point for a respective host, and use -I nixos-config=hosts/thishost.nix or whatnot
| 02:34:03 |
| ekler | obv that's not the only way to do it, but it works for me
| 02:34:19 |
 mjm | yeah that's a decent way. i skip nixos-rebuild entirely and build the config through my own tool, doing equivalent steps to what nixos-rebuild would do | 02:35:34 |
| somasis | makes sense | 02:35:52 |
| Charles | i use (and disclaimer: maintain) this https://git.afnix.fr/sprinkles/sprinkles with lon (but you can use whatever pinning tool) and if you want a practical example my dotfiles repo is https://gitlab.computer.surgery/charles/dotfiles (also i just noticed the readme is a little outdated) | 02:37:54 |
| Charles | there's also https://github.com/nilla-nix/nilla which has a similar goal but is different | 02:39:21 |
| Charles | you can tell nixos-rebuild to use an arbitrary attribute path from an arbitrary nix file | 02:40:09 |
| Charles | (though i tried this a long time ago and ran into some issues so i wrote my own, terrible-r version of nixos-rebuild which is https://gitlab.computer.surgery/charles/dotfiles/-/blob/dae8665ee2961c14af67e0eeea95eea993d504bc/bin/system) | 02:41:37 |
 Psentee | somasis: I'm right now switching to npins+nilla, nilla's built on aux lib modules and quite nice to use, but not well documented, and I'm using raw nix -f ./nilla.nix … more than their nilla CLI. If you want to take a look at some actual config, public pieces of mine are at https://codeberg.org/psentee/etwa/, and there's also a more complex https://github.com/jakehamilton/config/ using the same tools | 08:52:51 |
 lillecarl | nix build --refresh --impure --print-out-paths --out-link /nix/var/nix/gcroots/nix-csi/csi16a0b640557000b87a44b5798b8c964ee33f0381815d40f9917e78dd32fb7b81 --file /tmp/tmpjmw9i720.nix
nix-csi-node-sg8p6 nix-csi-node 2025-10-16 10:15:37,979 DEBUG [nix-csi] warning: error: unable to download 'http://nix-cache.default.svc/87bdp04miawiffqc9k8n2m2p172fx6dj.narinfo': Failed to connect to nix-cache.default.svc port 80 after 0 ms: Could not connect to server (curl error code=7); retrying in 2591 ms (attempt 4/5)
Could someone explain how this makes sense, shouldn't --refresh bypass the unreachable cache?
| 10:19:57 |
 raitobezarius | isn't --refresh only about refreshing eval-time artifacts? | 10:21:56 |
| raitobezarius | if you want to bypass an unreachable cache, you should either disable it to avoid paying the expbackoff timeouts or accept the expbackoff timeouts | 10:22:42 |
| raitobezarius | (or pass --offline but its chance of successes are meager, this feature is broken) | 10:23:09 |
| lillecarl | narinfo-cache-negative-ttl = 0
narinfo-cache-positive-ttl = 0
I've got these set in config too. The problem is that I'm bootstrapping the nix cache that isn't working and the build doesn't continue here at all.
You think the best way is parsing the error messages for "warning: error: unable to download" and rerun the build without the cache configured? It'll be hard to do "properly"
| 10:26:54 |
| lillecarl | (It's been up once before obviously :P) | 10:27:22 |
| raitobezarius | I don't think that's the best way | 10:27:24 |
