Questions about `inputs.nixpkgs`

Help
1

I am a Determinate Nix user

As per the Determinate Docs - NixOS Installation page:

{
  inputs.determinate.url = "https://flakehub.com/f/DeterminateSystems/determinate/*";
  inputs.nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0";
 
  outputs = { determinate, nixpkgs, ... }: {
    nixosConfigurations.my-workstation = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        # Load the Determinate module
        determinate.nixosModules.default
      ];
    };
  };
}

And particularly,

inputs.nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0";

I was wondering:

What are the benefits of consuming nixpkgs from FlakeHub than from GitHub directly?

Importing from GitHub being:

inputs.nixpkgs-stable.url = "github:NixOS/nixpkgs/nixos-25.05";
inputs.nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixos-unstable";
2 Likes
2

there is no benefit in doing that

6 Likes
3

Exactly. You’re adding a new point of failure and trusting a 3rd party to deliver you the code.

5 Likes
4

If you use both dix+flakehub, I think you get more control on which version of nixpkgs you are pinned to. They allow some non-standard formatting of inputs in their fork.

Flakehub enables some non-standard formatting of inputs. Corrected below.

See SemVer

5

There’s only 5 regular branches on github to pick from (3 stable, 2 unstable).

nixpkgs is not versioned, so using flakehub nets you nothing here.

3 Likes
6

you can pin a revision in the uri on any git input :slight_smile: which is the extent of version pinning you need for nixpkgs

3 Likes
7

Maybe not for nixpkgs specifically, but for other types of inputs with more traditional versioning a feature like this would certainly be nice to have :slight_smile:

8

90% of flakes revolve around nixpkgs in the end and so theyre subject to the same stable/unstable/master versioning scheme. There is no tangible benefit to flakehub as of now. I agree that proper versioning would be nice and I’ve discussed this with some folk at nixcon, but doing it in flakehub is not the right place. Don’t use it

6 Likes
9

Using GitHub is also trusting a 3rd party to deliver the code.

1 Like
10

Sure, a few things.

A small thing is that fetching from FlakeHub you’re not making requests that count against your GitHub rate limit.

semantic versioning

A major one is that FlakeHub URLs support semantic versioning rules in the URL. This works for users of any version of Nix, since at the end of the day they’re just URLs.

The immediate benefit here is that inputs.nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0"; will fetch the current stable release of Nixpkgs.

That is not comparable to inputs.nixpkgs-stable.url = "github:NixOS/nixpkgs/nixos-25.05";, which will be stuck in time to the 25.05 release. Using FlakeHub for the stable input keeps you on the current stable automatically, every time you update your flake inputs.

Following semantic versioning rules, you can also specify a minimum version of nixpkgs. If you specify inputs.nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0.1.858212"; (the current unstable NixOS release of nixpkgs) then you will always get a version of Nixpkgs that is at least that specific version.

That seems like a weird question: why isn’t it always 0.1.858212 exactly? Because it is a semantic versioning specifier. If you want 0.1.858212 exactly, you have to specify =0.1.858212.

Isn’t that useless? No: it is possible to minimize a given flake and all its various required nixpkgs versions by locally solving the various defined requirements of of nixpkgs. This doesn’t currently happen today, but all the data is there to get it done. Concretely that means if you have 2 inputs, one with 0.1.858212 and one with 0.1.700000 the solver could unify this into a single flake input.

release records

Another bit of utility I frequently get from FlakeHub is using its archive of every release of Nixpkgs as a source of points to bisect. It is typically frustrating to bisect Nixpkgs unless you have a good idea of every time all the tests passed and the release actually happened.

Maybe this has changed since I last looked, but there is no convenient source of all the historical releases and when they were made. In contrast FlakeHub has a release recorded for every push, including the commit and date/time of the release.

checked flake validity

Occasionally over the last few years, the NixOS channel will advance with a broken flake.nix for some users. Our CI process validates that the flake works consistently before publishing. Nixpkgs’ CI itself has added this check, too, though occasionally the check has stopped working. In the future, I would expect us to add more checks, like making sure a certain (additional) subset of packages are built.

predictable updates

Our installer sets users’ nixpkgs on the CLI to point to nixpkgs-weekly. That flake is just a direct duplicate of Nixpkgs, but it only updates on Tuesdays. That means users only fetch a fresh nixpkgs once a week on Tuesday, and are then not stuck with random refetches throughout the week. We’ve heard from a lot of users who were frustrated by updates randomly interrupting their CLI workflows, appreciating that our weekly variant takes a lot of annoyance out of their day.

Anyway, here’s a few things I like about getting Nixpkgs from FlakeHub. If you don’t find it too compelling, no worries! FlakeHub isn’t doing anything specifically magical here, just a number of small enhancements that – for some users – add up to a nicer Nix experience.

5 Likes
11

So let’s be 2000% clear - github is the source of truth for nixpkgs (at this time). Would it be nice to migrate off? Sure. But I don’t see that happening soon.

Flakehub is an additional third party that you have to trust if you use their servers. And that requires trusting Github and Flakehub. That should be quite obvious already.

2 Likes
12

To what @grahamc said above I’d add that fetching from FlakeHub is also not affected by GitHub downtime. GitHub is a massive platform that does a million things and thus has many possible sources of failure (imagine, for example, Copilot’s infrastructure having issues that compromise GitHub’s ability to serve tarballs).

Now, FlakeHub, like all infrastructure, isn’t bulletproof and downtime isn’t inconceivable. But I do think it’s significant that FlakeHub is a fairly straightforward platform, with few sources of failure, built to do a small handful of Nix-specific things.

13

Semver has nothing to do with nixpkgs. nixpkgs does not use semver.

Which will automatically break every 6 months. The entire purpose of running stable is to avoid breakages and give people a month to upgrade at their (or their business’s) pace. This is the exact reason there isn’t and never should be a nixos-stable branch.

That’s a bit nonsensical because it doesn’t actually map to anything obvious in nixpkgs.
That last number is presumably the count of commits on that branch but that doesn’t translate into an actual commit you can look at/reference unless you have a local clone and can run arbitrary commands to do that transformation.

That’s a non-benefit as of today, as such version resolution doesn’t exist in nix.
Promising future benefits is not a reason to use something today - see Tesla for example.

Releases happen hundreds to thousands of commits apart; that’s not really a bisection if you have 1400 commits remaining to sift through (which happens at least every 2 weeks after the staging-next → master merge).

Surely that could be upstreamed to benefit all nixpkgs users; we can just improve the nixpkgs CI directly.

When using flakes with your config, NixOS sets the nixpkgs flake registry entry to the nixpkgs input that the system was built with. For non-NixOS systems, eh, maybe there is some point to this, but for NixOS itself these “random refetches” can be avoided by using that registry entry and/or overriding via the CLI.

4 Likes
14

Note that you can also use the channel tarballs as flake inputs if GitHub downtime (or ratelimiting and censoring) is a concern, e.g. https://channels.nixos.org/nixos-25.05/nixexprs.tar.xz. This actually has some benefits over using the git repo directly, mostly some artifact generation that isn’t done in-source, and these tarballs are tied to hydra evaluation completion so AIUI you’re a bit less likely to hit uncached artifacts (see also what @grahamc and @waffle8946 refer to with cache misses).

It sadly also comes at a pretty hefty evaluation cost; it’d be nice to have better support for the hydra tarball infrastructure in nix. Actually it doesn’t, see this post. I think this means you should objectively be locking to the hydra output tarballs, using the github:NixOS/nixpkgs URLs is just wrong.

Honestly, nixpkgs mirroring is an interesting question. I wonder how accessible nixpkgs is in China, and to what extent the packages are buildable. Probably not very, which is a shame given how much nix lends itself to making FOSS available through source location substitution.

7 Likes
15

There’s a 5-year old mirror for that:

And as they are a pure mirror, the provenance of all artifacts can be verified.

2 Likes
16

Could you elaborate? Is this a one-time-per-channel-update cost or is this every time you would run nixos-rebuild? And is just specifically for unpacking the nixexprs.tar.xz file, as opposed to costs relating to evaluating the nix expressions once unpacked?

1 Like
17

The issue is that you can’t lock an ever-changing tarball. You’ll have to keep nix flake update-ing, especially if you share your flake between multiple machines. I suppose I should say that rather than support for this in nix we need better artifact output on the channel side.

4 Likes
18

Ah, I see I should have read more closely. So evaluation penalty with specifically

https://channels.nixos.org/nixos-25.05/nixexprs.tar.xz

and not

https://releases.nixos.org/nixos/25.05/nixos-25.05.<ncommits>.<githash>/nixexprs.tar.xz with ability to follow along as <ncommits>.<githash> advances.

FWIW, npins does allow to follow along in this way, and I assume nothing fundamental to the flakes schema should prevent an implementation of this nix-channel-like functionality?

19

This is not true actually. Serving Tarball Flakes - Nix 2.30.3 Reference Manual

nixexprs.tar.xz implements this:

6 Likes
20

(This is exactly what Flakehub uses internally IIRC)