Questions about `inputs.nixpkgs`

[TLATER]

@Malix

@TLATER

you should objectively be locking to the hydra output tarballs, using the github:NixOS/nixpkgs URLs is just wrong.

Could this be elaborated, and do other Nix proficient people agree?

The way I understand nix’ CI infrastructure (from reading these docs apparently) and branching strategy things go roughly as follows:

1. A commit is pushed to the respective dev branch (master or release-YY.MM).
2. Hydra eventually picks up the commit and starts building packages and tests.
3. Hydra completes
4. Upon completion, hydra:
   • Produces the release tarball
     • This contains the relevant command-not-found cache (and man cache?)
   • Hydra fast-forwards the respective non-dev branch (nix(os|pkgs)-unstable or nixos-YY.MM)
     • There are sub-points to the CI completion that trigger the *-small and *-darwin releases

As such, the release tarballs are more complete, aren’t subject to the same rate limits and censorship as GitHub (which have caused many folks headaches in the past), and mean actually using the nixpkgs infrastructure as intended. You can build from the branches, but those are downstream from the release tarballs and you get less complete artifacts.

@Malix

What could be the potential tradeoff of doing that?

Older versions of nix won’t be able to resolve the input correctly, though they should interpret the lockfile correctly I think? Other than that, none, you’re just using nixpkgs as intended, before the limitations of flakes resulted in people using the git repo directly instead of the release tarballs. I.e., you’re getting the same stuff nix-channel used to download.

CDN details change, too, I suppose, but the tarball is ~40MB, while the shallow git repo is ~80MB compressed, so you’d have to have a pretty bad connection to NixOS infra to have overall slower downloads than from GitHub.

@Malix

I think remembering over the vast majority of the nix flakes configuration I have seen, nixpkgs inputs were almost always using a version of a github:NixOS/nixpkgs URLs (and some using nixpkgs FlakeHub URLs)

I don’t think I have seen it recommended in the wiki either (but probably should if that is correct)

This feature only came into existence a few months ago. You’re looking at half a decade’s worth of ecosystem. Of course not all of the above have updated, nor has your memory retroactively inserted a feature that didn’t exist. The fact that this is even possible hasn’t been remotely advertised beyond that PR either, so the vast majority of the community will be as unaware as I was.

It’s not exactly intuitive behavior, normally a url doesn’t magically resolve to a different location at flake resolution time, so I don’t think anyone would be looking for this either unless they scanned the nix release notes and understood what the feature name meant at a glance. I imagine this passed by most of us.

@Malix

Are those benefits not possible to be worked on and added for git urls?

Not really, since the command-not-found (and man?) cache fundamentally has to be produced during the build, so it cannot reasonably be committed, and the cleanup steps involved in reducing the tarball size most likely involve removing dev-only cruft from the repo.

Using git for release versioning is anyway a bit of a hack, this is much nicer IMO.

---

Overall, really awesome work from detsys, thank you @grahamc & co for upstreaming this. It’s technically a small fix, but if we can get over the collective inertia I think this has significant impact. Even just the emission savings from cutting all nixpkgs update downloads in half matters.