This is only a starting point. For this to be more useful, we need to
build for multiple Emacsen. But I want to get a baseline for the size of
the closure first (as well as confirming it works in the first place).
CI fails to fetch it:
```
error: Server does not allow request for unadvertised object 87d0d1fb0566a80229029d0d8d7c863138d70aae
warning: could not update mtime for file '/home/runner/.cache/nix/gitv3/0gjpwip102kwcvz961gsiva3lqmmr6266s5wzs8kq0ybm68gwpx9/refs/heads/master': No such file or directory
error:
… while checking flake output 'checks'
at /nix/store/fwrwzxjvvpx1l27h8j5f9gffzwn2vdik-source/flake.nix:54:7:
53| in {
54| checks = perSystemPackages (pkgs:
| ^
55| let
… while checking the derivation 'checks.x86_64-linux.full'
at /nix/store/fwrwzxjvvpx1l27h8j5f9gffzwn2vdik-source/flake.nix:83:11:
82| })).emacsWithDoom;
83| full = mkDoom {
| ^
84| full = true;
(stack trace truncated; use '--show-trace' to show the full trace)
error: Cannot find Git revision '87d0d1fb0566a80229029d0d8d7c863138d70aae' in ref 'refs/heads/master' of repository 'https://git.savannah.gnu.org/git/emms.git'! Please make sure that the rev exists on the ref you've specified or add allRefs = true; to fetchGit.
```
Try to follow the suggestions from the error message, as I do see the
commit in https://git.savannah.gnu.org/cgit/emms.git/.
I'm not sure why this is only failing now...
...with `--override-flake nixpkgs github:NixOS/nixpkgs/nixpkgs-unstable`
(bypass my local registry) to write a flake.lock that should pass
flake-checker.
I knew this might cause problems at some point, but it came to a head
sooner than expected: it triggered
https://github.com/magit/magit/issues/5131 (magit is pinned but
magit-section was not, and those packages expect to be kept in sync).
The fix is messier than I'd like but at least fixes magit.
Doom hooks into flycheck's emacs-lisp checker to load itself. This does
not involve its profile loader, so this bypasses our profile dir
customization.
Hook into this hook to add that customization back.
`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.
