6 ms·

Can someone please ELI5 flakes to me? Specifically: * What they add from vanilla Nix. * What they take away. * How they work. * Why channels are unnecessary

Can someone please ELI5 flakes to me? Specifically: * What they add from vanilla Nix. * What they take away. * How they work. * Why channels are unnecessary with flakes (once they're complete) as TFA implies. * How much they replace home-manager. * Why they add even more reproducibility. * Why else I should care about them. Other questions that might help me: Are they just adding the equivalent of lockfiles to vanilla Nix? If so, why is that such a hard transition? My initial impression on reading about Nix, and I've read a lot, is that Nix already had lockfiles. Context: not a Nix user, but I've read the Nix thesis, the NixOS thesis, a lot of the Tweag blog posts about flakes, a lot of the xeiaso.net posts about flakes, and a lot of the other posts listed in the Reddit link of a child of a sibling comment. Despite all of that reading, I don't get them. I have a hard time following regular Nix as it is, and if I start using Nix, I want to start with flakes.

JamesSwift 4y ago
I'm not knowledgeable enough to tackle all of those but for most of them they can be summed up as "they add more hermeticity/reproducibility to the system", and (my understanding) is that this is mostly due to how nix-channels work. Basically nix-channels is an environment variable NIX_PATH that works sort of like PATH, and is where your nix derivations would look when resolving references. So, for example, I could set my NIX_PATH to a private clone of the nix store and have my personal derivations there and builds I did would not be the same as on your machine where you point your NIX_PATH at the canonical upstream. Flakes require all of these dynamic parts of the build (including the build architecture etc) to be injected as inputs to the system. Similar to how Bazel workspace files work from what I understand. As part of that standardization of the inputs into a `flake.nix` / `flake.lock` file there was also work done to define a standard interface for a flake as a unit. Before flakes, if you imported another "unit" there was no telling what was being exported by the target (is it a derivation? an overlay?). With flakes there are well-known, enforced patterns on what and how you would expose to consumers. > How much they replace home-manager. Not at all really. But home-manager is now provided as a flake and so you no longer need to install it separately, and can instead import their flake to get a fully-working system. > Context: not a Nix user, but [...] To be honest, nix is a system you have to actually use to begin to understand and synthesize. As noted, flakes make this hill less steep, but you won't really internalize the value and the system as a whole until you actually start using it some.
- ghoward 4y ago
  Thank you for the explanation. I'm going to go back through everything I've read and see where it helps me. However, I just want to address one thing. > To be honest, nix is a system you have to actually use to begin to understand and synthesize. As noted, flakes make this hill less steep, but you won't really internalize the value and the system as a whole until you actually start using it some. This is discouraging me from trying Nix for a couple of reasons. Having read the thesis, understanding the necessity of reproducible builds and how Nix turns that up to 1100, and looking forward to being able to tell future contributors of my software to just run `nix-shell <whatever>` to set up my exact development environment, I think I understand the value of Nix pretty well. Being told that I don't understand it's value just because I don't use it feels a bit like condescension or elitism. You probably intended none of that, but that's what it felt like. Second, flakes have not made the hill less steep for me; they've made it more steep, simply because understanding wasn't there. Some things are harder for some people than others, including things that seem like they should be easy to anybody. Math is easy for Terence Tao in a way that it's not for me. But I bet you there is something I'm a natural at that he finds hard or impossible. Third, I agree, after all my study, that Nix is easier to understand once you use it. My trouble is that a package manager is a critical part of my system, and I don't want to run it until I do understand it. Standard package managers may be bad compared to Nix, no doubt about it, but they are understandable, which means I've been able to fix them when things go wrong. I have no such confidence that I could do that with Nix, so I haven't used it yet. It is unfortunate, but there are a myriad of reasons why people who know about Nix, and want to use it, haven't yet used it. Sometimes, the reason isn't because they don't understand the value of it. I don't like that I am not yet confident enough to use it, but that's my situation.
  - flurie 4y ago
    I like to think of the nix ecosystem as an Olympic-size pool. These pools caused me a great deal of stress when I was a child, not because I feared drowning, but because I felt like I could not fully understand their enormity. I learned to swim despite this fear, and what finally helped me get over the fear, more than my swimming ability, was focusing on my purpose or activity within the pool. It is easy to feel overwhelmed by the scope of everything within nix. So much of it is great. Many things aren't great at all. I do much better with it when I stop trying to take in the depth of it all and focus on the one small thing I want to do with it at any time. If there's something small and focused that you want to do with nix that elicits joy within you, I think it is good to dive in and learn enough to do that thing. I really like development environments as a focus, but that aligns with my personal and professional interest, and perhaps you want orthogonal systems or containers or application builds instead. There is something to the understanding that comes through experience, but it's not because it helps me realize the thing I can see in my head, but rather because it will sometimes reach out through the machine and slap me very hard in the face. I have been dealing with this issue[1] since it began. It is pervasive, and it is painful. But it helps me realize how fragile this ecosystem we work with is, and it gives me satisfaction knowing that I belong to a group that might happen to surface issues present in safety-critical systems through nothing more than ceaseless rigor. I hope you will join us at some point. I am confident that you will find it enriching. [1] https://github.com/NixOS/nixpkgs/issues/175875 https://github.com/NixOS/nixpkgs/issues/175875
rgoulter 4y ago
> What they add from vanilla Nix. Flakes add a couple of things: 1. They ensure the version of nixpkgs used is 'locked': In pre-flake Nix, working with nixpkgs involved using channels. The channel more/less was a clone of some git repository. But, what revision is checked out may vary from machine to machine, since the channels may be updated at different times. 2. Flakes provide a consistent entry point to Nix code. In pre-flake Nix, there were different conventions, but you'd have to know the contents of a file named "default.nix" to know how to work with it. With "flake.nix", the file follows a specific schema, and has a standard way of working with it. > What they take away. There's added restrictions on purity. IIRC, stuff like fetchUrl needs to specify the checksum when using flakes. > How they work. In pre-flake Nix, you'd need to have certain channels installed to use some expressions (or to use a tool like Niv to avoid using system channels). With flakes, pretty much once you've declared your inputs and declared the outputs of your nix code (what its packages, overlays, apps, etc. are), the Nix code used by the flake is otherwise the same. > Why channels are unnecessary with flakes (once they're complete) as TFA implies. Channels are an implicit per-user way that inputs are used in Nix code. Flakes need inputs to be declared. > Why else I should care about them. The CLI is much nicer. e.g. you can have "nix run github:<owner>/<repo>" and it fetches/builds/runs the repo, if it specifies a default app or default package. - Stuff like this is why I'd compare Nix to "like Docker, without containers". > Are they just adding the equivalent of lockfiles to vanilla Nix? If so, why is that such a hard transition? My initial impression on reading about Nix, and I've read a lot, is that Nix already had lockfiles. I think the tool Niv offered similar functionality as the input locking from Nix flakes. But, well, that's a community tool, and still doesn't imply a standard way of invoking a Nix file. There was a lot of fuss over the big Nix 2.4 release, which had many changes since Nix 2.3. Some of the frustration was that the Nix 2.4 release made breaking changes to non-flake stuff which worked in Nix 2.3. I used non-flake nix for some time before trying out flakes. I needn't have waited. It's initially a bit of boilerplate to copy-paste. But, I didn't have pain moving stuff to flakes, and flakes are neat.
- ghoward 4y ago
  This is a great answer, thank you. I think what hindered my understanding was the claim that Nix was purely functional, so it never made sense why flakes were needed. Knowing that Nix is not purely functional, i.e., that channels were still an implicit input, might be the missing piece for me.

JamesSwift 4y ago

I'm not knowledgeable enough to tackle all of those but for most of them they can be summed up as "they add more hermeticity/reproducibility to the system", and (my understanding) is that this is mostly due to how nix-channels work. Basically nix-channels is an environment variable NIX_PATH that works sort of like PATH, and is where your nix derivations would look when resolving references. So, for example, I could set my NIX_PATH to a private clone of the nix store and have my personal derivations there and builds I did would not be the same as on your machine where you point your NIX_PATH at the canonical upstream. Flakes require all of these dynamic parts of the build (including the build architecture etc) to be injected as inputs to the system. Similar to how Bazel workspace files work from what I understand. As part of that standardization of the inputs into a `flake.nix` / `flake.lock` file there was also work done to define a standard interface for a flake as a unit. Before flakes, if you imported another "unit" there was no telling what was being exported by the target (is it a derivation? an overlay?). With flakes there are well-known, enforced patterns on what and how you would expose to consumers. > How much they replace home-manager. Not at all really. But home-manager is now provided as a flake and so you no longer need to install it separately, and can instead import their flake to get a fully-working system. > Context: not a Nix user, but [...] To be honest, nix is a system you have to actually use to begin to understand and synthesize. As noted, flakes make this hill less steep, but you won't really internalize the value and the system as a whole until you actually start using it some.

ghoward 4y ago
Thank you for the explanation. I'm going to go back through everything I've read and see where it helps me. However, I just want to address one thing. > To be honest, nix is a system you have to actually use to begin to understand and synthesize. As noted, flakes make this hill less steep, but you won't really internalize the value and the system as a whole until you actually start using it some. This is discouraging me from trying Nix for a couple of reasons. Having read the thesis, understanding the necessity of reproducible builds and how Nix turns that up to 1100, and looking forward to being able to tell future contributors of my software to just run `nix-shell <whatever>` to set up my exact development environment, I think I understand the value of Nix pretty well. Being told that I don't understand it's value just because I don't use it feels a bit like condescension or elitism. You probably intended none of that, but that's what it felt like. Second, flakes have not made the hill less steep for me; they've made it more steep, simply because understanding wasn't there. Some things are harder for some people than others, including things that seem like they should be easy to anybody. Math is easy for Terence Tao in a way that it's not for me. But I bet you there is something I'm a natural at that he finds hard or impossible. Third, I agree, after all my study, that Nix is easier to understand once you use it. My trouble is that a package manager is a critical part of my system, and I don't want to run it until I do understand it. Standard package managers may be bad compared to Nix, no doubt about it, but they are understandable, which means I've been able to fix them when things go wrong. I have no such confidence that I could do that with Nix, so I haven't used it yet. It is unfortunate, but there are a myriad of reasons why people who know about Nix, and want to use it, haven't yet used it. Sometimes, the reason isn't because they don't understand the value of it. I don't like that I am not yet confident enough to use it, but that's my situation.
- flurie 4y ago
  I like to think of the nix ecosystem as an Olympic-size pool. These pools caused me a great deal of stress when I was a child, not because I feared drowning, but because I felt like I could not fully understand their enormity. I learned to swim despite this fear, and what finally helped me get over the fear, more than my swimming ability, was focusing on my purpose or activity within the pool. It is easy to feel overwhelmed by the scope of everything within nix. So much of it is great. Many things aren't great at all. I do much better with it when I stop trying to take in the depth of it all and focus on the one small thing I want to do with it at any time. If there's something small and focused that you want to do with nix that elicits joy within you, I think it is good to dive in and learn enough to do that thing. I really like development environments as a focus, but that aligns with my personal and professional interest, and perhaps you want orthogonal systems or containers or application builds instead. There is something to the understanding that comes through experience, but it's not because it helps me realize the thing I can see in my head, but rather because it will sometimes reach out through the machine and slap me very hard in the face. I have been dealing with this issue[1] since it began. It is pervasive, and it is painful. But it helps me realize how fragile this ecosystem we work with is, and it gives me satisfaction knowing that I belong to a group that might happen to surface issues present in safety-critical systems through nothing more than ceaseless rigor. I hope you will join us at some point. I am confident that you will find it enriching. [1] https://github.com/NixOS/nixpkgs/issues/175875 https://github.com/NixOS/nixpkgs/issues/175875

rgoulter 4y ago

> What they add from vanilla Nix. Flakes add a couple of things: 1. They ensure the version of nixpkgs used is 'locked': In pre-flake Nix, working with nixpkgs involved using channels. The channel more/less was a clone of some git repository. But, what revision is checked out may vary from machine to machine, since the channels may be updated at different times. 2. Flakes provide a consistent entry point to Nix code. In pre-flake Nix, there were different conventions, but you'd have to know the contents of a file named "default.nix" to know how to work with it. With "flake.nix", the file follows a specific schema, and has a standard way of working with it. > What they take away. There's added restrictions on purity. IIRC, stuff like fetchUrl needs to specify the checksum when using flakes. > How they work. In pre-flake Nix, you'd need to have certain channels installed to use some expressions (or to use a tool like Niv to avoid using system channels). With flakes, pretty much once you've declared your inputs and declared the outputs of your nix code (what its packages, overlays, apps, etc. are), the Nix code used by the flake is otherwise the same. > Why channels are unnecessary with flakes (once they're complete) as TFA implies. Channels are an implicit per-user way that inputs are used in Nix code. Flakes need inputs to be declared. > Why else I should care about them. The CLI is much nicer. e.g. you can have "nix run github:<owner>/<repo>" and it fetches/builds/runs the repo, if it specifies a default app or default package. - Stuff like this is why I'd compare Nix to "like Docker, without containers". > Are they just adding the equivalent of lockfiles to vanilla Nix? If so, why is that such a hard transition? My initial impression on reading about Nix, and I've read a lot, is that Nix already had lockfiles. I think the tool Niv offered similar functionality as the input locking from Nix flakes. But, well, that's a community tool, and still doesn't imply a standard way of invoking a Nix file. There was a lot of fuss over the big Nix 2.4 release, which had many changes since Nix 2.3. Some of the frustration was that the Nix 2.4 release made breaking changes to non-flake stuff which worked in Nix 2.3. I used non-flake nix for some time before trying out flakes. I needn't have waited. It's initially a bit of boilerplate to copy-paste. But, I didn't have pain moving stuff to flakes, and flakes are neat.

ghoward 4y ago
This is a great answer, thank you. I think what hindered my understanding was the claim that Nix was purely functional, so it never made sense why flakes were needed. Knowing that Nix is not purely functional, i.e., that channels were still an implicit input, might be the missing piece for me.