A common pattern for nixpkgs flake inputs is to use a URL like github:nixos/nixpkgs/nixos-unstable. This isn’t the best choice! Instead, you should probably be using the official project-hosted channel tarballs from channels.nixos.org. Here are a few reasons why:
Reduced Download Sizes
The project tarballs use zstd compression, which is more efficient than Github’s gzip. By switching, your download sizes drop by 20%, completely free!
Forge Independence
Many have, justifiably, complained about the downsides of using GitHub as the project’s forge. While switching away from GitHub is still infeasible, you can help improve our ability to do so! By using the project tarballs, you uncouple your configuration from GitHub, making it easier for us to move away in the future.
Other Benefits
No issues with problematic and unstable GitHub rate-limiting.
Automatically-included database for command-not-found, which displays the package to pull for commands you don’t have installed.
Stable branches are supported too; simply change nixos-unstable to your preferred branch.
Extra, bonus tip! Unless you specifically need to pin a stable branch, nixpkgs-unstable is probably the best branch to use for project flakes; e.g. anything that won’t be building a NixOS configuration. It moves faster and is an even smaller download than nixos-unstable.
It would be nice if inputs had a comparably nice protocol shorthand for this so it looked like more of a proper idiom and didn’t require as much recall for new projects.
Yes, it is. Stop doing that! Indirect flake references in inputs can cause a number of subtle issues. They’re best just avoided. (In fact, multiple people have suggested they be disallowed by nix itself…)
To date I have not found this documented in any proper formal place. It should probably be in the Nixpkgs manual and in the NixOS manual. I’m sure a PR would be welcome.
Probably the most common one is failing to update at all because the registry pins nixpkgs to a specific commit, particularly if that pin is generated from a nixos config in the flake itself that pins to the flake inputs.
More generally, it’s just plain counter-intuitive that the behavior nix flake update is environment dependent.
I wasn’t suggesting it was happening in this case. It’s just the most common problem I’ve seen.
Using the registry from the command line is perfectly reasonable. I don’t think anyone is advocating against that. The problem is when you involve the registry in your flake.nix’s inputs section.
Thanks for pointing that out! I just put up a PR to change that:
I’m on a bit of a mission to change the defaults here to be better, so please keep pointing out areas where that’s still the recommended/default pattern.
I was confused for a moment at the idea that pointing to an URL would cause issue when wanting to reproduce that build, but it turns out this URL redirect to a fixed input with some hash in it. I’m going to guess that the flake lock will pin that instead of the raw input URL. (I personally tend to use nixpkgs instead. Just a nice shorthand. It is true a way of pinning the flake registry itself as a flake input might be usefull. Thought that has not been a problem for me yet)
Does this interact well with the CLI flake update command? My current workflow is a weekly scripted update to the latest nixos-unstable which gets built by CI as PR against my infra repo. Although I haven’t had any issues with that workflow I’m always happy to move away from implementation details like being tied to GitHub directly.
Switched over one of my test-systems to try this. Poor little CPU had a hard time decompressing a ZSTD file. Did a bit of a search to figure out what to use for my 26.05 setup. It must be obvious to most people here which part of the URL to edit but I would still suggest instructions and documentation somewhere, like other have already mentioned (wiki.nixos.org specifically suggests using GitHub in flakes). Saying that flakes are experimental and for advanced users only is not really an excuse for skipping documentation any more.
Is there a similar way of working for home-manager? It probably uses GitHub as well.
I also found this during my search, linking them together by posting it.
I’ve been using these tarballs for about a year now and I quite like it.
I found that if I had issues after updating my nixpkgs input and identified a revision on GitHub containing the fix, I’d reach for nix flake update --override-input with that specific nixpkgs revision. Now, instead of picking a specific revision on GitHub and it possibly not being built by Hydra (potentially rebuilding a lot of stuff…), I can go to Channels for NixOS project(s), scroll down to the bottom, pick a built revision and use its nixexprs.tar.xz link in the nix flake update --override-input command. Substitute nixos-unstable for your preferred channel branch. There’s probably a more straightforward way to do it like looking through Hydra build status (or using hydra-check), but this is what I use.
Tangentially, I have been using the nixexprs.tar.xz tarball. Are there benefits to using nixexprs.tar.zst instead?
