| 7 Sep 2023 |
 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 |
