| 15 Apr 2026 |
 hexa | if that is the case, you'll likely want xdg.portal.xdgOpenUsePortal | 23:14:43 |
| 16 Apr 2026 |
 olivia | am I correct that after this change, I should be importing the lix module as nixos-module.nix rather than module.nix? | 01:57:53 |
| olivia | (if so I can make a PR to update the docs) | 01:58:06 |
 EsperLily [she/her] | Lix 2.95 added deprecations that keep triggering when I import nixpkgs. Latest nixpkgs doesn't trigger any warnings but or-as-identifier was only fixed in nixpkgs 3 months ago. I have a project whose direnv is pinned to a nixpkgs that predates that change, and getting warnings about that every time I use nix repl to poke at that package set to check things has been annoying enough, but I just discovered today that another project is pinned to a nixpkgs that's sufficiently old that it spews a bunch of other warnings too (I recall the last such warning it printed was broken-string-indentation but I didn't look at the whole list).
I'm all for deprecating stuff where it makes sense, but there's nothing at all I can do about deprecations in older nixpkgs, I have those old nixpkgs pinned for a reason. I know flakes have a feature that let you put configuration settings into the flake so perhaps I could set extra-deprecated-features that way but then I don't get the deprecation warnings in my own code, and that also presumably doesn't work for the nix repl --inputs-from . nixpkgs case. I feel like maybe it would make sense to suppress deprecation warnings coming from flake inputs?
| 03:14:06 |
 Emma [it/its] | that's a valid point, i cant wait to have to lock nix because i depend on nixpkgs 23.05 | 03:15:26 |
| Emma [it/its] | * that's a valid point, i cant wait to have to lock lix because i depend on nixpkgs 23.05 | 03:15:51 |
| EsperLily [she/her] | this solution wouldn't do anything for folks using non-flake approaches to pinning nixpkgs of couse, which suggests that perhaps there should also be a way to say "import this path but suppress deprecation warnings in it" | 03:16:41 |
| EsperLily [she/her] | i suppose in the meantime for non-flakes users there's an equivalent to the per-flake settings which is using direnv to set NIX_CONFIG in order to set extra-deprecated-features, though again it sucks to suppress deprecations in local code just because of pinned dependencies | 03:21:25 |
| EsperLily [she/her] | * i suppose in the meantime for non-flakes users there's a semi-equivalent to the per-flake settings which is using direnv to set NIX_CONFIG in order to set extra-deprecated-features, though again it sucks to suppress deprecations in local code just because of pinned dependencies | 03:21:38 |
| olivia | if you don't care about getting the warnings on new code, you can disable them everywhere | 03:37:03 |
| olivia | which I'd think is straightforwardly preferable to using old lix specifically because of deprecation warnings | 03:37:22 |
| EsperLily [she/her] | or maybe the solution is "if we're importing a path from the nix store suppress warnings, unless this nix store entry was the result of referencing a path: or git+file: flake outside of the store that then got converted into a store path". if it's in the store and not originally from the local filesystem then it's some sort of dependency and deprecation warnings are unlikely to be helpful. that should presumably cover non-flake usage too, it's been ages since i looked at any of that but i assume that all generally works by downloading inputs into the store and recording the store paths into some form of lockfile | 03:51:40 |
 aloisw | As far as I know, at the point the import happens it is not known any more where the flake originally came from. | 04:17:08 |
|  Perchun Pak [don't randomly ping] changed their display name from Perchun Pak [don't ping; dm instead] to Perchun Pak [don't randomly ping; dm instead]. | 17:07:22 |
| Perchun Pak [don't randomly ping] changed their display name from Perchun Pak [don't randomly ping; dm instead] to Perchun Pak [don't randomly ping]. | 17:16:05 |
| 17 Apr 2026 |
|  @sapphoqt:matrix.org left the room. | 03:23:14 |
 Qyriad | In reply to @aloisw:kde.org
As far as I know, at the point the import happens it is not known any more where the flake originally came from. Yeah flakes have no provenance | 06:05:08 |
 blitz | Because the scheme comparison came up and there is the french connection in this room: https://christian.queinnec.org/WWW/LiSP.html <- this is an amazing book about interpreter design. but you need to be able to read scheme to enjoy | 10:24:33 |
| blitz | 
Download image.png | 10:25:04 |
| blitz | * | 10:30:04 |
 ShalokShalom | 
Download Bildschirmfoto_20260417_123253.png | 10:38:30 |
| ShalokShalom | nil reports this (in Kate) while Lix is actually fine with it. | 10:38:45 |
| ShalokShalom | * nls reports this (in Kate) while Lix is actually fine with it. | 10:38:55 |
| ShalokShalom | * nil reports this (in Kate) while Lix is actually fine with it. | 10:39:28 |
 ToxicFrog | I'm pretty sure that's a linter message, i.e. "this won't break, it's just bad form" | 10:39:34 |
| ShalokShalom | and whats the correct form? | 10:40:20 |
| ShalokShalom | I got it from a webpage 🙂 | 10:40:28 |
 Lily Foster | only putting with pkgs; if you use attributes from pkgs in the with context? nothing from pkgs is used in that with pkgs; context | 10:41:02 |
| ToxicFrog | Th with pkgs; isn't doing anything in that expression because you aren't using anything from inside pkgs | 10:41:04 |
| ShalokShalom | ah, ok thanks 🙂 | 10:41:27 |
