Pull nixpkgs as tarball from channels.nixos.org (another try)

[xokdvium]

Actually working solution for #61. Don't even ask what "exact" is doing here, but it's load-bearing for this to work. Stuff like nix flake metadata nixpkgs/nixos-26.05 (and nix flake metadata nixpkgs) uses the channel tarballs, while nix flake metadata nixpkgs/master falls back to github:nixos/nixpkgs/master.

[xokdvium]

Ugh the CI is wrong here, to get the right behavior we explicitly should have the non-exact entry for nixpkgs last.

[xokdvium]

This particular feature has been around since NixOS/nix@7402451 (so forever).

[xokdvium]

The sortedness requirement is kinda incorrect, the flake registry is order-dependent and "disorder" is required for the channel tarball redirects to function correctly (the exact matches should come first before the catch-all nixpkgs).

[pennae]

we would strongly suggest making snapshots of the flake registry a build input to both lix and nix packages at the nixpkgs level. the registry changes very infrequently anyway, much less frequently than staging rebuilds happen. as it stands now the registry is materially worse than it was before because it's missing a bunch of nixpkgs versions, all of which lix (which ships a snapshot of the registry already for stability reasons) would have to track at all times. that's impractical for us to do and would make UX for our users significantly worse

[xokdvium]

as it stands now the registry is materially worse than it was before because it's missing a bunch of nixpkgs versions

How so? Stuff like nixpkgs/nixos-25.05 falls back to github:nixos/nixpkgs/nixos-25.05.

[pennae]

How so? Stuff like nixpkgs/nixos-25.05 falls back to github:nixos/nixpkgs/nixos-25.05.

ah, right. we misread part of the patch; we retract that criticism. we still suggest making a registry snapshot a build input of all flake-implementing nix implementations though for reliability, consistency, and not having to refetch the registry at runtime.

[xokdvium]

we still suggest making a registry snapshot a build input

That does make sense to me, though the are of course pros and cons to that.

As a conservative start, the flake-registry could just be defined by default in the NixOS module at the nixpkgs level to make NixOS users not have to look it up at runtime. With update scripts the tedium of updating could be circumvented. I guess in practice vendoring it at build-time is also a workable option, but rebuilding nix (and dependent NixOS tests) in the bumps might be a bit annoying.

[pennae]

shipping the registry via module settings is also on option, but lix will warn about that and potentially cause confusion. since registry changes are so rare we'd probably shove them into staging instead of going straight to the branches, that avoids most of the overhead and (seeing how lix hasn't yet had problems with a registry snapshot) probably won't negatively affect anything

[edolstra]

FWIW Determinate Nix includes a built-in copy of the flake registry as a fallback for when fetching fails: DeterminateSystems/nix-src@535a168

That may be worth upstreaming.