In the most basic, practical sense, flakes solve the standardization and pinpointing of two things: inputs, previously solved by things like niv, and outputs, making nix structures more standard and better able to coexist. Things like overlays, package outputs, nixos configurations, and even flake templates themselves all follow the same structure.
The result of all this is that, when I look at a non-flake repository, I may have to spend some time looking around to see what it does at a high level, and it may have its own special method of installation that usually begins with
this = import (builtins.fetchTarball "https://...")
You can start by converting any of the things I listed to flakes, and there is a module called flake-compat designed to provide backward compatibility for non-flakes. The Serokell guide is very helpful for this as well.
I'm not sure what the ~deciders would say, but experimental here means something like "opt-in public beta."
Maybe you're drawing a distinction I'm missing, but it doesn't strike me as that weird to note experimental features when the goal is to entice adventurous users to put them through the paces.
Is the question more like, "why is there a release if flakes aren't ready?" In that case, yes, I think the release is more pragmatic than semantic. You can read a little more in https://discourse.nixos.org/t/nix-release-schedule-and-roadm..., but basically the release cycle stretched out long enough for a lot of backport friction to build up. To give one big example: the documentation had been converted to markdown in master, but not in 2.3-maintenance--backporting anything with documentation updates also meant re-writing the documentation changes back into docbook.
Hmm. This isn't something I'm doing terribly consciously, so I'm not sure if this will make sense:
~literally, it means something like "approximately".
It would obviously break the sentence if it literally meant "I'm not sure what the approximately deciders would say", so in this case I'm using it more to indicate some uncertainty about the term--that the word-choice is an approximation.
I'm not sure if this use is ~common or me-idiomatic.
Nix 2.4 is the first Nix release to include the flakes feature, so this is the first chance for Nix users who don't want to run cuts right off the Nix master branch to see what flakes are like, experiment with them, and give feedback.
(Previously, to use flakes you'd be running a bleeding edge build of Nix itself as well.)
This is a pretty big deal, since flakes bring a new level of determinism to `nix` as you might use it at the CLI, and other built-in Nix tools like `nixos-rebuild`, making it ‘easy’ to pin Nixpkgs and other package sources in your configs. The greater determinism (‘pure evaluation by default’, in Nix lingo) also improves performance, because it provides the Nix language evaluator with more caching opportunities.
Flakes are still contentious in some ways inside the community, and the outputs schema of flake.nix files themselves is also kinda verbose (imo), so use of helper libraries to generate outputs is pretty common. My hope as a Nix user is that this release means we can overcome both of those issues in the next year or two and make some solution for deterministic evaluation by default official in the next year or two.
Wow so many gems in here that I’ve been waiting for (though some still experimental).
- better cli (previously was a myriad of shell scripts you’d just had to memorize, and would do the non-typical thing by default if you didn’t pass many arguments)
- flakes (will make nix more nix. Currently we need checkouts of entire nixpkgs to run two versions of the same software alongside, it is my understanding that with flakes this will become more easy and lightweight to pull off)
- markdown docs
This last one shouldn’t be understated I feel. Docs have always been a pain point with Nix to the point where insiders joke about it with an affection almost. I feel due to many core contributors having academic backgrounds and the generally steeper learning curve with Nix, they have been susceptible to embrace “quantifiably superior documentation formats”, blindspotting the effects of markdown being the lingua franca lowering the barrier to entry for people contributing fixes by so much—perhaps because this is less easy to quantify, and perhaps less easy to appreciate for folks that were okay to learn Nix in its current state the first place.
Anyway, thanks everyone for putting in the hard work, this will pave the way to a bright future for Nix I am sure.
12 comments
[ 4.1 ms ] story [ 43.9 ms ] threadI switched to them exclusively (removed all nix channels) and haven't had any troubles yet.
- What problem(s) they will solve for me
- How I should go about using them to solve the above problems.
In the most basic, practical sense, flakes solve the standardization and pinpointing of two things: inputs, previously solved by things like niv, and outputs, making nix structures more standard and better able to coexist. Things like overlays, package outputs, nixos configurations, and even flake templates themselves all follow the same structure.
The result of all this is that, when I look at a non-flake repository, I may have to spend some time looking around to see what it does at a high level, and it may have its own special method of installation that usually begins with
You can start by converting any of the things I listed to flakes, and there is a module called flake-compat designed to provide backward compatibility for non-flakes. The Serokell guide is very helpful for this as well.Maybe you're drawing a distinction I'm missing, but it doesn't strike me as that weird to note experimental features when the goal is to entice adventurous users to put them through the paces.
Is the question more like, "why is there a release if flakes aren't ready?" In that case, yes, I think the release is more pragmatic than semantic. You can read a little more in https://discourse.nixos.org/t/nix-release-schedule-and-roadm..., but basically the release cycle stretched out long enough for a lot of backport friction to build up. To give one big example: the documentation had been converted to markdown in master, but not in 2.3-maintenance--backporting anything with documentation updates also meant re-writing the documentation changes back into docbook.
~literally, it means something like "approximately".
It would obviously break the sentence if it literally meant "I'm not sure what the approximately deciders would say", so in this case I'm using it more to indicate some uncertainty about the term--that the word-choice is an approximation.
I'm not sure if this use is ~common or me-idiomatic.
(Previously, to use flakes you'd be running a bleeding edge build of Nix itself as well.)
This is a pretty big deal, since flakes bring a new level of determinism to `nix` as you might use it at the CLI, and other built-in Nix tools like `nixos-rebuild`, making it ‘easy’ to pin Nixpkgs and other package sources in your configs. The greater determinism (‘pure evaluation by default’, in Nix lingo) also improves performance, because it provides the Nix language evaluator with more caching opportunities.
Flakes are still contentious in some ways inside the community, and the outputs schema of flake.nix files themselves is also kinda verbose (imo), so use of helper libraries to generate outputs is pretty common. My hope as a Nix user is that this release means we can overcome both of those issues in the next year or two and make some solution for deterministic evaluation by default official in the next year or two.
- better cli (previously was a myriad of shell scripts you’d just had to memorize, and would do the non-typical thing by default if you didn’t pass many arguments)
- flakes (will make nix more nix. Currently we need checkouts of entire nixpkgs to run two versions of the same software alongside, it is my understanding that with flakes this will become more easy and lightweight to pull off)
- markdown docs
This last one shouldn’t be understated I feel. Docs have always been a pain point with Nix to the point where insiders joke about it with an affection almost. I feel due to many core contributors having academic backgrounds and the generally steeper learning curve with Nix, they have been susceptible to embrace “quantifiably superior documentation formats”, blindspotting the effects of markdown being the lingua franca lowering the barrier to entry for people contributing fixes by so much—perhaps because this is less easy to quantify, and perhaps less easy to appreciate for folks that were okay to learn Nix in its current state the first place.
Anyway, thanks everyone for putting in the hard work, this will pave the way to a bright future for Nix I am sure.