tree-sitter-langs has special handling in nixpkgs, and our pinning
breaks assumptions it makes about version numbers. This causes
tree-sitter-langs to attempt to download and write a grammar bundle both
at build time (where the network request fails) and runtime (where it
causes an error on visiting a file supposed to be handled by
tree-sitter).
Fix up our derivation so it loads the Nix-provided grammar bundle.
This only partially fixes the problem: at least for Go, the
tree-sitter-langs package now loads, but visiting a Go file causes
`tsc-lang-abi-too-new 14 (13 . 13)`.
The included test fails without the fix in this commit, but does not
trigger this new failure.
Commit this partial fix because after
nixos/nixpkgs@2421239d66 the build-time
failure became an error. This should fix CI and leave us no worse off
than before.
Downside: needs to be disabled at the Emacs (not emacsWithPackages)
level, so this builds Emacs.
Upside: still seems to be faster, at least in limited local testing. And
if CI caches Emacs this should be substantially faster there.
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.
I manually skimmed all packages.el files for dependencies behind a mix
of positive and negative checks (requiring at least one module flag
enabled and at least one module or flag disabled). I found several
packages I was not building, but no issues building them.
I don't intend to keep this up-to-date, but might as well check it in.
Using an attrset instead of a list allows using Nix's shorthand for
nested attrsets, which is much more readable for the simple cases toInit
is used for.
Move `doomdirs/example/` to just `doomdir/`, and rename the package
using it from `doom-example` to `doom-emacs`.
I do not expect to need multiple doomdirs checked in again, and I can
unclutter the packages provided by the flake a bit now that most of them
are checks.
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.
