51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# Internals/design notes
|
|
|
|
## Why [profiles](https://github.com/doomemacs/doomemacs/tree/master/profiles)?
|
|
|
|
Because the profile loader runs early enough we can set `doom-profile-data-dir`
|
|
(where the generated profile is stored and loaded from) outside `DOOMLOCALDIR`
|
|
relatively cleanly. Not using the "global" profile is a largely unintended side
|
|
effect, but the changes to other paths made seem largely reasonable so for now
|
|
I'm sticking with it.
|
|
|
|
After the profile loader, the next point we would get control is `doom-start.el`
|
|
loading `init.el` from `doom-user-dir`. We currently point `doom-user-dir` into
|
|
the store (see below): setting `doom-profile-data-dir` and `doom-profile-dir`
|
|
from there (by prepending to the user's `init.el`) would probably also work.
|
|
This seems a bit questionable because `doom-profile-dir` is set with `defconst`:
|
|
its const-ness is not enforced but I'd prefer not to take advantage of that. I
|
|
also have not checked if writing the profile would work out of the box with this
|
|
approach.
|
|
|
|
## Why put `doom-user-dir`/`DOOMDIR` in the Nix store?
|
|
|
|
Doom forces my hand. I would prefer for just `packages.el` and possibly
|
|
`init.el` to live in the store, but splitting out where those are loaded from
|
|
looks non-trivial.
|
|
|
|
Doom uses `doom-user-dir` as the path to a special module (`:user`).
|
|
|
|
At profile generation time, this is how `packages.el` gets loaded. We want our
|
|
generated `packages.el` to take effect, so we want the `:user` module's path to
|
|
be a store path when generating the profile.
|
|
|
|
Paths to all modules are embedded in the generated profile and used to
|
|
initialize `doom-modules` at runtime. Among other things, this controls where
|
|
the user's `config.el` is loaded from (it's loaded along with module `config.el`
|
|
files). So (without further hacks) the path to `packages.el` at build time and
|
|
`config.el` at runtime are the same.
|
|
|
|
(And even if that wasn't the case, functions like `doom/help-packages` load
|
|
`packages.el`, and I currently expect less overall confusion if that loads our
|
|
generated `packages.el`, not the original one. So I do think we want the `:user`
|
|
module loaded from the store.)
|
|
|
|
In several places, Doom assumes (at runtime) that `doom-user-dir` and the path
|
|
to the `:user` module are the same. This is mostly in functions like
|
|
`doom/help-packages` and `doom-module-from-path` that map paths back to modules.
|
|
|
|
Combine all that and I think consistently having `doom-user-dir` and the `:user`
|
|
module live in the Nix store is the least bad option.
|
|
|
|
This does break things that write to DOOMDIR at runtime. `custom-file` is an
|
|
obvious example, but there are probably a few more.
|