I discovered too late that Nix basically has no support for this.
While NixOS has some very nice features for declarative setup, user environment management boils down to terminal commands for "install package X, remove package Y".
The mentioned home-manager seems more of an awkward hack than a good solution in my view. It builds up a parallel package repository that you have to use besides the actual packages, and requires a lot of additional work if you want to customize something.
In my understanding (possibly incorrent?) it is also not actually immutable, but just dumps down files into $HOME, losing the most interesting aspect of Nix.
In the end I ditched it and stuck to my Ansible setup.
Nix is a great approach, and definitely worth a look, if you can stomach the other downsides (see below). But right now I would only recommend it for deterministic server builds or isolated dev environments, not for managing you main setup.
* Problems:
- There is plenty of documentation, but it is often incoherent, messy, missing important explanations, and it is generally very awkward to get a good insight and understanding of how all the parts fit together.
- The language... it is full of confusing oddities; clearly something that has grown peace by piece. Switching to something more coherent like Gluon (also functional, https://github.com/gluon-lang/gluon) would seem like a better approach to me.
- Packages: The quality can be very hit and miss. I discovered several that are written poorly. Plenty are also outdated/unmaintained. But: considering the niche nature of Nix, the amount of packages is actually quite impressive.
I can't comment directly on home manager, and I have had to put a lot of work into adopting Nix, but FWIW I'm happily using it to manage my NixOS desktop at home (since early 2018; my first daily-driver Linux system) and my macbook (since late 2018--though, caution: Nix hasn't really settled into Catalina yet).
Not quite sure how to express it. I guess the ecosystem isn't yet a full-throated embodiment of its own vision for computing. But, if you buy into the vision enough to sweat a little for it, it is livable.
That's actually not true. Each home-manager generation is immutable and in the Nix store. E.g., the last two generations on my MacBook:
home-manager generations | head -n2
2019-12-23 12:05 : id 12 -> /nix/store/6rig5ip0swmnnfcvgm221n5lig3xsh18-home-manager-generation
2019-12-12 12:40 : id 11 -> /nix/store/8as4k5x7i5bhf3wjvlcczhx8w2680k46-home-manager-generation
losing the most interesting aspect of Nix
Similarly to the declarative NixOS configuration, you can switch between home-manager generations, etc. It's a purely declarative configuration.
It also basically builds up a parallel package repository that you have to use besides the actual packages,
What do you mean by this? home-manager also uses the Nix store. E.g., my home-manager configuration contains ripgrep in the declarative package configuration:
$ realpath $(which rg)
/nix/store/hww0h39bs56hp17ynxcjrk0imgqill07-ripgrep-11.0.2/bin/rg
I fully agree! Often one has to read derivations in nixpkgs to understand how things are done.
The language... It is full of oddities and basically a mess
I disagree. I didn't like it when I started using Nix and seriously looked at Guix because it used scheme. Now, 1.5 year later, I like Nix as a language. It's just a small, functional language.
---
I think the biggest barrier of the Nix ecosystem is that you can't really use NixOS or Nix in a meaningful way without also learning the Nix language and some of the intricacies of writing derivations. So, you are pretty much all-in or it will be a frustrating experience. So, I understand your point about only using NixOS on reproducible servers. I also use NixOS on my desktop (and love it), but admittedly, it's only doable when you invest enough time to learn things.
If someone wants an immutable system with transactional installs and updates, Fedora Silverblue is probably a much easier entry-point, because you do not really have to understand OSTree et al. to use it.
If nixos used a different language (e.g. gluon), do you think you would have become more comfortable quicker?
The `shell.nix` files make it easy to place the environment setup in your repository. The file contains the list of packages that you need and you can make these packages available in just one shell by calling `nix-shell`.
Here's an example of a `shell.nix` file:
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "cv-env";
buildInputs = [
libxslt gnumake openjdk entr
];
}Each approach I tried failed because of some limitation that made the whole thing awkward or pointless. (like symlinking immutable config files into $HOME)
This admittedly might have been exacerbated by my shallow understanding.
For your own workstation- what OS?
Have you got these in github or somewhere i could take a look?
In regards to the problems. 1. I totally agree. Everyone using Nix has seen this as an issue for a while, and I'm not entirely sure how it can be fixed in the near term. I would say that Nix is for people who love to tinker and enjoy spending time on this sort of thing. If that's you, go to the riot chat or the subreddit and ask questions there. r/nixos 2. Haven't seen gluon before, interesting. Nix is functional which is key and it's focus as a configuration language offers it some great advantages when used for configuration. I believe a gluon is not feasible as it's not functional. The Nix team seems open to changing parts of the language to improve it, they are looking at removing the special url syntax for example. 3. No comment. I haven't really looked at this space. Nixpkgs if that is what you are referring to is pretty well maintained, particularly for the configuration-less executables.
More details here [1].
[~/code/dotfiles]$ tree -a -R -L 2
├── aws
│ └── .aws
├── git
│ ├── .gitconfig
│ └── .gitignore_global
├── .gitignore
├── .gitmodules
├── gpg
│ └── .gnupg
├── README
├── ssh
│ └── .ssh
├── tmux
│ ├── .tmux
│ └── .tmux.conf
├── vim
│ ├── .viminfo
│ └── .vimrc
└── zsh
├── .oh-my-zsh
└── .zshrc
$cd ~/code/dotfiles
$ stow -t $HOME git
.gitconfig -> code/dotfiles/git/.gitconfig1. Probably it will not receive more features any time soon.
2. You can have several configurations and mix them, also it makes very easy to adopt changes from the current system and/or rollback changes.
3. No, it is not programmable, but you can have several folder for different systems and configurations. I for example have a folder called unix for all *nix systems, other called x11 for x11 programs, darwin for macOS, etc. You could do the same with roles.
If you want really fine grained control over machine/user/role, it is not enough, and it does not take into account package managing at all.
I use a mix of Stow/Ansible for Desktops and HashiCorp/Ansible for the `cattle`. Nix is more powerful than my setting, but I still need to evaluate if it is flexible enough for the orgs I work with.
I wrote about my approach here in case you are interested ( https://germano.dev/dotfiles/ )
Also i still symlink some stuff like stow is doing, but with few shell scripts. The main difference is that my dotfiles are not start with '.'.
Idea is to move everything to nix, so that when you rollback, you rollback your dotfiles as well.
What i wish maybe, is that i used home manager but that some future focus.