`doom-start` locates the profile init file relative to
`doom-profile-dir` when running interactively, which we customize (either
directly or by setting `doom-profile-data-dir`). But when running
noninteractively, it uses `doom-profile-init-file`, which always loads
relative to `doom-data-dir`.
We cannot point `doom-data-dir` into the store, so this breaks us.
Work around it by advicing `doom-profile-data-dir` to locate the init
file relative to `doom-profile-dir` too. Try to make this more safe by
erroring out if called on a non-default profile.
All of this feels questionable, but I really want `doom doctor` to
work...
`straight--load-build-cache` is not autoloaded, so we fail if it has not
been loaded yet. Apparently it usually is when we hit this override
interactively, but Doom CLI can call our override early enough we need
this.
It does not use them (although doomscripts themselves might).
Not forcing them seems more convenient for users (this should let me
test build-profile-loader) and helps me make the profile loader
optional.
Both approaches are about equivalent, but since I'm trying to make the
profile loader optional and there's no way I can make the wrapper
optional, let's move this around...
Instead of passing the path down from the profile loader to init.el,
just substitute the path into init.el.
This requires moving DOOMDIR generation into the same derivation as
profile build to avoid a circular dependency.
This unsets DOOMPROFILE from inside the profile loader, which should
result in Doom behaving as if we were not using profiles at all.
I'm marking this experimental in part because it feels like a hack, and
in part because this is not sufficient to fix `doom doctor`.
Buliding an empty autoloads file is harmless. Removing it would only
have been useful if I was able to skip straight.el initialization
entirely: now that I'm storing its build cache it no longer helps.
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).
