| 11 Apr 2026 |
 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 |
| raitobezarius | to keep using Lix with very old Nixpkgs that suffers from deprecated features | 12:00:57 |
| raitobezarius | I personally care about the ability to evaluate over decades but I don't want this (secondary?) goal to stand in the path of evolution, so there must be some mechanisms to achieve both things while balancing out efforts | 12:02:15 |
| blitz | Yes that's sensible | 12:55:57 |
| blitz | Since most of the deprecations are just syntax, having a way to specify what nix language version you want to parse would also be cool (a bit like rust editions) | 12:57:09 |
| raitobezarius | It's the whole topic of langver at Lix that we want to address someday | 12:59:32 |
| raitobezarius | (there's also its variants: derivation versions too) | 12:59:47 |
 lassulus | langver would be cool | 13:31:18 |
 kfiz | Indeed. I think there needs to be a clear story or at least good “central” recommendations on how to approach which use cases in lix (nix). Currently it’s to confusing even for people who have been using nix for a while. | 15:42:30 |
| raitobezarius | Yep, definitely | 17:10:42 |
 Lotte (it/its)/Cinny (she/her) θΔ& | is there a lix equivalent of the cppnix setting [abort-on-warn](https://nix.dev/manual/nix/2.24/command-ref/conf-file#conf-abort-on-warn)? | 18:27:03 |
 whispers [& it/fae] | yes it's abort-on-warn (added in 2.95) | 18:32:20 |
| whispers [& it/fae] | second item here https://docs.lix.systems/manual/lix/stable/release-notes/rl-2.95.html#features | 18:33:17 |
| Lotte (it/its)/Cinny (she/her) θΔ& | oh | 18:39:26 |
| Lotte (it/its)/Cinny (she/her) θΔ& | should have used .latest instead of .stable | 18:40:01 |
| Lotte (it/its)/Cinny (she/her) θΔ& | thanks | 18:40:06 |
