News for hackers. Stuff that matters.
Re:Home in Nix – dotfile management by oever on Friday January 10, 2020 @05:09AM (#22009881)
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 <nixpkgs> {};

    stdenv.mkDerivation {
      name = "cv-env";
      buildInputs = [
        libxslt gnumake openjdk entr
      ];
    }
Re:Home in Nix – dotfile management by the_duke on Friday January 10, 2020 @05:27AM (#22009973)
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 by danieldk on Friday January 10, 2020 @05:40AM (#22010034)
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 by lidHanteyk on Friday January 10, 2020 @06:37AM (#22010273)
I do this. When I run into problems with a shell.nix, I fix the underlying project, or abandon it. Nix is ruthless but being ruthless is required in the face of the task of taming decades of terrible software.