Use Nix flakes

[akirak]

Assumption: Power users of Nix would want to use Nix flakes locally, but it is unavailable on GitHub Actions. We will provide instructions for Emacs package developers without Nix proficiency, but it's better for them to learn it.

• [ ] Add flake.nix
• [ ] Use Nix flakes to track dependencies even inside elinter itself
• [ ] Remove the dependency on Niv and sources.json
• [ ] Make CI work even in an environment where the flake command is unavailable, e.g. GitHub Actions

[akirak]

Note that the Nix flakes system is an experimental feature of Nix, so you cannot expect it to be available on every machine (#17).

[terlar]

Using cachix/install-nix-action you can also get flake support via GitHub Actions: https://github.com/cachix/install-nix-action#usage-with-flakes

Also you can create a compatibility file via https://github.com/edolstra/flake-compat to have it still work on versions without flake support.

E.g. add a default.nix with the contents:

(import (fetchTarball {
  url =
    "https://github.com/edolstra/flake-compat/archive/c75e76f80c57784a6734356315b306140646ee84.tar.gz";
  sha256 = "071aal00zp2m9knnhddgr2wqzlx6i6qa1263lv1y7bdn2w20h10h";
}) { src = ./.; }).defaultNix

this will expose an attrset with all the outputs from the flake.

[akirak]

@terlar Thanks for your comment.

Using cachix/install-nix-action you can also get flake support via GitHub Actions

I didn't know of that, but it would make the problem easier. It looks like a relatively new feature, so I guess I overlooked it. Thank you for the information.

Nonetheless, flakes are still limited to the unstable channel, and some people may have trouble switching to it (as I did at first), so use of nix-compat may be necessary. I am gradually adopting flakes.

It is possible to use a flake-enabled version of Nix locally like in nixflk, but I don't know if it is an encouraged practice.

[terlar]

I think you can still use whatever version of nixpkgs (stable/unstable). Only the nix command itself needs to be one with nix flake support. I believe that is what the GitHub action does, just installs a specific version of the nix commands.

If you use flakes you can use the stable nixpkgs via the inputs or if you want to use nix-env or things using the NIX_PATH (<nixpkgs>) you can also provide a stable channel there.

Something like this should work:

 - uses: cachix/install-nix-action@v12
      with:
        install_url: https://github.com/numtide/nix-flakes-installer/releases/download/nix-2.4pre20201221_9fab14a/install
        extra_nix_config: |
          experimental-features = nix-command flakes
        nix_path: nixpkgs=channel:nixos-20.09

If 20.09 is available as a channel, I see that the channels repo is deprecated, so not sure where/if they are still tracked.

[akirak]

@terlar I will have a look at it.

This will be a major rewrite, and I won't finish working on it soon. I am exploring ideas for my open items during the holiday. Your information will be helpful for this project. Thanks.

[akirak]

nix-emacs-ci, which is a collection of patched Emacs builds for CI, fails to build in flakes. I am working on the issue in this PR: https://github.com/purcell/nix-emacs-ci/pull/34

[terlar]

I was trying to use this project as part of a nix flake recently and ran into the issue that the nix/lib.nix refers to <nixpkgs> explicitly even though I imported the the default.nix with a specific pkgs. I checked the branch rewrite/flake but seems to have the same issue. Did you have time to look into this or need assistance? I've had my eyes on the project for a while, but this is first time I am writing an Emacs package for a while and was planning to use it.

[akirak]

Hi @terlar,

I'm currently thinking of dropping the Flake support from the wishlist of this v4 branch and postpone them to the next major rewrite, which should be called v5.

Due to the internals, it looks hard for me to rewrite it to allow integration with flakes. Another rationale for this plan is that use of flakes may reduce the amount of code to a greater extent. If a project contains flake.nix, then the user is supposed to use nix flake check to run checks, I think. I tried to provide a convenient CLI in v4, but there may be a different form of API if flake.nix is assumed.

Nonetheless, the current v4 has an advantage of requiring only recipe files in the project source repository. The user doesn't have to create a flake.nix, which is good for simple projects.

Thus I plan on dropping the remaining features from the wishlist of v4, turning the status into beta, and continuing maintenance. I have been using v4 in my several existing projects, and I am not thinking of switching to other solutions like makem.sh personally. I have to admit that v4 provides the least advantage of depending on Nix, but it would be possible to reuse part of its code if I were to work on the next major version.

The major reason for using Nix in elisp CI would be to include non-elisp dependencies in a distribution-agnostic way, as needed in projects like emacs-webkit. However, what would be the standardized way to deploy such packages? I think we'll have to think more about integration with the Emacs infrastructure for Nixpkgs. It could even possibly lead to a new Nix-based elisp package manager and an Emacs distribution, which sounds exciting, but I have to work on more practical stuffs for now, to solve my own problems. I'm sorry, but this is the current status.

[akirak]

I plan on migration to nomake.