| 7 Sep 2023 |
 JoelMcCracken | yeah | 14:08:55 |
| JoelMcCracken | well it depends, what you mean specifically by recursive nix i guess | 14:09:27 |
 ckie (they/them) | what do you mean by "nix installs it" though? installs it where. i'd think nix gives some store paths or an elisp payload and emacs evals it into the running process | 14:09:42 |
| ckie (they/them) | like this at runtime but also for the elisp path variable | 14:10:15 |
| ckie (they/them) | * like this but at runtime but also for the elisp path variable | 14:10:24 |
| JoelMcCracken | TBD, but my thought was:
- somehow emacs/nix figures out what the speicifc package should be, versions etc.
- nix then builds this package, maybe via a standard "emacsWithPackages" or something like that; somehow nix would know how to call its own build process
| 14:11:05 |
| JoelMcCracken |
- once this is all built, it can just be added to
load-path and then loaded
| 14:11:33 |
| ckie (they/them) | yes! | 14:12:19 |
| JoelMcCracken | but yeahwe should be able to share a lot of all of this code | 14:12:20 |
| JoelMcCracken | it would be v nice if elpaca had some design input from us | 14:13:08 |
| JoelMcCracken | so that we could just interface with it instead of having to hack it | 14:13:25 |
| ckie (they/them) | my thought was, main Emacs goes "I want this straight recipe (package! blabla :pin "whatever")" and system()s a nix-build --argstr recipe "…", then there's another little Emacs spawned inside the Nix sandbox which is a FOD and has network access, so it goes on fetching that package and then brings the output back through Nix to the main Emacs | 14:14:07 |
| JoelMcCracken | yep | 14:14:25 |
| JoelMcCracken | tho, FOD? | 14:14:42 |
| ckie (they/them) | fixed-output derivation, a sorta precondition to getting network access in the nix sandbox | 14:14:56 |
| JoelMcCracken | ic | 14:15:03 |
| ckie (they/them) | you know, the hash option you set when you use fetchFromSomething | 14:15:06 |
| JoelMcCracken | k | 14:15:12 |
| ckie (they/them) | * you know, the hash attr you set when you use fetchFromSomething | 14:15:14 |
| ckie (they/them) | i like this (: | 14:15:42 |
| JoelMcCracken | yea it sounds cool | 14:15:52 |
| JoelMcCracken | tho first step would be to get the regular build step working so | 14:16:11 |
| ckie (they/them) | i think we should work on extracting the "install recipe with straight and get a package" bit out from doom's big mess | 14:25:16 |
| ckie (they/them) | ref for FOD btw: https://nixos.org/manual/nix/unstable/language/advanced-attributes.html?highlight=outputHash#adv-attr-outputHash | 14:27:27 |
| JoelMcCracken | ok, learned something new | 14:29:53 |
| JoelMcCracken | i guess message output isn't shown for some reason from within straight-use-package advice | 14:30:25 |
| ckie (they/them) | don't we suppress that for some reason? | 14:30:45 |
| JoelMcCracken | but doom's own print! is working | 14:30:47 |
| JoelMcCracken | "we?" | 14:30:58 |
| JoelMcCracken | like nix-doom-emacs suppresses it somehow? | 14:31:05 |
