Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Home in Nix – dotfile management

hugoreeves.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Home in Nix – dotfile management

#11

Post by devhugo »

tyrion wrote: post #5

Nice post, thanks for sharing. I currently use vcsh and myrepos and they work great for me. Now that I switched to Nixos maybe I could give home-manager a try. I wrote about my approach here in case you are interested ( https://germano.dev/dotfiles/ )

Interesting. Home manager will enable you to manage your dotfiles. The more interesting proposition comes from Nix. I've absolutely loved using it in general and run NixOS by choice as my desktop OS. The great thing about using Nix and Home Manager to manage dotfiles is that your configuration is defined in a programming langauge. You have broad scope to control things based on whatever environment you are deploying the files to. It's a really powerful solution, it just takes a bit more time than some other dotfile systems. Give Home Manager a go if you have time to tinker, and if you have questions feel free to contact me through my email on my homepage.

Re: Home in Nix – dotfile management

#12

Post by oever »

the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

The documentation is not much aimed on a developer workflow.

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  {};

    stdenv.mkDerivation {
      name = "cv-env";
      buildInputs = [
        libxslt gnumake openjdk entr
      ];
    }

Re: Home in Nix – dotfile management

#13

Post by hrchak »

I have very similar setup https://github.com/dejanr/dotfiles it was inspired by https://github.com/peel/dotfiles and few other repositories.

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.

Re: Home in Nix – dotfile management

#14

Post by hrchak »

the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

That's missing the point of immutable reproducible builds i did something similar with arch and ansible long time ago. And it would end up in weird state quite often https://github.com/dejanr/archbox

Re: Home in Nix – dotfile management

#15

Post by devhugo »

the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

I migrated to this new setup slowly. First of all, I think separating things out from the main Nixpkgs repo is valuable, particularly for this whole new scope of user configuration. Based on what you've written I think you may be missing part of the power of home-manager. Worst case scenario, this is how I manage neovim, you can just write a file that sources a bunch of local files into the correct location on your computer. See https://github.com/HugoReeves/nix-home/tree/master/program/e... ```nix { config, lib, pkgs, ... }: { xdg.configFile."nvim/coc-settings.json".source = ./configs/coc-settings.json; xdg.configFile."nvim/fixers.vimrc".source = ./configs/fixers.vimrc; xdg.configFile."nvim/flags.vimrc".source = ./configs/flags.vimrc; xdg.configFile."nvim/general.vimrc".source = ./configs/general.vimrc; xdg.configFile."nvim/init.vimrc".source = ./configs/init.vimrc; xdg.configFile."nvim/init.vim".source = ./configs/init.vim; xdg.configFile."nvim/keys.vimrc".source = ./configs/keys.vimrc; xdg.configFile."nvim/lsp.vimrc".source = ./configs/lsp.vimrc; xdg.configFile."nvim/status-line.vimrc".source = ./configs/status-line.vimrc; xdg.configFile."nvim/themes.vimrc".source = ./configs/themes.vimrc; xdg.configFile."nvim/vista.vimrc".source = ./configs/vista.vimrc; } ``` So at worst it's an overly complicated way to source files into your home directories. However with the home-manager supported configuration it's much better in my opinion.

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.

Re: Home in Nix – dotfile management

#16

Post by the_duke »

oever wrote: post #12
the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

The documentation is not much aimed on a developer workflow. 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 {}; stdenv.mkDerivation { name = "cv-env"; buildInputs = [ libxslt gnumake openjdk…

I tried to do this, but I ran into way too many problems.

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.

Re: Home in Nix – dotfile management

#17

Post by microtonal »

the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

The mentioned home-manager is more of an awkward hack than a good solution in my view. Tt's not actually immutable, but just dumps down files into $HOME,

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
But it symlinks certain files from the store in the home directory, because some programs (e.g. shells) have hardcoded paths to configuration files.

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
There is plenty of documentation, but it is often incoherent, messy, missing important explanations,

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.

Re: Home in Nix – dotfile management

#18

Post by padthai »

devhugo wrote: post #10
trevorrr wrote: post #7

Would prefer GNU stow for simplicity. https://www.gnu.org/software/stow/

I've looked at and read about other's experiences with stow in the past. I'm uncertain about this so please correct me where I am wrong, but the issues I see with stow are: 1. It's somewhat dated/may have a tail of legacy features 2. I'm unsure of it's value beyond of what can be provided via the Git Bare Repo solution linked in the intro of my post. 3. More importantly, it's not a programmable solution where you can…

I use Stow, it is simple and only does a few things, but for a lot of users like me it is more than enough:

1. 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.

Re: Home in Nix – dotfile management

#19

Post by microtonal »

the_duke wrote: post #16
oever wrote: post #12

Earlier quoted context omitted.

The documentation is not much aimed on a developer workflow. 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 {}; stdenv.mkDerivation { name = "cv-env"; buildInputs = [ libxslt gnumake openjdk…

I tried to do this, but I ran into way too many problems. 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.

Each approach I tried failed because of some limitation that made the whole thing awkward or pointless.

Could you explain the limitations that you've run into? I have been using shell.nix + direnv + some caching for 1.5 years now and I have been very happy with it.

The only thing I disliked is that shell.nix is underspecified in the sense that it by default relies on your configured nixpkgs channel. So, I am now using niv to pin down nixpkgs and other package sets (mostly my own) to specific revisions. Once Nix flakes become mainline, this can be done easily without third-party tools.

Re: Home in Nix – dotfile management

#20

Post by emptysongglass »

the_duke wrote: post #8

I tried out Nix recently, with the intention of using it to get declarative management of my user account. 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…

I use Nix for declarative management of my user account using home-manager. I think you might be missing something.
Post reply on HN