nix improvements: auto-advancing, caching, and completions

[colemickens]

Hi,

I noticed that some cool Rust projects are adding flakes and I'm hoping we can get feature parity across them, and serve as a template for others. The current nix support is missing:

• auto-advancing of flake inputs (aka eventually you'll be building against old system packages potentially)
• caching of binary outputs
• installation of shell completion files (zellij's recently added support does this) (at least, I don't see this in the flake, and I don't seem to have it active)

Somewhat separately...

I'm pondering a community provided build/cache service. Flakes would make this really easy, and the community provided service could even basically serve as a CI offload -- imagine that helix only runs CI every day, but nix-community runs it every hour. Unless you get really unfortunate, and if you trusted the community's cache, then it would mean that y'all nix builds would basically become no-ops.

[the-mikedavis]

The caching part might be covered by #1717 - is cachix along the lines of what you were thinking? Also, the build/cache service sounds similar to hydra, no?

[colemickens]

Yes, but I think on that point specifically my ideation is growing beyond "just another cachix" repo. There are implications to having to list+trust numerous caches - every cache can provide every store path, thus every cache can poison any path, and similarly every cache can need to be queried for every path (and there are potentially some client implementation details here that come into play).

I think I'm going to run with the idea of an externally-driven cache, just because I get the gut instinct from the interest in nixpkgs-wayland that there are enough Nix users wanting to be on the cutting edge that there would be some use. I can share details about that here, but again, no reason for that to block just a simple push to a helix cachix repo in the build job. (which can be setup very quickly with the Cachix GitHub Action)

For the sake of issue sanity, I'm fine with changing the scope of this issue to track just:

• auto-advancing flake inputs
• fleshing out the rest of the package derivation for completions
  and leaving helix-specific caching to Nix binary cache for flake #1717. If I get anything useful done with an external cache I'll share a note on Nix binary cache for flake #1717.

[the-mikedavis]

Zellij's flake has some nice goodies: here it sets up the completions and installs the logo, desktop items, etc. plus a man page. The completions themselves are setup by Clap. Helix uses a custom arg parser though so this would probably take some manual work to add completions to Helix.

[colemickens]

cc: @the-mikedavis This is something else I was thinking about https://github.com/DeterminateSystems/update-flake-lock/ though in my nix repos I stll do it by hand right now and just have it auto-merge it after rebuid/testing rather than sending a PR.

[the-mikedavis]

completions: #2022

[mtoohey31]

It would be nice if we could cache flake outputs for platforms other than just x86_64-linux, it might be difficult inside a GitHub action though...

Something like https://github.com/docker/setup-qemu-action might make this possible. I haven't done any testing, but I wonder whether we could get things working just by running that action, then adding the platforms to the container's nix config under extra-platforms. If so, we could run nix build .#packages.aarch64-linux.default etc. instead of nix build and the cachix action should pick things up automatically, right?