| 7 Sep 2023 |
ckie (they/them; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | like this at runtime but also for the elisp path variable | 14:10:15 |
ckie (they/them; limited keyboard usage, voice preferred) | * 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; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | you know, the hash option you set when you use fetchFromSomething | 14:15:06 |
JoelMcCracken | k | 14:15:12 |
ckie (they/them; limited keyboard usage, voice preferred) | * you know, the hash attr you set when you use fetchFromSomething | 14:15:14 |
ckie (they/them; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | 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; limited keyboard usage, voice preferred) | 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 |
ckie (they/them; limited keyboard usage, voice preferred) | yeah. or maybe doom, i don't remember exactly | 14:31:21 |
ckie (they/them; limited keyboard usage, voice preferred) | * yeah. or maybe doom, i don't remember exactly where | 14:31:23 |