Why Home-manager and Flakes?

Hey i am fairly new to NixOS, pretty much just started. Got a few Years of Experience with Manjaro and Debian and i was just amazed when i first learned of the Nix Concept. How good it is…and wondering why i never heard of it. I always hated the dependency struggle and “find the right configuration hell”. The Fact that i have one File to Declare my whole system is awesome and got me hooked right away.


one of the first things in the Official Documentation is the Home-Manager (in fact, a lot of guides are specific to HM) But it does require another config File. Then you Learn about flakes…which requires another config File… So far i try to avoid both of those, but i feel like that is not really sustainable

am i missing Something here? We went from one Configuration File to 3-4 entirely different ways to manage the System (4 including nix-env -i, which i do not get at all tbh)

To me…so far… it feels like this is like the greatest idea of managing a Development System…turning into trying to make something/a bit for everybody… which makes it kinda awful again

I Don’t want to Piss anyone off or anything like that. I just do not understand the thought process here.

Anyone care to enlighten me?

Have a nice Day everyone :heavy_heart_exclamation:

*P.S dang it…this is most likely the wrong thread…apologies for that

home manager allows you to specify user specific configurations using the module system developed for NixOS. you can use it in your configuration.nix file importing it as a module itself: Home Manager Manual

As far as I know, Flakes aimed to solve everything, but I am not sure if it succeeded. Here is a good article on flakes: Flakes aren't real and cannot hurt you: a guide to using Nix flakes the non-flake way - jade's www site

If you like you can ignore Flakes for system configurations. You can use niv or npins for lock files. If you feel unhappy to rely on the state of channels you can follow sanix pattern, but this leads also to more then one file for describing the system.

but you can also take your time and just stick with the current default that is to use a simple configuration file.


Had a feeling like this should be possible xD but did not stumble across it.

I feel like i will need to use flakes for my use-cases. But you have given me a lot of context and things to dive into. That should help me get along and did clarify some of my puzzled thoughts.

Thanks! I really appreciate the effort :slight_smile:

Hi, and thanks a lot for the feedback. Constructive criticism should certainly not make anyone angry. In fact we need more of that to make sure we’re on the right track when trying to improve things.

I’d like to know where exactly you found that. nix.dev is as official as it gets for Nix documentation, and there we didn’t even get to write about Home Manager yet.

The reason you may find there are too many entry points is that indeed there are. But that’s for historical reasons, since many components we’d now consider essential to the ecosystem were and still are developed without much coordination and with very limited means. There are ways to make sense of it all in a unified way. Flakes were intended for that and are one way, and @infinisil’s sanix is one way. But there is no “blessed” pattern — I assume because the effort to find and agree on one was beyond our collective available capacities.

1 Like

Hey there!

Home Manager

Whether you want or need Home Manager is entirely up to you; it is completely optional. I don’t see much benefit for myself right now, so I don’t use it either.


You might have a look at these two videos which, in my opinion, explain their purpose quite well: namely 1) improving reproducibility and 2) making software more easily and in a more standardized way available. To summarize the first point, per default Nix pulls all software from channels in order to realize your declared configuration. That means the same configuration file can result in different systems depending on the available software of the channel at any given moment in time. Flakes solve that by locking the precise versions. Their basic concept is actually quite simple.

What it means to install software with Nix

Put simply, whenever you install software in NixOS (regardless of the method used) it gets copied to a unique subfolder in the Nix Store (which is just your local directory /nix/store) and made available to you via so-called Profiles or user environments: you only “see” the applications that are in your default Profile (or that are declared system-wide in the list environment.systemPackages of your configuration.nix). A nice explanation can be found in the Nix Reference Manual, entry “Profiles”.

Or in the description of nix-env of the Nix Reference Manual: “The command nix-env is used to manipulate Nix user environments. User environments are sets of software packages available to a user at some point in time. In other words, they are a synthesised view of the programs available in the Nix store. There may be many user environments: different users can have different environments, and individual users can switch between different environments.”

So, Profiles (or user environments) are basically a bunch of symlinks to different objects in the Nix Store that define which software is available to you. That means, if you use nix-env -iA <insert_app_name_here> or even something like

nix run nixpkgs#cowsay hello world

it gets thrown into the Nix Store along all the other software, but is added only to your current user profile (and can’t be accessed by someone else unless they also decide to install it - in which case a symlink to the already available copy is added to their profile as well, so that you don’t have to worry about having the same software twice). If you “uninstall” a specific application, its symlink is removed from your Profile but it still remains in the Nix Store unless you also do a “garbage collection” (GC). Note that profiles act as so-called GC roots: put simply, everything in the Nix Store which is referenced by a link from outside the Store is protected from being garbage-collected. And everytime you install or remove a package a new “generation” of that profile is generated. You can see your profiles in ~/.local/state/nix/profiles.

If you’re interested in how profiles, the Nix Store and the linking system actually works, I highly recommend watching part of the video “Everyday Use of GNU Guix” (minutes 23 to 37) by Chris Marusich on YouTube. Nix works similar to Guix in this regard. (But the given commands differ.)


You are right. the official documentation does not mention Home-Manager, that is on me. I went through my History but i could not Reproduce this. My best guess at the time is that i got confused by the entry’s like Zsh in nixos.wiki which does link to how to install zsh in /etc/nixos/configuration.nix but then states " Zsh can be configured with Home Manager." As far as i can tell tough, the Configuration works the same in the regular configuration.nix. The right shell Shell is one of the first things i tend to do. So its one of the first things i saw, but is is not official documentation.

Also there is the entry users.users.<username> which allows you to specify Software for a specific user. To me it felt like Home-Manager was more like an Option for Nix standalone. But it’s a lot to take in so i am probably wrong on a lot of things. Just started my Journey in Nix 2 days ago

There is a lot of Documentation and Tutorials :sweat_smile: which is a good AND a bad thing. Some of it seem outdated or incomplete. The ones i started with:

nix 4 Noobs
NixOs wiki
nix tutorial on gitlab
A tour of Nix
Reference Manual
Probably also duo to the fact that there is Nix and NixOS

is kinda overwhelming. Especially considering there are multiple ways to get going…

But it’s an absolute miracle that such an OS even Exists. I Instantly fell in Love :heart:
And it makes a lot of sense given the Context you provided and the Fact that this Project is running for a long time now (Holy shit, this exists…since 2002??) with less attention than it deserves.

I am very grateful for the Replies, that’s actually very helpful. This seems to be a really nice community.

Thanks for all the Hard Work you put into this amazing Software


I have read that before but as far as i understand i can specify a version with nix-shell -p python310
For me so far a simple shell script reading

#!/usr/bin/env zsh
nix-shell -p python310

or using smt. like this syntax

#! nix-shell -p bash python310

would do the Trick of having the version of python running that i want to. Wouldn’t the channel i have be irrelevant as long as it provides the version i need?
To me (as someone with little to no knowledge) That feels like overengineering the Problem. I though flakes where mainly for Software that is not available in the Nix Pkgs :thinking: i was hoping to get Mojo running with flakes at some Point :sweat_smile:

But i will watch the Videos and read the reference you Provided, always happy to be proven wrong. :grin:

I think i at least understand the basics of the atomic approach and the storage system but nix-env -i just feels like the “wrong”(opposite) way of installing Software in a Declarative manner. More analogous to pacman -S or apt install. I can see why that would Exists

But when you learn about NixOs it just feels like, yet another way to install Software, and on Top of that one that defeats the purpose.
Again…just the perspective of someone new to all this. :man_shrugging:. I am the one not getting it xD

Very in deep Explanation! Thanks a lot!

Yes, but if you use channels, an unfortunate nix-channel --update (or a copying of your configuration to a system that has different channels to begin with) could remove python310, at which point your script will no longer work.

The python310 there also refers to a specific python 3.10, built with a specific gcc and dependency versions. Updating your channels can move any of those dependencies, thereby making a subtly different python 3.10 (note the commits differ), even if the version number is the same. Updating might even result in patches being applied, or a minor version change, which will have more clear changes.

This is also only specifically available for python, and a small handful of other packages where having multiple versions is often necessary. The 310 suffix basically makes python310 a completely different package from python, and not all packages need to (or should!) be duplicated like that.

In practice, you personally probably won’t notice the difference 99% of the time, but nix focuses on reproducibility, so we set out to nearly guarantee successful resolution of your code - and with traditional nix use, we were close but not quite there.

Flakes exist to solve that problem, and as an average end user that’s going to be their primary use case for you, alongside some improved UX. There are indeed other solutions, but at this point you might as well use flakes, it’s where the ecosystem is going - despite the dissent caused by drama around how they were proposed (there are valid criticisms, and the whole topic is a bit toxic for various reasons, no need to rehash that all here, feel free to search this discourse if you’re interested).

But yeah, if it’s a bit overwhelming for now, stick to channels until you’re comfortable, and earmark flakes for a future exploration. Most of the official docs are not adapted to flakes yet, and I personally doubt we’ll see much movement on that front before another 5 years have passed.

For when you do want to try out flakes, I’ve heard good things about this book, it also goes over the motivations for using flakes and even covers home-manager: Introduction to Flakes | NixOS & Flakes Book


I hear you and you are right about that. For some context, my colleagues used to work in Windows or MacOS. So interoperability is not something i am that used to :joy: For me personally that still feels like over-engineering the Problem. Just Nix, is already 20x better than anything else i came across, even seems to work in Windows via WSL.

Just to give a Fresh Perspective on all of this i want to cite the Book that you mentioned:

A Word of Caution about Flakes

The benefits of Flakes are evident, and the entire NixOS community has embraced it wholeheartedly. Currently, more than half of the users utilize Flakes[3], providing assurance that Flakes will not be deprecated.

This Sentence, is a contradiction. “the entire NixOS community” and “half the user” are mutually exclusive Groups. This also sounds a bit like the To Big to Fail argument. I did read some (not all) of the Threads relating to the Problem you have mentioned. And all of this starts to feel like the Sunk cost Fallacy.

This is just my perspective and to be very clear: I will still use NixOS and Probably also adopt flakes, because i Love tinkering. But the Reason stuff like the iPhone are so successful despite their lack of Configuration Options. Is that, tinkering is not what the most people want to do, even most Developers. (one could also refer to Gnome or VSCode)

For me this Topic is resolved, because i (think i) do understand now why things are the way they are. And at this point i am not competently enough to contribute anything new. Looks like i have a lot of reading to do :sweat_smile:

Much Love and appreciation for anyone working to make this awesome Software :heart:
And Thank you all again for the insights you have provided me with. :hugs:


It works on any distro you want and since WSL2 is basically just a Hyper-V VM of a given distro it should work just fine.
WSL is another reason to use home-manager btw. I use it so that I can use my Nix environment on my work Ubuntu WSL.
It’s really nice to have all my systems in sync like this.

As for one file for everything, except for the additionial lock file you can have just one file with flakes or sanix as well.
Nothing really prevents you from doing that.
However it quickly can get messy depending on how many lines of code you got.
For example just the Nix code in my systems config is 5588 lines of code.
Having all of that in a single file would be quite unwieldy, therefore many people split there config into multiple files.