| 7 Sep 2023 |
 JoelMcCracken | *
'prod' workstation
yeah i need to start doing this
| 13:44:37 |
 ckie (they/them) | the thing is currently NDE nearly forces you to wait for the whole damn rebuild cycle | 13:45:02 |
| JoelMcCracken | for what i had been doing before as I've been trying to make all these packages work, it involved basically re-running home manager over and over | 13:45:44 |
| ckie (they/them) | doom doesn't encourage this and nix does but there's a big Mess to resolve when we make them touch | 13:45:49 |
| JoelMcCracken | yeah | 13:45:57 |
| ckie (they/them) | In reply to @JoelMcCracken:matrix.org
for what i had been doing before as I've been trying to make all these packages work, it involved basically re-running home manager over and over yeah for me this takes a while because my evals are quite big | 13:48:48 |
| ckie (they/them) | so i usually eval at point in my org config | 13:49:10 |
| JoelMcCracken | one thing about working on nde directly now is that I can run the check thing to see how its working | 13:49:22 |
| ckie (they/them) | a friend who wasn't on Nix yet at the time could just M-x package-install and that was like. wow | 13:51:06 |
| ckie (they/them) | like i went "oh you should get $X" and they just ran a few things in emacs and got the package | 13:51:23 |
| ckie (they/them) | even with vanilla doom that'd be what, a doom sync and restart | 13:51:53 |
| JoelMcCracken | weljl you can i think run M-x doom sync | 13:53:13 |
| ckie (they/them) | there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines | 13:53:20 |
| ckie (they/them) | * there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines? | 13:53:23 |
| JoelMcCracken | sure | 13:54:02 |
| ckie (they/them) | * there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines? | 13:54:29 |
| ckie (they/them) | if we had a imperative2nix that'd be really neat | 13:54:50 |
| JoelMcCracken | for sure | 13:54:58 |
| JoelMcCracken | like somehow a way to generate an overlay from the current running doom | 13:55:22 |
| ckie (they/them) | what's actually missing for that? what if we put a Nix in the doom | 13:55:28 |
| ckie (they/them) | yea | 13:55:29 |
| ckie (they/them) | like nix-shell -p but doom calls it from inside its package manager | 13:55:44 |
| ckie (they/them) | see: [RFC 0040] "Ret-cont" recursive Nix | 13:57:09 |
| ckie (they/them) | vaguely. not sure if that's precisely the right one | 13:57:45 |
| ckie (they/them) | yeah this isn't the right one | 14:00:01 |
| ckie (they/them) | 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 |
| ckie (they/them) | 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 |
| ckie (they/them) | 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 |
