Test if packages are loadable with the wrapper

[akirak]

The test which I added three years ago only builds emacsWithPackages wrapper with a few packages. Since then, there have been several changes made in the upstream nixpkgs repository. Unfortunately, the wrapper no longer correctly starts if it is combined with an Emacs derivation from nix-emacs-ci, which was not detected by the test.

This PR extends the test to check if the wrapper correctly starts and loads packages.

[akirak]

@purcell site-start.el is required by the wrapper, and it is supposed to be created here. Without the file, Emacs built using emacs.pkgs.withPackages fails to start, but creating an empty file seems to fix the startup error. What do you think?

[purcell]

Yeah, upstream in nixpkgs the site-start.el looks like this: https://github.com/NixOS/nixpkgs/blob/342d73c9355613f36304a19d272d75ca86502d14/pkgs/applications/editors/emacs/site-start.el, but I'm not worried about missing any of that content, so an empty site-start.el sounds viable.

[akirak]

Rebased onto master to trigger rebuilds with the latest nixpkgs.

[purcell]

Is the extra treeSitter flag var necessary? I thought the previous code was doing the right thing, ie. emacs versions that supported tree-sitter would automatically detect and enable it.

[akirak]

Is the extra treeSitter flag var necessary?

It is only intended to enable the tree-sitter integration of the wrapper. Alternatively, the user of nix-emacs-ci could set the attribute by overriding the attribute as follows (overriding passthru doesn't trigger rebuilds, so the binary cache would be still effective):

 emacs.overrideAttrs (_: {
    passthru.treeSitter = true;
  })

To use the feature in a project like #168, either this library or the user must pay the cost. Although nix-emacs-ci doesn't necessarily have to work around every possible feature of the wrapper, the empty site-start.el is already part of this PR, so one possible way would be to sensibly support common use cases through this library.

It's possible to handle the problem on the user side, so I will revert the commit if you don't prefer the additional complexity.

[akirak]

I have removed the commit to set treeSitter from this branch and made it a separate PR (#172).

[purcell]

Great, thanks!

[purcell]

It is only intended to enable the tree-sitter integration of the wrapper.

Oh — that makes sense.