> As you can see, it uses our ./configuration.nix as a module. What are modules again? Per NixOS wiki:
> > Modules are files combined by NixOS to produce the full system configuration. A module contains a Nix expression. It declares options for other modules to define (give a value). It processes them and defines options declared in other modules.
I think the quoted documentation is not well written. Modules may be simple, but this description is certainly not. It reads like someone wrote a longer, more complicated but detailed sentence, and then in an effort to improve it, clipped it down in a very “lossy” way into shorter, punchier statements.
Nix has volumes of half useful documentation like this.
Suggestion for the author: the “why use it” discussion deserves it own heading. As I write this, that content is situated in the “What is Home Manager” section.
I want to setup my configs using Nix and Home Manager but I just find it so confusing and not very user friendly. Every guide I’ve seen is either a really basic case of setting up a single package and config or an extremely complicated setup using Flakes that I can’t wrap my head around.
This guide I feel like falls more into the former, it gives you a really basic example but isn’t enough to go off for me.
Drake's book looks great. I appreciate his efforts to create a mental model and learning approach to NixOS.
I found a set of tutorials on YouTube by Will, to be incredibly helpful at the beginning of my NixOS journey. Even though these tutorials are a couple of years old, they should have aged well.
Drake's book, should help confirm some assumptions I've made about how NixOS works. Given NixOS's declarative nature, I find it easy to copy configurations to do what I want - a handy approach when pressed for time, but it does leave some gaps in understanding that need to be filled.
I think it is wise to use Nix for a bit before trying to manage all your user configs with it. Using `nix-shell` for project dependencies is a good starting point. You can't really make any costly mistakes here since the scope of any given project is likely much less than all your system and user configurations.
Nix shell plus something like direnv using flakes or nix expressions (non-flake approach) would give you a chance to learn the language and ecosystem. Once you feel comfortable with this, home-manager should be much more approachable.
> If you happen to have a necessity for such a thing, you're better off using Home Manager, else you would end up implementing parts of Home Manager by yourself.
So if I need to do X then I should use Y, but why do I need to do X?
I use NixOS daily as well, I installed home-manager as part of my initial configuration and have basically just ended up using configuration.nix in a git repo for everything anyways since I'm the only user. It feels like a good idea in theory, but I don't think it's actually that useful for most
With flakes it seems a lot easier to understand where all the parts are coming from. You give it git repo urls and it gives you a workable package. If you want to use a branch, or unstable, or whatever, it’s right there in the flake. Also, input and output are clearly marked.
It’s not doing anything new, really, but as a stand-alone unit it seems easier to wrap my head around.
In my experience, it’s easier to understand everything as a single project with the mind map of flakes. Although it is as you mentioned that a lot of complexity is hidden and can bit you in the ass, like home manager not (necessarily) using the systemwide nixpkgs, yet as a beginners it feels easier to grasp how everything is one big derivation and your home manager config is only a dependency of this derivation.
I've been using flakes exclusively for project dependencies, not for system config. I've been doing this for a year or so but I still feel like a newbie.
What I like about flakes is that they (appear to) let you hide complexity.
I haven't seen this happen in a real community yet, but one could imagine JimBob's flake for foo-type work. JimBob has put a lot of thought into which tools you need and has his flake up on github for other foo-workers to use. JimBob is kind of a big deal in the foo community.
Then you've got Susie, who has been using JimBob's flake, but she doesn't really know all of its ins-and-outs. Eventually she needs something extra, because she specializes in bar (a subset of foo). With flakes, if I understand them, she can use JimBob's flake as an input, add the piece she needs, ad publish her own JimBob-with-Susies-tweaks flake.
In this way you can sort of imagine a constellation of flakes (I've been imagining the nix snowflake as a nix flake with three inputs and three outputs) which represent the various needs of the community that's using them.
In a config without flakes, my feeling is that there are fewer boundaries, so you have to keep more in your head about what's already in place. If you've enabled a service in /etc/nix/nix.conf and you're using home manager as a module, you can't disable it there because the values will conflict.
Granted, I don't actually know what a system configure with flakes looks like, but I hope it lets me compose flakes in a way that mirrors what JimBob and Susie are doing. I want to log in and say:
> give me base_system -> my_print_drivers -> image_tools
...and those flakes will compose so that I can use gimp and print photos. But since `my_printer_drivers` is a flake, I can also reference it from a different machine like:
> give me other_base_system -> my_print_drivers -> document_tools
This is unlikely, but let's suppose my printer is super fancy and can print in silver and gold ink, but in order to make this work the image tools flake has to change something about the printer driver. In a "flat" system config you're going to get a conflict, right? my_print_drivers to be one way, image_tools wants it to be another way, so you're going to have to sort that out.
But flakes are portable and composable in a way that lets you ignore the big picture and just focus on what you need. If you take something as an input and make an output where that thing is changed... it's changed. You can get away with ignoring more.
Of course that's the real question. can you get away with ignoring that much? I hope so.
> As you can see, it uses our ./configuration.nix as a module. What are modules again? Per NixOS wiki:
> > Modules are files combined by NixOS to produce the full system configuration. A module contains a Nix expression. It declares options for other modules to define (give a value). It processes them and defines options declared in other modules.
> Simple as.
If only.
Also, the article is very much a How not a Why.