| 26 Oct 2025 |
 lillecarl | * The logic for fetching really wants things to be online 😄 Edit: (It keeps looping forever) | 22:32:39 |
| 27 Oct 2025 |
 522 it/its ⛯ΘΔ | i was searching for colmena and noticed that it's also in nixpkgs as nixpkgs.lixPackageSets.{latest, git}.colmena: should i assume that this is "colmena but built to use lix" (and i should use that over nixpkgs.colmena if i use lix?). And i guess use git since i also use lix on main? | 00:34:10 |
 just1602 | I don't know if it's gonna rebuild it if your build on main isn't the same as the one in the package set, but personaly I build the package from source directly with my lix build. Like I have this in my flake devShell colmena.defaultPackage."${system}". | 00:38:29 |
| just1602 | But the one from the lix packgeSets should work, tho. | 00:38:47 |
 @dawnofmidnight:catgirl.cloud | if you use the lix module, that automatically applies overlays so that nixpkgs.colmena will do the right thing | 02:03:18 |
| @dawnofmidnight:catgirl.cloud | * if you use the lix nixos-module (https://git.lix.systems/lix-project/nixos-module/), that automatically applies overlays so that nixpkgs.colmena will do the right thing | 02:03:27 |
| @dawnofmidnight:catgirl.cloud | lixPackageSets.git is updated periodically, but it's the same as lix-on-main (it's probably a couple of days behind), and you'll end up pulling the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:07:40 |
| @dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind), and you'll end up pulling the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:07:50 |
| @dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:08:03 |
| @dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache | 02:12:36 |
| @dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache. using it if you also use lix-on-main is decidedly the wrong behavior. | 05:30:55 |
| @dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache. using it if you also use lix-on-main is almost certainly the wrong behavior. | 05:32:05 |
|  νεολαμπής [he/him] joined the room. | 12:36:50 |
|  splurged changed their profile picture. | 16:08:28 |
| 28 Oct 2025 |
 somasis | what's the correct way to get pure evaluation when using nix repl? when not evaluating a flake, specifically. using --option pure-eval true doesn't seem to have an effect as builtins.currentSystem still returns "x86_64-linux" | 14:14:11 |
| somasis | what's the correct way to get pure evaluation when using nix repl? when not evaluating a flake, specifically. using --option pure-eval true doesn't seem to have an effect as, builtins.currentSystem still returns "x86_64-linux" | 14:14:24 |
 hexa | --pure-eval? | 14:23:07 |
| somasis | didn't know that flag exists, but same result, builtins.currentSystem gives "x86_64-linux" :/ | 14:23:44 |
| somasis | didn't know that flag existed, but same result, builtins.currentSystem gives "x86_64-linux" :/ | 14:23:49 |
 jappie | $> nix repl --pure-eval
Lix 2.93.3
Type :? for help.
nix-repl> builtins.currentSystem
error: attribute 'currentSystem' missing
at «string»:1:10:
1| builtins.currentSystem
| ^
nix-repl>
| 14:24:21 |
| somasis | huh... | 14:24:32 |
| somasis | hmm okay that's not good | 14:24:39 |
| somasis | hmm okay that's not good lol | 14:24:41 |
| somasis | I didn't think nix repl -f . would cause that to differ, yet it does | 14:25:17 |
| somasis | I didn't think nix repl -f . while in my config directory would cause that to differ, yet it does | 14:25:24 |
| hexa | I suppose accessing the filesystem like that is impure, that's why nix copies flake repos to the store before evaling 😄 | 14:26:44 |
| hexa | * I suppose accessing the filesystem like that is impure, and that's why nix copies flake repos to the store before evaling 😄 | 14:26:54 |
| somasis | ah, yeah I guess it would have to do with that | 14:27:15 |
