I recently learned that it is possible to use nixpkgs channel releases in flake inputs.
(Credits to TLATER):
More specifically, is there a reason to use one over the other? How is the nixexpr.tar.xz release generated, and how does it differ from a normal git checkout?
# channel release
inputs.nixpkgs.url = "https://channels.nixos.org/nixos-unstable/nixexprs.tar.xz";
# git release
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
Main benefit I see in using the channel tarball is less dependency on github (which is region-locked) and its API (which is rate-limited and is subject to change outside of nix’s control).
Release tarballs also contain some extra metadata making this possible:
It is also notably smaller by 33%, since it uses lzma and not gzip.
Would it be a welcomed addition to Official NixOS Wiki to mention that it is possible to use the channel release expression as nixpkgs input? I’m quite confused to not see any documentation regarding this and the differences that arises. Especially that channel releases seems to better in all regards in my research and according to your reply.
I searched on GitHub with regex and found that there are less than 200 people using the channel releases, and almost 100k people using the git checkout input. The difference is staggering.
I opened this PR command-not-found: enable and default to channel release's dbPath by leana8959 · Pull Request #489532 · NixOS/nixpkgs · GitHub because I realized I could point dbPath option to the database shipped with nixpkgs. I understand that it was noisy and “broken” because it currently points to the stateful NIXPATH, but it suffice to point it to the right database and it would work properly. I think this is another reason to advocate for channel releases in flake inputs.
How is the channel tarball is generated? I was able to find some related code under nixos/releases but I can’t seem to find how programs.sqlite is built. I grepped in hydra’s source code but found nothing as well.
Yup, I do it for the same reason. The less hard dependencies on Github, the better. I really like what they offer but it’s been a pain lately.
I’ve been pulling the channel for my inputs for about a year now and not once has it caused me any trouble, so I can generally recommend it!
I’m also trying to use those channels http urls for my nixpkgs inputs. I understand the github rate-limit issue, so my question is, given that any GH repo has public http urls for archives, like https://github.com/user/repo/archive/refs/heads/main.tar.gz wouldn’t it be better if the nix command actually used that kind of url for github:user/repo/main inputs? or why does it has to consume GH rate-limits, do archive urls like the one above are also rate-limited ? Is it worth any good if for all other GH inputs we use such http archive urls ?
All gh endpoints are rate-limited.
GitHub also almost certainly doesn’t implement the lockable tarball protocol, so those would be static, un-updateable inputs, that break any time they’re not cached.
It’d make sense for a forgejo: input type, though.
As far as I know, github:user/repo/main already works this way. It works similarly by first using git ls-remote https://github.com/user/repo --ref refs/head/main to get the latest commit hash, and then downloading https://github.com/user/repo/archive/{commit hash}.tar.gz.
The number of users who correctly use channel releases may be smaller. I found that about half of the search results used Chinese mirror sites, and none of these mirrors have lockable tarballs. The only reason they use this channel is probably that they cannot access GitHub.
It’s the usual chicken-and-egg problem. There isn’t really a concerted effort for good, centralized documentation around the nix ecosystem. It’s all quite ad-hoc and grassroots efforts, so there’s no good way to broadcast information about changes like this into the world. This is exacerbated by the official documentation largely ignoring flakes (for good reason), so most flake documentation is just random blog posts.
The lockable tarball protocol is about a year old, so only people who read the release notes carefully (or read one of the three posts I’ve written on the topic) even know about the feature.
Hence few people are using it. Since few people are using it, not many people would know to write about it, so there are few examples, and little documentation.
The git-based input types meanwhile are already omnipresent, most documentation related to flakes from the last 5 years will be written with them. New users are overwhelmingly more likely to only encounter that style, and hence propagate it themselves.
If they do encounter the alternative, they’ll typically be skeptical because nobody else uses it. I usually have a hard time explaining why people should switch; when you suggest replacing something the onus is on you to explain why, even if the user never thought about why they use what they’re using in the first place.
The result is that the inferior input type gets exponentially more documentation and users.
It’s a very nice case study of the early adoption advantage 
People just use whatever is the default,
and having bad defaults is a very specific nix problem.
npins apparently does this correct, why do flakes do it wrong?
That’s the point, these aren’t defaults, as there are no default input URLs or templates. It’s thousands of people independently choosing to do something; you can’t explain this without network effects.
Unless you refer to the global registry, but that’s a different topic than what is being discussed. That in turn is just a case of historic settings not being updated.
npins are a completely different story; they weren’t tied to flake input types and implemented a special case for channels.
The flake implementation instead wanted to standardize beyond just nixpkgs, so a good solution took a while to materialize; but that’s fine, flakes are experimental, after all, nobody should be relying on them for production (right?).
There is the official templates though. However as people have pointed out that the HTTP locking RFC is new, is it supported by older nix releases?
Nope. It’s in the manual since nix 2.18. I think it’s been long enough to be generally recommended, but indeed perhaps not for adoption in the global registry.
The global registry is anyway one of those unresolved problems, though.
Do the URLs rot or not? If I come back for deadbeef on Nixpkgs-unstable in 2 years, will the link still be there? I can’t seem to tell or poke around the resolution URL https://releases.nixos.org/nixos/unstable/ is empty to see if what hashes are there. I was looking at the TUNA + some of the other Chinese mirrors for channels & they seem to drop old hashes relatively quickly—which signals to me that these might not be the best to work with for projects if you can’t come back to a stable hash.
I would love if I was wrong, so does anyone know?
The Chinese university mirrors don’t use lockable tarballs, they’re not representative of what’s happening on nixos.org.
It resolves to something like this: https://releases.nixos.org/nixos/25.11/nixos-25.11.5198.e576e3c9cf9b/nixexprs.tar.xz.
Currently, great care is taken not to even garbage collect historic binaries if there’s any chance they may be used (that may subtly change, but currently the focus is to tame storage requirements by means that have no visible effects).
I think the last possible thing that will be considered for deletion are these tarballs. Besides being the only thing required for reproducible builds, the nix-channel command relies on these tarballs as well, and nobody worries about that suddenly no longer working.
Case in point;
Oh, nice. I was truly unsure about the stability of this so I didn’t mess with it. I will actually use it now that I understand that better!
Are there any mirrors that do mirror nixos.org? What happens when it’s down?