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.
