Caching Nix store?
alphapapa opened this issue · comments
Hi Steve,
I was reading https://help.github.com/en/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows and I wondered if it would be possible to cache the Nix store to speed up the action on subsequent runs. Since the Emacs binaries that are installed should change very rarely, it would seem like a good candidate for caching. And I've noticed that, in my runs using this action, setting up Nix and Emacs takes much longer than linting and testing, so it could greatly reduce runtime.
However, that documentation says that only paths in $GITHUB_WORKSPACE can be cached, and since the Nix store is in /nix, I guess that won't work.
But I wonder if there's a way to use a per-user Nix store in a different location. I know that Guix can install software per-user, and I'm guessing that Nix can too. If that could be done, maybe caching could work.
What do you think?
Thanks for your work on this!
Thanks for filing this for discussion.
Ultimately, all of Nix is a cache served from S3 or similar. What you're describing isn't really something that fits the Nix model. If you look at what happens on Travis, people aggressively cache things that could just be downloaded from the network, so it just adds build overhead in the form of compressing, uncompressing, uploading and downloading big cache tarballs, also to S3. I don't think Actions is any different in this regard. What might work is providing a downloadable "closure" for each Emacs version and its dependencies, which would be unzipped under Nix. But some Nix machinery would still be needed for path setup etc.
This idea isn't really a viable route to explore in isolation IMO.
Ok, thanks.
I know that Guix can install software per-user, and I'm guessing that Nix can too.
nix uses just one directory (/nix/) for user's and system's packages. To avoid recompiling every single package you need, it is strongly recommended to use this directory and not a custom one. Guix being based on a nix daemon, I think the constraints are exactly the same.
What it comes down to is that the closure of emacs + dependencies can be safely unzipped under /nix on any machine, but Nix itself provides content-addressed caching to optimise the process when not all of those dependencies need to be freshly installed. The key overheads, then, are:
- Some of the system-wide libraries might be adequate, but Nix will never use them. This is kinda the point of Nix, but it's also why just installing a prebuilt EVM Emacs will always be faster
- Installing Nix in the first place means downloading some basic tools and the nixpkgs "recipe" collection, which can already take a little time.
The more you use Nix for installing other helpful dependencies, the less the overheads matter, of course. And the more you value the reproducibility of Nix on various systems, the less concerning they are.
is it possible to setup Nix in prefix under $GITHUB_WORKSPACE?
Setup of emacs takes much longer than other steps.
The Emacs installations are already cached via cachix, so that part wouldn't get any faster. Do you mean caching the initial Nix installation itself? It can take 25 seconds, but caching it via the action cache wouldn't be possible because it also sets up users.
Is it really a big issue? I find it only a small annoyance.
It's possible to use install-nix-action yourself at the beginning of a job, and then run several consecutive setup-emacs and run steps with different Emacs versions. That involves less installation time, but more overall duration.
One thing I haven't explored is alternatives to install-nix-action. For example, there's https://github.com/DeterminateSystems/nix-installer-action. I currently have an inline version of the former, but if setup-emacs finds that nix is already installed, it skips the installation. So an interesting test would be to try using nix-installer-action directly, and see if it's faster overall.