Trying to start doom-example after enabling `scheme +guile` confirmed we
have at least one package (geiser-guile) that requires its dependency's
autoloads are loaded before its own are.
Fix it by assuming `package-activated-list` is in reverse order of
activation. That behavior is (as far as I could find) not documented,
but sufficiently obvious it seems safe enough to rely on it.
Having this empty only really makes sense for minimal/full test builds.
Also, /var/empty was not doing what it looks like (it's not accessible
from inside the build sandbox). Use nixpkgs's emptyDirectory instead.
Writing profiles.el was borderline unreadable.
`doom-profiles-autodetect` was effectively just reading in the entire
file: accepting the paths we want in the profile as individual args and
putting them together on the Emacs side is easy enough.
Accidentally fixes a bug: `user-emacs-directory` should end in a
directory separator. We now get the right value for free by using the
path we're running Doom CLI out of.
doom-profile-data-dir is for the current profile, naming it
"profiles" (plural) made no sense.
Also move the loader into its own subdir so it's more obvious what the
two init.29.elc files are.
I was hoping to avoid this but it does not seem practical: I'm pretty
sure I need the user module in the store to override its packages.el,
and Doom does not separate the user module and doom-user-dir.
This seems like a relatively sane way of loading our profile from the
Nix store. The alternatives I see are patching Doom (which I'm trying to
avoid) or setting DOOMLOCALDIR. If we set DOOMLOCALDIR, Doom sets enough
variables based on it it would be a pain to clean them up after we gain
control.
Using the profile loader lets us set doom-profile-data-dir early, which
currently only contains the profile and env file.
I haven't fully confirmed this is sufficient to avoid rebuilds, but I
did confirm for a few packages the version no longer appears in that
package's derivation (which should be sufficient).
We were already setting `commit` to `p.pin` unconditionally, so the
requirement is not new. Add an assert because this can be triggered from
a user packages.el.
We were installing bootstrap.el, install.el and indent.el. The former
two would have undesirable side effects if loaded, the latter shadows a
built-in library.
