1. 35
    1. 1

      I wonder exactly what I’m missing by not using flakes in this circumstance. I have plenty of factored-out NixOS modules, but no flakes.

      1. 5

        Flakes clearly identify your inputs from outside not xpkgs, the data flow is easier to reason about. They also make pinning and updating inputs much easier with the lock file. It’s mostly about ergonomics. You could do all of them things a flake does yourself just not as easily.

      2. 2

        A bit more of a concrete example. Before flakes were a thing, I had a module for connecting to a VPN. After moving my system into a flake, I moved this module into its own flake. That forced me to tighten up the code, due to the flake purity, and led to me finding a couple of bugs in my module (and one in Nix). That module is up on a git repo now and I believe that two other whole people may be using it.

        I could have done all this cleaning without flakes. I also could have submitted this module to the main Nix package repo (though I’m not entirely sure if it could be accepted - I don’t know the full rules on adding modules for connecting to third party commercial services). However, I didn’t, because not doing these things was easier. With flakes, sharing and fixing was easier than leaving things the way they were.

      3. 2

        I like that I can roll back nixpkgs just by reverting my flake.lock. You can also use an ordinary git repo as an input, which is useful for when you want to work with software that isn’t in nixpkgs. Instead of having to manually tweak the git hash, just nix flake --update whatever (or whatever the command is) and go.

      4. 1

        My fuzzy understanding is that the specific versions of a package selected in each flake can be different? But I think I’m completely misunderstanding something every time I think that