| 7 Sep 2023 |
 mei 🌒& | like nix-shell -p but doom calls it from inside its package manager | 13:55:44 |
| mei 🌒& | see: [RFC 0040] "Ret-cont" recursive Nix | 13:57:09 |
| mei 🌒& | vaguely. not sure if that's precisely the right one | 13:57:45 |
| mei 🌒& | yeah this isn't the right one | 14:00:01 |
| mei 🌒& | I think I was thinking of [RFC 0092] Computed derivations but it's been >a year, need to reread | 14:02:38 |
 JoelMcCracken | yeah i don't know | 14:03:33 |
| JoelMcCracken | i imagine it would work like:
- a user picks a package to install from a list
- nix installs it
- emacs loads it within the running process
| 14:05:37 |
| mei 🌒& | mhm, it's essentially tearing out the parts of straight&emacs that do network I/O into their own emacs, running inside a nix build | 14:06:42 |
| mei 🌒& | which works happily for the top-level imperative emacs usecase (editing your config before rebuilding) but you want to have all of these prefetched in the build process once you're ready to deploy it to your 'prod' machine | 14:07:22 |
| mei 🌒& | recursive nix isn't actually a hard dependency-- we can crudely and inefficiently emulate it, but it would make this much more streamlined since it would run through approximately the same codepath in both imperative/Nix sandbox | 14:08:44 |
| mei 🌒& | * recursive nix isn't actually a hard dependency-- we can crudely and inefficiently emulate it, but it would make this much more streamlined since it would run through approximately the same codepath in both the imperative/Nix sandbox usecases | 14:08:49 |
