| 24 Nov 2025 |
 helle (just a stray cat girl) | the untangling of the fetchers (cleaning fetchurl, etc) is going to be a whole extra set of questions | 20:00:18 |
| helle (just a stray cat girl) | sigh | 20:00:46 |
| helle (just a stray cat girl) | for chaos reasons, fetchurl, fetchTarball and fetchGit are implemented as:
https://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/primops/fetchTree.cc#L329
not 100% sure how path and file are off the top of my head, but probably similarly silly | 20:05:39 |
| helle (just a stray cat girl) | so the fact that some abstraction is leaky.... | 20:06:23 |
 goldstein | the part that’s confusing to me is that they explicitly list allowed attrs, including rev and revCount
https://git.lix.systems/lix-project/lix/src/commit/b966d2e53bd6f5f03ae86b60b12d7489cf91f1a6/lix/libfetchers/tarball.cc#L234 | 20:07:19 |
| 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 |
