Shallow clones are the default in Nix 2.23, but the Git server for
notmuch does not seem to allow shallow clones of specific revisions.
Disable them, which should make no difference for Nix < 2.23.
This is mostly to (hopefully) unblock CI. If this fixes it, I should
investigate if it is possible for Nix to fall back to a full clone in
this scenario.
We were only pulling in autoloads files for packages installed via
packages.el. This was not that noticeable because all pinned packages
without custom derivations end up installed that way, but it does affect
extra packages (including the one pointed out in #11).
Try to fix this by including autoloads files in the top-level site-lisp
directory from emacsWithPackages.
This otherwise gets garbage-collected and then has to be regenerated on
next flake evaluation. It may not be that slow to regenerate, but it's
also tiny enough we may as well keep it alive.
The amount of shell in non-shell files was making me uncomfortable,
and two of these previously contained awkward `''$` escapes.
Apart from forcing one more step to run locally, this is just moving
code around.
Mostly removes string interpolation from build commands, by mechanically
pushing inputs up to derivation attributes.
Should be equivalent, but makes the derivations more readable (and
potentially allows splitting build commands out to separate files).
Detect module flags by walking package.el files.
This still does not build all dependencies, because some are enabled
only if some flag or other module is disabled. But this should be close.
...not yet with all flags, but that's the next step.
This surfaced several problems not caught by the existing "full" build,
because that did not enable dependencies conditionally enabled if a
second module is enabled.
There are a small number of dependencies only enabled if a second module
is *not* enabled, which I intend to add some manual tests for.
They do not have src set, so if we pull them in without having a pin
they fail to build.
Noticed with org, so add a test for that. Probably not the only one
affected, though.
Fixes#4
This seems to be much more space-efficient: ~/.cache/nix/tarball-cache
is about 700MiB uncompressed, under 300MiB as tzst (using tar's
defaults, CI uses zstdmt but I assume will be in the same ballpark). The
gitv3 cache is multiple GiB.
CI will still build doom-example using fetchGit. I intend to shrink the
number of modules enabled in the example to keep gitv3 cache size under
control.
This may turn out to be too much (but it does at least build).
Motivation: CI's git checkouts consume an unmanageably large amount of
cache (over 3 GiB per snapshot out of 10 GiB quota), and must be cached
for acceptable build speeds. Dropping submodules should help somewhat
directly, but I want to try switching most of CI over to fetchTree's
github fetcher, which won't include submodules. This change should help
maintain parity.
I'm also seeing a submodule fetch failure in CI (for stan-mode) that I
may not need to debug if the package functions without that submodule.
After upgrading my local Nix from 2.18 to 2.22, evaluating
Unstraightened became very slow. I think this is a bug in
Nix (https://github.com/NixOS/nix/issues/10773), and it may explain
the slowness I've been seeing in CI.
Attempt to work around this by unconditionally passing `ref` to
`fetchGit`. This seems like it should not do anything, since we also
pass a `rev` and set `allRefs = true`, but it does work around the
caching issue (mostly... it looks like submodules still hit it).
Tested locally in both Nix 2.18 and Nix 2.22. I did see some odd
warnings with 2.18 (`warning: refname
'e4031935803c66eca2f076dce72b0a6a770d026c' is ambiguous`), but only for
one refname and they did not recur. Ignore that for now.
Having CI confirm allRefs false is still safe would require a network
hit for each repo, which is already problematic. But
https://github.com/NixOS/nix/issues/7120 means we'd need to drop CI's
cached content, not just its cached refs: given how much we're fetching
that seems too much.
Fetch all refs unconditionally, assuming we're typically re-fetching the
same fixed rev repeatedly, which should be cached.
The doom profile is a non-negligible fraction of the cachix binary size,
that will only get worse (any dependency change will trigger a rebuild),
and caching them is essentially useless.
Expose emacsWithPackages so we can push just that. Skip
emacsWithPackages itself and push just the -deps derivation while we're
at it: caching either emacsWithPackages or -deps is similarly useless,
but they are a bit smaller.
When I say "non-negligible", it's about 1 MiB per "full" profile: much
larger than most individual libraries but not actually large. So this is
really a micro-optimization.
Triggered by ob-ammonite (used by scala, in emacsattic) depending on
ammonite-term-repl (also in emacsattic). `eself` only contains
emacs-overlay and doomPackageSet.
All of this needs refactoring, but an explicit recursive call fixes the
immediate problem.
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...
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.
