1. 46
  1.  

  2. 12

    For anyone else ignorant of what “flakes” are in this context, here is an intro.

    1. 7

      It feels to me like this article was written in response to some local Internet Drama™ that I’m 100% unaware of, even as a casual NixOS fan. As such, I’d admit its tone renders me mildly baffled and slightly scratching my head. I really hope you’re all doing fine! <3

      As to some points mentioned by the article raised in some comments here on lobste.rs, though IMO not really touched by the article (with the caveat that I’m unaware of the presumed Internet Drama™ story), my personal belief is that:

      • Nix Flakes are fairly amazing, in that they seem to be precisely fixing nearly all the few major PITAs/annoyances of managing Nix expressions that I had over my amateur relationship with Nix (probably except secrets handling); basically IMO putting the Nix technology in general on a straightforward trajectory towards holy freaking mountain-crushing awesomesauce; mind me, there are still smaller grade annoyances (like just the fact it’s dynamically typed), that will lead to no end of complaints, but IMO they’re on a level of things that didn’t stop, say, Python from succeeding.
      • Nix/NixOS documentation situation was super tedious since approximately always; as such, the current state of Nix Flakes documentation… kinda stays in line with that tradition :P and is thus (if unfortunately) not really surprising to me. On the other hand, in part due to Nix having recently kinda graduated from “mad scientist” to “fringe science” territory in Internet Hive Mind’s perception, it’s starting to gain a steady stream of third party resources in the “blogosphere” (or whatever kids these days call it). I wouldn’t be surprised if they started providing some reading material on those topics earlier than official Nix docs… Also, notably, due to the Nix Wiki being thankfully brought back to communion with Nix’s local (slightly-Chaotic Good) Hive Mind, there’s some useful stuff about flakes at least in there; and also, notably as well, thanks to the IMO brilliant step of finally accepting Markdown as the format for docs, many people AFAIK (me included) hope it’ll be possible for (the exceedingly rare bird of) some accidental docs contributor to actually have a chance of not running away immediately in panic in case they someday actually drift close by in the first place.
      • IMO, the introduction of the RFCs process, the smoothing up of the merge process, etc. etc. etc. are super awesome steps and I’m super happy they’re being undertaken. There are always bumps and toothing problems, it would be naive if disarmingly sweet to expect none ;)

      My general feeling about Nix, is that given how successful (in the “mad scientist” circles) it became while the docs and the merge process were so crappy as they were a couple years ago still, then seeing a few amazing breakthrough developments recently (incl. flakes, rst->md, bringing back the wiki, opening a bit the merge process), I feel extremely highly confident Nix is on a path to somewhere very close to… maybe what I’d call “HN mainstream”, i.e. something like docker/k8s now. (Such that mad scientists like me already kinda treat it as old news and established tool, while “Big Tech” starts to slowly see it as an “Emerging/Buzzword”. Mwahahahaha <chuckle>) IOW, I expect it will start showing up relatively commonly in Hiring Descriptions at some point ;P

      Thus, to @grahamc and other Nix community members: first of all, HUGE Thank You for your work; then, if there’s some community drama that got out of hand, could there be some possibility to try and ask some respectable people who went through similar toothing pains and phase-shifts in their communities, who could maybe help you heal and get some more experience in resolving some challenging situations in the future? I personally seem to think of the Rust community as a high-profile FOSS one that seemingly managed to stay decently healthy in face of a lot of challenges; maybe it could be worth to at least try to shoot @steveklabnik a message and see if he could connect you to someone who might be able and have some time at hand to possibly help you a bit? This certainly doesn’t come with any guarantees, but I’d say maybe there’s not much to lose, and possibly quite a lot to win, in having a try at that? Anyway, good luck, and I’m really keeping my fingers crossed for you! :) <3

      edit: sorry for this being a huge wall of text, and somewhat chaotic :/

      1. 4

        At this point, it feels like there’s a chicken and egg problem. Lots of people I’ve talked to have been scared to touch them due to the experimental status and unstable verbiage, but the only logical way forward is flakes. Personally, I feel like using non-flake Nix feels barbaric after having tried them since there’s just so many emergent properties that they bring that make life so much easier. A couple really neat things I’ve been able to do is have repos set up that provide arbitrary nightly builds of arbitrary software via CI that I don’t have to worry about dealing with the hashes or anything for (vim plugins, alacritty, neovim itself via their flake, and so on). Instead of worrying about channels nowadays I can just git pull my config and rebuild and have an actually reproducible config rather than “well i’d have to figure out the channel state, too much effort”. I sort of feel like flakes need a soft rebrand at this point to jumpstart adoption.

        1. 4

          Flakes are one of those things that feel like they could really simplify a lot of NixOS stuff (including being able to split stuff out of the massive nixpkgs monorepo), but the experimental status around them has me feeling a little nervous.

          1. 2

            Me too. I tried to flake-ify some of my repos near the end of last year, and couldn’t make head or tail of what needs to go where. I’m aware of a few Tweag blog posts, and not much else in the way of good documentation. Has the documentation situation improved?

            1. 5

              I have found the flakes wiki page to be a good reference that I still consult regularly:

              https://nixos.wiki/wiki/Flakes

              1. 6

                This and https://zimbatm.com/NixFlakes/ are quite good.

              2. 4

                Not really. One of the traps of it being “experimental, but merged” is some people have suffered through and figured it out… and others haven’t, but not much documentation is happening because it is “experimental” and could “change at any moment. Of course, it would be nice if there was something a referer could provide.

                That said, nix flake --help has a good bit of stuff.

                1. 7

                  I feel this might also be the general curse of the nix documentation, which typically has very thorough reference docs, but lacks simple guides for folks which just want to do things, without necessary understanding how it works under the hood.

                  With flakes, I feel that RFC and the series of tweag posts are an excellent reference, but I didn’t find a simple guide for my simple use-case. The docs are “here’s how you setup NixOS container” or “here’s how you use home-manager”, while what I want is a minimal diff to switch from minimal /etc/nixos/configuration.nix to minimal flake.

                  1. 2

                    That’s a shame. A sprint to document flakes as they currently are may help break the deadlock.

              3. 1

                I agree that by and large flakes are a good thing. Having a standard layout for Nix repositories, proper versioning through lock files, and impurities removed are a huge step forward. However, I also agree with e.g. andir that it would probably have been better if work had been started with a pure-nix implementation to hash out the UI/UX. [1] It would have allowed faster iteration and more community members could have contributed to the design, because most people in the Nix community are more familiar with Nix than C++. Also, it would have decoupled Nix 2.4 from flakes.

                But it is always easy to criticize things in hindsight, it is often hard to anticipate how processes unfold. As you said, the Nix/nixpkgs/NixOS community has grown at a very fast pace, and we have to learn to deal with that as a community.

                At any rate, I think we are beyond the point of return and the best path forward is that people try flakes, submit bug reports, and getting it into a shape where it can ship. Perhaps UX gripes can be addressed in a future iteration using editions. I think there are now to many flakes out there to make very large breaking changes. I don’t want to recommend people to use flakes in production systems, since they are still unstable, but I have switched to flakes to build my main desktop months ago without any issues. I have also converted some of my projects to flakes, using flake-compat for compatibility with Nix 2.3.

                [1] Eelco Dolstra even made a nice flake-compat project, which can be used to evaluate flake.nix/flake.lock files for compatibility with pre-flake Nix versions.

                1. 1

                  I always saw flakes as some sort of formalisation of Niv’s functionality, but guess that’s not it. Are flakes older than Niv? Did Niv not play part in the RFC process?

                  1. 3

                    I am not sure which was first, but the first Niv commit was on Jan 17, 2019, the flakes MVP was posted in October 2018.

                    Niv overlaps with the flake locking mechanism. But flakes provide much more, such as a standard Nix repository API, and it enables pure evaluation (e.g. using impure functions such as builtins.currentSystem is not allowed).