| 24 Nov 2025 |
 helle (just a stray cat girl) | yeah, that is a little weird, wonder if flake inputs use that path as well, should poke thubrecht on that as they changed that up last it seems? | 20:10:42 |
 thubrecht | Yes, the flakes machinery goes through libfetchers | 20:12:36 |
| helle (just a stray cat girl) | yeah, but also specifically that code path I guess that uses the same definition as fetchTarball? | 20:13:39 |
| helle (just a stray cat girl) | because that seems messy, oof | 20:13:54 |
 goldstein | yeah, fetching files and tarballs is explicitly the same interface I think | 20:14:07 |
| goldstein | don’t think either of them should need rev though | 20:14:16 |
| helle (just a stray cat girl) | yeah, I mean it's fine to share some amount of code path, but having that leak into fetchTarball is uh, very silly design | 20:17:44 |
| helle (just a stray cat girl) | anyway, I do need to go over this when redoing the docs around there, I bet there is a bunch more of "is this intentional?" behaviour in the code | 20:20:08 |
| helle (just a stray cat girl) | this is also going to lead to more test suite writing huh | 20:31:23 |
 raitobezarius | quick reply, we plan to dissolve flake refs into general URIs | 23:46:13 |
| raitobezarius | flake refs gets to continue to exist as URIs + a new scheme registration (flake:) | 23:46:28 |
| 25 Nov 2025 |
|  wizzy changed their profile picture. | 00:26:34 |
|  Garrett joined the room. | 04:06:10 |
 Atemu | btw. on the topic of flakes: has anyone ever dabbled in re-implementing the flake.nix interface in Nix expressions so that you can eval flakes via plain old regular impure direct eval without all the special bullcrap Nix does to make pure eval work? | 15:17:39 |
 piegames | Do we have a command to easily check remote builder connections? If not, can I request that as a feature? | 15:19:23 |
| piegames | * Do we have a command to easily check (and debug) remote builder connections? If not, can I request that as a feature? | 15:19:34 |
 Sofie 🏳️⚧️ (she/her) | isn't compat basically this but kinda like reversed | 15:25:59 |
| Atemu | flake-compat is quite close to what I want but IIRC it still evals the current project "as a flake" and comes with all the stupidity in doing that like depending on my VCS state or copying shit to the nix store unnecessarily | 15:28:00 |
| goldstein | I’m doing this basically right now lol | 15:28:32 |
| Atemu | but I'll have to take another look | 15:28:33 |
| goldstein | I have a program that takes in flakes inputs format, solves them into a flat dependency structure and adds to npins sources.json | 15:28:58 |
| goldstein | and then generates appropriate dependency injections so flakes don’t know they aren’t actually being used as flakes | 15:29:16 |
| Atemu | Oooh; do you have that published somewhere? | 15:29:42 |
| goldstein | not yet, I need to add a bit of polish (like CLI parsing), but I expect to publish it this week | 15:30:13 |
| goldstein | also I need to change name generation scheme, because doing npins update unflake_<base64> isn’t really nice lol | 15:31:09 |
| goldstein | 
Download clipboard.png | 15:31:12 |
| Atemu | I want it to be direct and acually work with the flake.nix "standard" such that I can throw it at some local flake project and eval it without flake tooling BS but I'd probably need to solve many of the same issues as you likely have | 15:31:47 |
| Sofie 🏳️⚧️ (she/her) | well, the issue is that there's really no "standard" | 15:32:47 |
| Atemu | Yeah I know, hence the quotes.. | 15:33:06 |
| Sofie 🏳️⚧️ (she/her) | you'd have to solve that but if we are doing that, why not just fix the whole standard | 15:33:07 |
