Generate fallback-paths in a flake output instead of "hidden" perl

[roberth]

Motivation

Currently, nix-fallback-paths.nix is generated in the release script. Let's make it more declarative instead, so that

• Users can check that the fallback paths file is correct, by building it
• It makes the release process easier to understand
• It removes a duplication of the systems attrset
• It simplifies the release script

The new package provides the contents for nix-fallback-paths.nix in NixOS, but without the weirdly specific name that's for the purpose of nixos-rebuild.

TODO Follow-up:

• update release script to download the file instead of generating it

Question:
Do we want to rename this and provide JSON? I think using a data format for data is good, as it makes alternative use cases possible. The current name is a layer violation.

(Ideally we should have a store-level json based package description format, but that's overkill for this particular use case; it would make the entire solution reusable though, whereas the current thing or this PR are still an ad hoc format.)

Context

• Originally written for nixos: add script to automatically update nix-fallback-paths nixpkgs#343657. Although that wasn't the right approach, still this would be a good refactor when the release script downloads the file instead of generating it in perl.

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

See my comment here. We shouldn't have multiple release processes.

[Mic92]

My answer here: NixOS/nixpkgs#343657 (comment)

[roberth]

We shouldn't have multiple release processes.

Yeah I marked it as draft when I realized this was (obviously) already in the release script.
So while its original purpose isn't good, I think it's still beneficial to make declarative what we can, and do less in the release script.

• Users can check that the fallback paths file is correct, by building it
• It makes the release process easier to understand
• It removes a duplication of the systems attrset
• It simplifies the release script

I'll update the description

[roberth]

It's unnecessarily difficult to simplify the release script without having an example of this on Hydra, so I'll make this a two-parter.

Part one ready for review, right here!

[edolstra]

It simplifies the release script

Does it though? I feel that

# Upload nix-fallback-paths.nix.
write_file("$tmpDir/fallback-paths.nix",
    "{\n" .
    "  x86_64-linux = \"" . getStorePath("build.x86_64-linux") . "\";\n" .
    "  i686-linux = \"" . getStorePath("build.i686-linux") . "\";\n" .
    "  aarch64-linux = \"" . getStorePath("build.aarch64-linux") . "\";\n" .
    "  riscv64-linux = \"" . getStorePath("buildCross.riscv64-unknown-linux-gnu.x86_64-linux") . "\";\n" .
    "  x86_64-darwin = \"" . getStorePath("build.x86_64-darwin") . "\";\n" .
    "  aarch64-darwin = \"" . getStorePath("build.aarch64-darwin") . "\";\n" .
    "}\n");

is simpler than nix-all-output-paths.nix. It's also a lot more efficient (a Nix expression that depends on the Nix closures for every platform is very painful for Hydra, since the builder needs to fetch all of those closures from the binary cache just to write a little text file.) It also means that we can't make a release if any of the non-critical systems is broken.

all-output-paths.{nix|json} seems like a misnomer since it doesn't include all output paths, just the bin paths. Including (say) the doc outputs might be useful for updating the manual on the website.

[roberth]

Does it though? I feel that [...] is simpler

Most of the complexity is in the interfacing with Hydra.
It should be little more than (formats.json {}).generate when we get rid of the .nix.

What weighs heavier to me is that it's hidden away in a release script.

a misnomer since it doesn't include all output paths

Fair. I meant to refer to all system types, but that's not clear at all.

painful for Hydra

Ok.

• Depends on Opaque dependency #9558

... back to draft