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.
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.
