But we don’t think that indirect references inside of flakes are reasonable. In fact, we’ve seen this as an ill-conceived misfeature for years because it produces a hole in flakes’ reproducibility guarantees, as the reference can resolve to different things depending on what’s in the registry.
It doesn’t matter what the inputs field is, as long as you have a flake.lock. Calling this a “hole in the reproducibility” is a bit overblown IMHO.
You wouldn’t send a flake to someone to reproduce it, but also tell them to run nix flake update before.
Once the flake.lock file is in place, yes, that is true. And we don’t issue a warning in that case either. You’ll only see that warning with a “fresh” flake.nix, for example if you initialized a flake template with only a flake.nix or a situation like that. The reproducibility gap comes in two situations that I can think of:
- You can produce two different
flake.lockfiles depending on the registry - Evaluating the flake can downright fail if some input
fooisn’t in the host’s registry.
A catastrophic problem? Naw, I wouldn’t say so. But I do think it’s fair to call it a reproducibility issue.
I think your point is a nitpick; ultimately it’s surprising behavior for a flake registry input (especially when users don’t explicitly specify the input) to materialize in the flake.lock. The only exception I can think of is if the user explicitly opts into the registry by prefixing with flake:.
Besides, here’s a third problem scenario I ran into before: registry entries can point to paths, and will get added to the flake.lock as such, but won’t evaluate on other systems. This of course has the same issues as path: or x+file:// inputs, however, the cause is really non-obvious for many users in the registry case.
It’s a good thing to deprecate; I hope lix and upstream nix do the same!
Hey there.
I’ll preface this post with a link to a previous writeup about “channels”. This might help better orient readers about the subtle nuances of the topic.
So, I wanted to ask a couple questions before I get accused of FUD.
First of all, removing nix-channel and its associated semantics is great. The imperatively-mutated ambient impurities from those semantics are a big papercut, and one that realistically is part of the great Flakes blockage. If it hadn’t been for that, I would have tried to figure out a way to get rid of it a long time ago.
Considering I suppose this is intended to quickly get accepted into upstream Nix, since this is only a downstream distribution.
- What’s the plan for migrating existing users off
nix-channelsemantics? - What’s the plan for users who are not using Flakes, when migrating off of
nix-channelsemantics?
With that said, I’m a bit confused, if not worried about the channel:[...] form being deprecated at the same time. Is this just being done because of it being conflated with the semantics of nix-channel? They are wholly unrelated concepts! Only linked through the common usage of Nixpkgs release bumps.
The removal of channel:[...] seems misguided, since this is a great built-in method to refer to a Nixpkgs, whichever it is, from the last bump, from a given [Nixpkgs tested release bump] channel.
This is super-mega-confusing when your announcement instead suggests using the <nixpkgs> NIX_PATH look-up, which literally could point to anything. This is at odds with the stated goals of removing a “source of persistent confusion”. The NIX_PATH mechanisms which are entirely orthogonal to nix-channel are themselves a source of confusion that must be wrangled with proper care. I believe it is misguided to suggest yet an additional new and excitingly different set of semantics in this situation.
And I’ll add that even with the defaults implied when used with your downstream distribution, this is pointing to an arbitrary weekly update of nix[???]-unstable, maintained(?) by Determinate Systems, instead of the actual uspstream. (Side-note, FlakeHub updates for that all link to 404s… which does not fill me with confidence.)
So, the last set of questions are:
- What’s the rationale behind the deprecation of the
channel:[...]references?- (Note: the article does not explain why, only that it is now deprecated.)
- Why suggest using two additional layers of indirection?
NIX_PATHlook-up- Assumed usage of the FlakeHub hosted
nixpkgs-weekly
- And why one that is not owned by the NixOS org?
Cheers,
First off, which links are 404ing?
Ultimately, everything involving NIX_PATH, extra-nix-path, and the like are there as backstops. We don’t think that people should continue to use so-called “diamond” references like <nixpkgs> in their expressions but if they have old code kicking around, we’d prefer to not full-on break it just yet. But we don’t suggest doing that:
While we don’t necessarily encourage using the
<nixpkgs>lookup path for new things, we know that many of you may have bits of Nix logic that use references like this and we want to continue to support this use case for now.
As for why we use nixpkgs-weekly for that: it’s not subject to GitHub’s rate limits and having that backstop pointing to something that updates weekly rather than something like github:NixOS/nixpkgs, which updates many times daily, seemed like a reasonable middle ground. “And why one that is not owned by the NixOS org?” You seem to be gesturing toward some latent norm that I, personally, am not aware of.
Every commit referenced in the releases list:
(I will take time to read the rest of the message later.)
Ah, I see what you mean. I’ll get those URLs fixed. Thanks for reporting!
Why are you considering nixpkgs/master the alternative? No one should be using that except for nixpkgs development purposes. Regular users should be using the nixos-unstable or nixpkgs-unstable branches, which only update once every two or three days (sometimes longer). Is that still too frequent? If nixpkgs-weekly is based on master and not one of these branches, that’s a major problem, as master does not have the same assurances.
I was just giving an example. nixpkgs-weekly is just a backstop for channel references to Nixpkgs, nothing more. We suspect that most of our users never even run into this and if they complained we’d change it.
YMMV, this depends on the exact context IMO, but generally yes: as long as the semantics of angled bracket paths are referring to NIX_PATH, they should not be used to author expressions, but that’s again orthogonal to nix-channel semantics.
I believe we’re talking past each-other a bit since you’re talking about in their expressions.
The blog post may need to be edited to better explain that. The first thing after explaining that the channel:[...] syntax has been deprecated, you show that the angled-bracket syntax works, state that it won’t print deprecation messages (yet), and explain this works via the implicit assumption that the Determinate Nix default settings refer to the nixpkgs-weekly flakehub, from Determinate Systems.
To me, this read as a suggestion to replace the channel:[...] syntax.
Wouldn’t the channel:[...] form (which desugars into the longer https://nixos.org/channels/[...]/nixexprs.tar.xz form) not have this issue?
In fact, why is it even involving GitHub to fetch Nixpkgs? Upstream provides a tarball with the content of the release bump, why not use it?
Not a latent norm AFAIK. When using an upstream project’s resources, it is natural to use the sources or artifacts that they produce, instead adding an additional indirection layer that (assumedly) holds the same data.
In turn, just like the previous part of this reply, NixOS (the organization) produces a tarball of the Nix expressions for every channel bump.
They should be used. Unless I’m missing something.
Adding an additional entity in the middle seems misguided to me. At the very least right here it means that the updates lags by up to a week compared to the same intended input.
Now, I’m re-reading more attentively, and I’m seriously wondering: do you understand that channel:[...] and nix-channel are two pretty much unrelated concepts? Related only in that they end-up generally referring (in different manners, with different semantics) to a Nixpkgs tarball? (That tarball is then also confusingly often called a channel.)
The wording in the article makes me believe they have been confused and conflated. (You’ve also not answered my questions btw.)
This wording, bold my own emphasis:
This
nix-buildcommand, for example, still works:nix-build command emitting deprecation warning
nix-build -I nixpkgs=channel:nixos-24.11 '<nixpkgs>' -A ponysayBut because it uses the
nixos-24.11channel, it emits this warning:nix-channel deprecation warning
warning: Channels are deprecated in favor of flakes in Determinate Nix. Instead of 'channel:nixos-24.11', use 'https://nixos.org/channels/nixos-24.11/nixexprs.tar.xz'. See https://zero-to-nix.com for a guide to Nix flakes. For details and to offer feedback on the deprecation process, see: https://github.com/DeterminateSystems/nix-src/issues/34.
There is absolutely no nix-channel involved with these commands. None at all. None of their semantics.
~ $ nix-channel --list
~ $ env -i nix-instantiate '<nixpkgs>' --attr 'hello'
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
~ 1 $ env -i nix-instantiate -I nixpkgs=channel:nixos-unstable '<nixpkgs>' --attr 'hello'
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
/nix/store/lsdj5l8bxp5nczrgbk83v5lqqvdx6042-hello-2.12.1.drv
No nix-channel in sight. With env -i all the environment is gone, so no additional NIX_PATH entries either.
And furthermore, they are so wholly disjointed, that the channel:[syntax] is entirely foreign to nix-channel!!
~ $ nix-channel --add channel:nixos-24.11 nixpkgs
error: invalid channel URL 'channel:nixos-24.11'
Am I missing something?
I am absolutely confused by this reply, and your tone. If you believe
I’m trying to find a gotcha and… I don’t know what… That is your
prerogative.
What I’m doing, is asking questions about the support level for existing
features in Nix, since I am working on the assumption that these
deprecations are coming to Nix.
And I still believe you are missing an important point. You keep going
on about GitHub and tarballs, but this is irrelevant.
Did you know that the process that makes the
/nix(os|pkgs)-(unstable|\d{2}\.\d{2})(-small)?/ branches makes a
canonical tarball, which are the channel tarballs I am referring to?
~ $ curl --silent --location --head
https://nixos.org/channels/nixos-24.11/nixexprs.tar.xz | grep ^location:
location: https://channels.nixos.org/nixos-24.11/nixexprs.tar.xz
location:
https://releases.nixos.org/nixos/24.11/nixos-24.11.717703.5b35d248e920/nixexprs.tar.xz
There is no GitHub involved. Which is why I’m getting really confused at
your aggressive tone regarding somehow locking users into some GitHub
nonsense. I never once mentioned GitHub, or implied it was involved with
any form of “channels”.
The tarballs produced by GitHub are not canonical. Not only are they
not, they are less featured than the canonical channel tarballs from
channels.nixos.org. The build process attaches additional metadata,
like the command-not-found database, for example.
So maybe I’m not the only one missing something. 
Though from the first sentence, I guess I see what it is that I’m
missing. Maybe it’s not intended to reach upstream Nix? After all,
without flake references, and since nix-build already was hinted at
being soon deprecated, I guess that means you’re eschewing backward
compatibility with the currently only stable interface to evaluate Nix
expressions, like follows:
~ $ $(nix-build --no-out-link
'https://nixos.org/channels/nixos-24.11/nixexprs.tar.xz' -A hello)/bin/hello
Hello, world!
Right?
I think the post would have been much clearer if it actually stated that
the goal was to deprecate every non-Flake Nix expressions, rather than
confusingly make it about channels. I also believe you had the
opportunity to drop the <nixpkgs>-like references at the same time, it
would have been paired well with that deprecation notice. After all,
NIX_PATH references are often conflated with channels. It would have
made sense.
And finally, I guess that’s on me for not wanting to have an EEE happen
to the broader Nix ecosystem. I should have just shut up previously
rather than bring up concerns. It seems that made me the enemy. You’d be
surprised, but I do not want to see your company “go up in proverbial
flames”. Like most companies working on Nix stuff, I want it to be a
good collaborator in the broader Nix ecosystem. Which is why I’m
invested in these discussions. Even though I left participating as a
general member, I still fucking care about the broader Nix ecosystem and
NixOS. Like it or not, Determinate Systems is a notable actor in the
broader ecosystem, and one with a non-negligible notoriety.
Anything that is part of the Determinate Nix downstream distribution
invariably affects the ecosystem at large. Making breaking changes like
dropping support for stable Nix features means writing and supporting
Nix expressions becomes more cumbersome, if the the end-users end-up
using it.
Since I work with Nix at work, and I am a resident subject matter expert
(apparently), I need to keep tabs on what is happening, and I need
clarity on the support level to be expected.
I’ll be candid and honest: it is very tiring to write every message relating to Determinate Systems, walking on eggshells, fearing to be misinterpreted as a mindless hater, when I’m asking genuinely for precision about what is going on.
Before deprecating channels, nix path, and basically any non-flake, can you please make nix fast again first?
Whenever I prepare contributions to nixpkgs I use nix-build -A rather than nix build, because its about 10x faster, as it doesn’t have to copy 40 MiB of nixpkgs, of which only 5ish would be of interest, and also for some reason, classic nix is much faster when evaluating…
As much as I enjoy flakes for many things, I do not think they are the tool for most users.
Most users are fine with channels and their downsides. There is rarely a need for the purity and hermeticity flakes provide. And just for the locking, its far to “expensive” to use a flake.
The way how DetSys pushes flakes forward, is what poeple call “enshittyfication”…
FWIW, rather than nix-build or flake syntax, you can still do nix build -f . when working on nixpkgs, which is indeed how I have to do 99% of my nixpkgs development because flakes are completely unusable when you have to copy nixpkgs for every edit. Not only is it slow to do the copy, the resulting GCs down the line take forever when there’s 100 nixpkgs directories full of small files, which is a worst case scenario for any file system.
The reply this refers to seems to have been hidden. I for one want to see it.
The author deleted it since, we should respect that
I don’t feel strongly about it because it doesn’t happen often, but some forums I’m in have a rule that you can’t delete a post once it’s started a discussion because you have a responsibility to let the following posts to make sense, once people have gone to the trouble of replying to your points.
The original was deleted while the reply was being written