| 9 Aug 2023 |
JoelMcCracken | i noticed that these are done as separate... derivations? steps? not sure of the right term here.. in nix-straight; i'm not sure why it needs to be this way | 19:44:10 |
ckie (they/them) | JoelMcCracken: right so, the emacs shim runs in one go, currently collecting just the package names, and it doesn't have a network connection at this point because it's in a Nix build. the package meta is put into a json file, which is the output of this derivation. next up the nix evaluator parses this JSON, and prepares the next derivation using that, reading another derivation's result is called IFD | 19:49:25 |
ckie (they/them) | * JoelMcCracken: right so, the emacs shim runs in one go, currently collecting just the package names, and it doesn't have a network connection at this point because it's in a Nix build. the package meta is put into a json file, which is the output of this derivation. next up the nix evaluator parses this JSON, and prepares the next derivation using that: reading another derivation's result is called IFD | 19:49:32 |
ckie (they/them) | * JoelMcCracken: right so, the emacs shim runs in one go, currently collecting just the package names, and it doesn't have a network connection at this point because it's in a Nix build. the package meta is put into a json file, which is the output of this derivation. next up the nix evaluator parses this JSON, and prepares the next derivation using that: reading & Importing From a Derivation's result is called IFD | 19:49:51 |
JoelMcCracken | ahhhhhh | 19:50:16 |
ckie (they/them) | but the trick is we don't always get fully-qualified package paths, sometimes we just get a (package! blahblah-mode), and we have to resolve it | 19:50:38 |
JoelMcCracken | sure | 19:50:55 |
ckie (they/them) | so that's done here atm | 19:51:55 |
JoelMcCracken | this seems to be the key https://github.com/radian-software/straight.el/blob/master/straight.el#L3022 | 19:54:45 |
ckie (they/them) | i feel that comment on 3031 | 19:55:36 |
ckie (they/them) | so essentially we need to determine a good spot to splice Nix in | 19:56:38 |
ckie (they/them) | that ideally doesn't involve a large api surface area | 19:56:52 |
JoelMcCracken | yeah | 19:58:12 |
ckie (they/them) | so that's about where i timed out last time after running around the room trying to read elisp | 19:58:40 |
j4m3s | slighty related question, is it sufficient to lock doom's git version to lock package version or ? (I'm confused about the ~/.emacs.d/bin/doom upgrade | 19:59:10 |
ckie (they/them) | moooostly | 19:59:28 |
ckie (they/them) | all of doom's own packages should be pinned, but the user doesn't have to specify a pin | 19:59:50 |
ckie (they/them) | like I have all of these: | 20:00:09 |
ckie (they/them) |  Download image.png | 20:00:10 |
j4m3s | Yeah right, i was just confused by the fact that in the modules they're called w/o the pin | 20:00:41 |
j4m3s | But seems like the pin is global to the repo :) | 20:00:49 |
ckie (they/them) |  Download image.png | 20:01:36 |
ckie (they/them) | JoelMcCracken: so this is another thing to consider actually. we need to save straight's resolutions. or every package registry's, but that might not be as feasible | 20:02:42 |
ckie (they/them) | i'm tending more towards that doom2nix that saves all the source url/commit-ish/hash pins | 20:03:43 |
j4m3s | mb then, I remembered it being empty. Thanks for the correction ~ | 20:07:46 |
JoelMcCracken | what is doom2nix? | 21:15:16 |
JoelMcCracken | also,
we need to save straight's resolutions is this covered by e..g exporting them as json output?
| 21:16:07 |
JoelMcCracken | * also,
we need to save straight's resolutions
is this covered by e..g exporting them as json output?
| 21:16:16 |
ckie (they/them) | JoelMcCracken: it's a thing that doesn't exist. but it'd be a CLI that pokes the network and creates a nde-specific json lockfile for resolutions | 21:20:29 |
ckie (they/them) | the idea is we want to put as little as possible behind the hash-dependent part with the network access | 21:21:08 |