| 4 Apr 2026 |
 K900 | And building up an understanding of the code as you go | 22:01:50 |
| K900 | But in nixpkgs and especially NixOS a lot of things happen because of weird side effects and things later in the file can affect things earlier in the file in unexpected ways | 22:02:16 |
 webtier | Right, I was thinking more direction-agnostic and documenting in a sense. For sure the general use case is for top-to-bottom understanding, but I am simply thinking about the technology not the principle | 22:04:32 |
| webtier | So literal just in the sense of being able to parse files which more complex markdown comment format. | 22:05:39 |
| webtier | * | 22:05:47 |
| webtier | * | 22:06:28 |
| K900 | Well there's already some level of support for Markdown in comments for :doc in the repl | 22:07:10 |
| webtier | That's good. What I'm imagining is that realistically, in the future we'd hit the nail on the head if basically something like that could be properly interpreted while at the same time allowing some other optional community app to use this same comment data to built a type of settings application. So like, as you configure your OS you keep making a more sophisticated "Settings" app... | 22:14:21 |
| K900 | I don't think that's something to be solved with comments tbh | 22:14:55 |
| webtier | I'm just brainstorming, want to note | 22:14:57 |
| K900 | I think the way to do that would be to provide better ways to introspect NixOS configurations in general | 22:15:10 |
| webtier | Yes that is true | 22:15:17 |
| K900 | But also there's incredible complexity there | 22:15:30 |
| K900 | That is really really hard to abstract over | 22:15:36 |
 Blastboom Strice | I thinl I know someone doing that with guix | 22:15:55 |
| K900 | https://github.com/oddlama/nixos-config-tui is one attempt I've seen that actually tries to follow the dependency chains | 22:15:59 |
| Blastboom Strice | * I thinl I know someone doing all this on guix | 22:16:12 |
| K900 | And that requires a custom build of the Nix interpreter | 22:16:21 |
| Blastboom Strice | * I think I know someone doing all this on guix | 22:18:04 |
| webtier | And looking at the current interpreter too... well maybe as a uni project | 22:20:29 |
| 5 Apr 2026 |
|  ritiek changed their profile picture. | 01:17:48 |
|  Lotte (it/its)/Cinny (she/her) θΔ& changed their profile picture. | 16:57:09 |
| 6 Apr 2026 |
 kfiz | Anybody using harmonia v3.0.0 https://github.com/nix-community/harmonia/releases/tag/harmonia-v3.0.0 with lix? They seem to be dependent on versions of the nix-daemon protocol > = 1.37. What's the version Lix is using? | 09:54:04 |
 griff | Lix uses version 1.35: https://git.lix.systems/lix-project/lix/src/branch/main/lix/libstore/worker-protocol.hh#L19 | 10:56:27 |
| kfiz | Ah. Cool. Thanks. That is unfortunate for my plans with harmonia, though. | 11:47:22 |
| griff | Yeah. As the person who wrote the removed code it also makes me sad. What did you want to do with it? | 11:48:39 |
| kfiz | just wanted to switch away from nix-serve-ng as binary-cache hoping for something a little bit more performant and ideally with less dependencies. | 11:51:12 |
| Lotte (it/its)/Cinny (she/her) θΔ& changed their profile picture. | 13:47:25 |
| Lotte (it/its)/Cinny (she/her) θΔ& changed their profile picture. | 13:48:30 |
 drab | // This must remain 1.35 (Nix 2.18) forever in Lix, since the protocol has
// diverged in CppNix such that we cannot assign newer versions ourselves, the
// protocol is bad in design and implementation and Lix intends to replace it
// entirely.
not necessarily asking anyone to explain this to me, but if you happen to have a nice blog post somewhere discussing stuff around this topic, I'd love to read it. I'm assuming searching about the capn proto stuff is a reasonable proxy otherwise?
| 16:14:51 |
