1. 63
  1. 4

    Thanks, nixpkgs.lib.genAttrs supportedSystems; looks very useful. I’ve used numtide’s flake-utils to accomplish a similar type of thing.

    1. 4

      This is great, the first time in a while that I read something about Nix and come out less confused than I was going in.

      Flakes seems like a great tool. Normally, when I hear someone say they use Nix with $TOOL, my reaction is “I have a hard enough time figuring out Nix on its own, tyvm”. Why is Flakes its own thing? And what is experimental about it?

      1. 16

        I’m glad it had the effect I was going for :)

        Flakes is a thing because the model that Nix uses kinda accidentally assumed that the whole world could be a part of nixpkgs. Turns out that’s sadly not the case, but this explains why external dependencies (such as random git repos such as my website’s source code) were never really considered as a core part of the model. Not to mention just giving people a .nix file to build the software is basically like giving someone a Dockerfile. A Dockerfile will get you to build the software yeah, but overall it doesn’t give you details on how to use it.

        I believe that the main innovation with flakes is that it doesn’t just give you build instructions, but also it gives you a way to give out usage instructions with the software. This is the same way that a docker-compose.yml file gives you instructions on how to use stuff that is built with docker.

        I’m pretty sure that flakes are still experimental because they want to get feedback about it and potentially make breaking changes to the implementation at some point. However, from my view the net improvements on giving more semantic information and direct ways to use things (eg: nix run github:Xe/gohello) are so great that this kind of thing really needs to be in the hands of more people. In my decision calculus it’s a case of the benefits outweighing the risks.

        I’m going to use this style of teaching people how to Nix in the future. I think the next post is purely going to be on how to write Nix packages (and split up a bigger package into a few smaller ones) using way too many contrived Go programs as examples. I may also work in Xeact and Xess. IDK, still working out the formula. This is the kind of style that I’d like to use for a book on Nix/NixOS if I ever get my ADHD to let off enough to let me commit to a longer term project like that.

        1. 4

          To pivot off of the note there on nix run, I’ll give an example, nixpkgs doesn’t have htwatch yet (I might submit a pr for it who knows), but if you want to run it anywhere with nix, aka darwin/linux with nix you can run this: https://github.com/mitchty/nixos/blob/master/flake.nix#L44-L71

          nix run github:mitchty/nixos#hwatch -- -n 300 -N -d somecommandorwhatever
          

          And It will build the same hwatch I am running at home now. I’m working on porting pikvm as well in that repo (i got side tracked so… don’t expect anything soon) but I love having nix flakes for a bit of a mini “personal nixpkgs” repo where I can test out experiments easily.

          I do have gripes about some of this mostly with the command MUST be the same as the package name, which isn’t quite good when you’re testing out something that has a name like blahfs and has a subcommand blah.mount that you want to just test out but I just haven’t looked at how hard that is to do or not.

      2. 2

        Thanks for the writeup! I’ve been wondering about Flakes for a while but never really understood what they were supposed to accomplish (versus “plain” Nix).

        1. 1

          For my personal tooling I use flakes for individual repositories b/c the built-in template and integrations (like poetry2nix for python applications) is a direct upgrade to what we had before.

          For my nixos configurations though I dislike using flakes. My main gripe with flakes is that it effectively becomes the entrypoint or ‘main’ of the configuration, which it makes it annoying to use with other tools like morph and the outputs section forces a certain structure to the code where I would prefer it work like niv where it sets up dependencies but the end result is just imports to your regular code.

          1. 1

            @cadey has your position on flakes changed? My earlier interpretation from earlier writing is that you favored tools like niv and morph which eschew the flake model completely. I also see that nix.dev still recommends niv (https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs) so wondering what the community thinks about flakes in general

            1. 5

              My position on flakes is that they are slightly less terrible than using NixOS normally. They ain’t perfect but they could be so much worse than they are. I’m happy with the usability as-is. Also see here for more words about the kind of mindset change that I had once I hit the satori moment with flakes.

              1. 2

                wondering what the community thinks about flakes in general

                No idea about “the community” (I really hate those terms), but I found flakes easier to get into than anything that came before that always felt “tacked on like spaghetti stapled together”.

                I’m doing more with nix now that I ever have now that flakes are “officially” here. Yes experimental but i now have a repo for my entire home config, I have that setup so I can build auto installing iso images, have secrets setup too, and build a system with my home config all in one deploy step via deploy-rs.

                In my view flakes are already useful enough to make me not care about what came before which I avoided to be honest. Perfect no but good enough for government work as they say.

            2. 1

              I remember watching “How Nix and NixOS Get So Close to Perfect” and you had a comment about not using flakes or something similar. Glad to see you’ve joined the dark side. You’re posts/shared configs are always a treasure trove of great information. Thanks for all your efforts!