Although a completely empty DOOMDIR seems to work (at least for build
purposes), I doubt Doom actually supports this. And it requires some
extra checks on our side as well.
Just check in a trivial DOOMDIR and use that instead.
Doom's package help uses `git grep` to search for files in Doom
configuring a package, which does not work for us because our Doom
install does not live in a Git checkout. Unfortunately this breaks
package help completely because of error handling problems.
Add advice to use ripgrep instead, which fixes package help.
I don't like doing this: I've sent the same fix upstream, if it's not
accepted there I may just make Doom in the Nix store be a Git checkout.
Add an (empty) straight.el build cache to the generated profile, and
load it when Doom calls `doom-initialize-core-packages` (which normally
does so by side effect).
Unfortunately requires adding to pre-init: Doom overrides
`straight-base-dir`, and we need to override that override.
Partially fixes package help.
Exposing it as a package was (at least according to `nix flake check`)
incorrect.
This means we now use the user's nixpkgs's `pkgs.callPackage` instead of
our own, but I think that's ok.
I somehow managed to lowercase build-profile and build-profile-loader
when I split them out of cli2.el. Undo this.
The only load-bearing capitalization was DOOMDIR in the profile loader.
Everything else was comments and docstrings.
Our cli.el ended up in the profile used at runtime. Although we could
have fixed overwriting a user's cli.el by appending to it, that still
would have leaked our build commands into the build.
This approach should be equivalent and reduces our profile modifications
to replacing packages.el (which is kind of the point) and prepending to
init.el (unfortunate, but seemingly necessary).
Removes the need to build a stage1 DOOMDIR, we can just use the user's
DOOMDIR directly.
The same approach should work for the next stage, removing the need to
leave our cli.el in the final DOOMDIR.
Although not used much with doomProfile set, the default (.local in the
Doom source tree) will not work.
Currently straight-base-dir ends up relative to this, although that may
change.
...by moving the existing hack from the CLI to init.el.
It's not really necessary to do this as early as init.el, but I'm coming
around to using init.el modifications as an alternative to using Doom's
profile loader. So we might as well do this in the same place.
This is not sufficient to make doom/help-packages work, but gets us one
step closer...
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.
