I have moved back to using nix for this project. There has been a lot of churn, however I have learned quite a bit.
- snap did not work out. There were reasons, one of which I think was that it was hard to set up/use/dealwith, but also because
- IIRC, I realized that if I just used an updated ubuntu/debian, I would be able to acquire an emacs that was new enough much more easily, so this whole thing wasn’t needed. but i had learned that snaps have weird limitations (shch as not being able to access files in /tmp)
- I started experimenting and having success with flakes, and added nix back in incrementally. This mostly worked, and once I got to the point where I now had the nix-doom-emacs package.
So I guess that although I had a good number of frustrations with nix, my core hunch (that it will be incredibly useful and powerful once I’m nearly expert at it, and that )
how should I organize the org files? one org file per source file seems wrong. But it also doesn’t seem like I can “include” references to other org files, so there isn’t a great way to DRY-up a muti-file setup.
Perhaps I am thinking about it incorrectly; there are other ways for thilngs to refer to each other, i.e. normal PL modules. The only time this really matters if if I can’t do that. I can adopt the GHC note strategy to make references between sections.
right now i think:
- exposition.org
- workstation.org
- bootstrap.org
thought: keep it simple. Use as few files as possible, but if it really makes sense to combine things, do it issue: there are very similar needs when bootstrapping and checking. example: should bootstrap check if these are installed before setting up?
can i make bootstrap “safe”/idempotent to run over and over?
- decided to make a history and decisions log
- making an exposition file, which may end up being a book/guide I guess?