| 10 Apr 2026 |
K900 | https://nixos-and-flakes.thiscute.world/ is another resource that is commonly recommended | 16:30:50 |
QuadRadical (Ping) | if you learn one, you will know the other | 16:30:42 |
K900 | That is also decent | 16:30:53 |
QuadRadical (Ping) | lix also uses nix the language | 16:30:47 |
K900 | You learn Nix, and you can use Lix as your Nix implementation | 16:31:06 |
Display Name | Thanks | 16:31:09 |
K900 | It is mostly a drop-in replacement | 16:31:21 |
K900 | (though this one is mostly focused on NixOS, not Nix on other systems) | 16:31:32 |
aloisw | In reply to @k900:0upti.me And I don't think we have prebuilt musl binaries? I wonder if it would make sense to offer the installer as statically linked with musl binaries? Then it'll work regardless of the host libc. | 16:54:29 |
K900 | Maybe? | 16:55:24 |
K900 | Not sure if it'll explode | 16:55:26 |
aloisw | It's Rust, that usually works relatively nicely with musl? | 17:42:59 |
sorrel | In reply to @piegames:flausch.social I'm currently afk, please ping me on Tuesday if nobody beats me to it until then unfortunately i missed tuesday, apologies | 21:57:21 |
| 11 Apr 2026 |
| ladas552 joined the room. | 02:06:16 |
blitz | Hey! I just switched to Lix 2.95 and it's become all spammy evaluating nixpkgs, because of:
warning: using or as an identifier is deprecated because it cannot be used in most places (try let or = 1; in or). Use --extra-deprecated-features or-as-identifier to disable this warning.
at /nix/store/80jiav8nl8hsx2sf4miaihfacajn1i5h-source/lib/default.nix:105:49:
104| inherit (builtins) addErrorContext isPath trace typeOf unsafeGetAttrPos;
105| inherit (self.trivial) id const pipe concat or and xor bitAnd bitOr bitXor
| ^
106| bitNot boolToString mergeAttrs flip defaultTo mapNullable inNixShell isFloat min max
and other deprecation warnings. I'm able to silence these, but what's the idea going forward? Is evaluating nixpkgs silently only possible with extra configuration? This seems a bit of an adoption hurdle.
| 11:18:38 |
blitz | * Hey! I just switched to Lix 2.95 and it's become all spammy evaluating nixpkgs, because of:
warning: using or as an identifier is deprecated because it cannot be used in most places (try let or = 1; in or). Use --extra-deprecated-features or-as-identifier to disable this warning.
at /nix/store/80jiav8nl8hsx2sf4miaihfacajn1i5h-source/lib/default.nix:105:49:
104| inherit (builtins) addErrorContext isPath trace typeOf unsafeGetAttrPos;
105| inherit (self.trivial) id const pipe concat or and xor bitAnd bitOr bitXor
| ^
106| bitNot boolToString mergeAttrs flip defaultTo mapNullable inNixShell isFloat min max
and other deprecation warnings. I'm able to silence these, but what's the idea going forward? Is evaluating nixpkgs silently only possible with extra configuration? This seems a bit of an adoption hurdle.
| 11:18:52 |
Yureka (she/her) | update your inputs | 11:19:44 |
Yureka (she/her) | people have been running with these warnings enabled since months, and have fixed pretty much every occurrence in the ecosystem | 11:20:09 |
blitz | mmh. it comes from nixpkgs-lib. let's see... | 11:20:48 |
Yureka (she/her) | that version of nixpkgs is at least more than one year old, because the section was reformatted on 2025-04-01 | 11:21:50 |
Yureka (she/her) | It can be surprising though how old versions of nixpkgs end up in your eval | 11:22:14 |
blitz | yes, currently digging :) | 11:22:25 |
Yureka (she/her) | nix flake info can be helpful | 11:22:31 |
blitz | it's my own fault obviously :) | 11:23:30 |
blitz | but what are the current thoughts wrt to being able to evaluate old nix evaluations? | 11:26:30 |
Yureka (she/her) | it's just a warning | 11:26:49 |
hexa |
Use --extra-deprecated-features or-as-identifier to disable this warning.
| 11:26:56 |
blitz | yes, I know :) | 11:27:07 |
blitz | but where does lix want to go. will there be a time where old nixpkgs cannot be evaluated anymore? | 11:27:33 |
raitobezarius | my view or opinion on this is that you could imagine a pre-rewrite pass | 12:00:35 |