nix.dev
nix.dev copied to clipboard
Anti pattern: nix-channel command
- https://github.com/NixOS/nix/issues/3601
This was linked in an answer about "channels being phased out".
There was recently a user asking questions on the NixOS IRC channel, confused about what "channels being phased-out" meant.
As this article is part of the website, this it not exactly great. This is giving out a message that officially something is decided here, while I don't even know where to start looking for a citation about that.
Furthermore, the link "Channels" points to the NixOS wiki article that is more about the Hydra process of marking revisions as good and tested than the nix-channel command (which I assume is what you state is being phased out).
What was the meaning of that note? Is Hydra being phased out? (I guess not :)) Is it about nix-channel being de facto being replaced with Flakes? Is there more?
Until I have time to write about channels, beginners have to blindly believe they are better off not using channels.
The constraint here is my time, but this is OSS project so everyone is welcome to contribute :)
Yes, I understand it's OSS and everyone is welcome to contribute.
The problem I have is I don't know where you are going off with that thought. If I knew what you were going for, I wouldn't mind proposing changes.
This is currently used on the official website. So this leaves kind of a weird unfinished thought about a tool that is part of the tool, and distro! There is no announcement of the sort, but it's stated that it's being phased out, but nothing about what replaces it.
cc @garbas
It's possible to avoid channels without flakes, although flakes will make that a lot simpler.
https://nix.dev/reference/pinning-nixpkgs.html offers solutions, although it's not complete nor structured (yet) well.
So I'm going to collect here all the reasons channels are an anti-pattern:
-
it's an abstraction that provides CRUD operations over an archive (usually zip/tarball) which is mapped to a commit, but the abstraction provides no benefits over just using pinning a git revision
-
it's hard to inspect what git revision is in an archive (nixpkgs has a function to retrieve that, but in general case of channels there's no way to check what version of the channel you're using)
-
it's global state that impacts the whole Nix evaluation results, defeating the whole purpose Nix was created for (to have deterministic properties for packaging)
-
it's possible to inherit channels between root and user, which is little known even to experienced Nix users, like which one overrides which?
-
my pet peeve: it doesn't validate input for commands and provides really poor UX for newcomers
So I see two simple alternatives that exists today by managing Nix sources via source control:
a) Either use builtins.fetchTarball("channel:nixos-20.09") and always get the latest release (I wish it prefix was named release, not channel).
b) Or you let git version nixpkgs source, by either: pinning the revision or managing its lifecycle using niv or flakes
-
Widespread conflation of nix-channel, NIX_PATH and the hydra.nixos.org channels, all of which can but probably shouldn't be called channels.
-
Relies on NIX_PATH which fundamentally does not support composition of expressions that need a different value for it, in contrast to function arguments or even Nix flakes' dependency injection.
it's global state that impacts the whole Nix evaluation results
Even worse, machine-or-user-or-both-global. If only it was global; you ssh somewhere and your channel may as well not exist. Am I thinking too big? :)
builtins.fetchTarball("channel:nixos-20.09") and always get the latest release (I wish it prefix was named release, not channel).
It appears like only hydra.nixos.org will be able to provide "channels" in the newspeak?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/how-do-i-run-nix-shell-with-a-package-from-my-own-new-channel/44242/1