Cache flake-registry

[centromere]

This change permits the flake registry to be included in the resulting Docker image.

[oldaccountdeadname]

You wouldn't be able to document this in the changelog, would you? I'm away from my clone at the moment but I believe it's in doc/manual/src/release-notes/rl-next.md.

[edolstra]

We can't lock this file because it's mutable and not a redirect. Probably better to use the underlying git repo (https://github.com/NixOS/flake-registry).

[centromere]

@edolstra Do my latest changes resolve this concern?

[thufschmitt]

The change looks good. I'm curious what the use-case is otoh. Isn't the registry file fetched (and updated) on-the-fly anyways in the image?

[centromere]

@thufschmitt I am using nix in various CI pipelines. The nixos/nix image on Docker Hub has nixpkgs bundled within it, however it exists in the context of nix-channel, not flakes. As a result, when the CI job runs nix build, it always downloads the latest version of nixpkgs. This means that the same CI job may produce different results depending on when it is run. Additionally, it adds a dependency on the nixos cache.

#6686 contains changes which address the problem. This PR is to ensure that the flake registry is cached also.

[garbas]

I've been thinking about this PR for few days now and I'm not 100% this should be merged. But of course I might be wrong as I was many times :)

It is important to know that the purpose of this Docker image is to give a users (especially new users) a great Nix experience while still running it in the familiar Docker container.

Looking at the old Nix commands it is expected that nixpkgs channel is set and correct NIX_PATH is set. This is not anymore true for new Nix commands. The expected behavior is actually that the last nixpkgs is going to be used. That also implies that latest flake-registry revision should be used.

Now I do understand that for CI it would be nice cache this. But I think the change might produce some unexpected results (eg. not really using the latest versions of flake-registry and nixpkgs.

I'm wonder if we can somehow work around to make both use cases work?

[centromere]

@garbas I closed #6686 and opened #6831.

Now I do understand that for CI it would be nice cache this. But I think the change might produce some unexpected results (eg. not really using the latest versions of flake-registry and nixpkgs.

I have a single GitLab project with a single flake.lock file at its root. This project is responsible for building and publishing 21 distinct software applications. The build and publish steps for a given application are split in to two distinct CI jobs. That makes for a total of 42 CI jobs. The compressed nixpkgs tarball downloaded from GitHub is ~30 MiB. If this tarball is not cached somehow, then a single run of this pipeline requires me to download and decompress ~1.2 GiB of data just for nixpkgs. That's a lot of network and disk I/O (leading to wear and tear on the SSDs, etc). Even if I run my own binary cache or use Cachix, the problem is not solved because I have to decompress and write the information to disk needlessly many times per day. The nixpkgs tarball, uncompressed, is 193 MB. 193 * 42 = ~8 GiB of writes to disk for a single run of a single pipeline, even if there is no work to do.

Luckily, all these software applications are contained within a single flake, which ensures that the same commit of nixpkgs will be used everywhere. However, this is just one GitLab project. We have ~250 GitLab projects. It seems highly unlikely that every project across the organization will use the same nixpkgs commit in its flake.lock file, which completely defeats the purpose of caching nixpkgs within the image.

I am doing R&D on different approaches to try and ameliorate these issues. It might very well be that caching the flake registry and nixpkgs is not the way to go, in which case I will close these PRs.

[fricklerhandwerk]

Triaged in the Nix team meeting 2023-03-17:

We're not sure what the tradeoffs are.
Provisionally assigned @garbas as the de-facto maintainer of the Docker infra. Do you have any capacity to deal with this?

[garbas]

I can see adding the functionality to docker.nix helper to create an image with flake-registry already inside. By default the nixos/nix docker image should still works as now (we actually do want flake-registry to be the latest and being fetched), but if somebody want to create a custom nix docker image we can have this option to do so.

@centromere Would that be OK compromise for you?

[garbas]

I've merged current master, resolved conflicts and made flake-registry optional. The change does not affect nixos/nix docker image.

[centromere]

Looks good, @garbas. Thank you!

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-17-nix-team-meeting-minutes-41/26614/1