Learning Nix: Flakes

I’ve been reading up on this gentleman’s journey to learn more about Nix and it has been very educational. But today, I want to bring attention to the parts where he tries out Flakes. Before saying anything, something mentioned on the very first post that I’d like bring to attention:

I recognize that no one asked me to learn Nix, and I definitely recognize that no one owes me anything. I did this, first and foremost, because I found it fun. I like to learn things, and I like to write. If someone who contributes to Nix ever actually sees these blog posts, I hope that they take them for what they are: a weird kind of user acceptance test. Not demands or complaints, just the story of one person’s experience.

Having said that, the flakes part are so dangerously close to my personal experiences, that I was simultaneously worried of having spli-personality and wanted to bring attention to this of Nix developers:

How to Learn Nix, Part 43: My first brush with flakes
How to Learn Nix, Part 44: More flakes, unfortunately
How to Learn Nix, Part 45: Fancy new profiles

Don’t worry, you don’t need to read first 42 parts to understand them.

These write-ups are, in my opinion (and experience) worth more than all other posts on flakes combined to portray how those who don’t follow Nix world constantly via Discourse, Matrix, IRC or Github are finding themselves in flakes’ wake.

I hope Nix developers find this post as something it is intended : An honest, real, User-acceptance test, and helps future development with an outside perspective. I like Nix, still use it, and intend to keep using it. But this here is a gem of a documentation worth reading even for non-developers of Nix, just to get a good cover of flakes foundation.


Thanks i was looking some tutorial about this topic, it would be nice to see some kind of video tutorial with this soft approach to the theme :stuck_out_tongue_winking_eye:

I actually read those as well and found them to be a very hard read and not useful at all.
After I finished them I only felt that I wasted my time.
Far too much ranting for my taste.
He has some valid points but they could probably be summarized on half a page without having to read through the whole mess.

This helped me much more for example:


I agree, a condensed summary is better if one is trying to learn flakes. What this is, is a written format of this person’s journey or process of learning flakes. As mentioned first, it is a User Acceptance test result, in a good detail too.

What set it apart for me is that this guy goes through lot of stuff to actually ‘understand’ how stuff works, starting with first principles. There are 42 parts before this after all. Your link gives a great interview and very useful if all I want is get work done. Both are useful, but for separate purposes.


I agree in general but I just found his tone very annoying to read.

1 Like

I agree with some of the points made, documentation could definitely be improved, but the whole thing also came across quite dishonest to me, as if the author was looking for reasons to dislike flakes.

For example, they start with a blog post about flakes from over a year old and rant about how it doesn’t provide the information they want, but only after more than 1 blog post the author starts reading nix <cmd> --help, where they do find what they had been looking for. But that is entirely reasonable IMO, because blog posts are not documentation.

And even if you would take the blog post as documentation, they quote parts of it, but not the entire thing, leaving out pieces that are pretty helpful when you want to inspect the contents of a flake, which is one of the things they could not figure out. Such as

Another goal of flakes is to provide a standard structure for discoverability
within Nix-based projects. Flakes can provide arbitrary Nix values, such as 
packages, NixOS modules or library functions. These are called its outputs.

But never did they try to access one of the attributes in the outputs of their flake. Could this be more informative? Yes. But then again, this is not documentation, and they tried almost nothing and gave up.

Or where they are calling things weird (emphasis not mine) without reading about why things are that way. With such a mindset you’ll never actually learn.

I’ll stop now because this is has also become quite the rant.


This blog series is a really good kind of case study in Nix UX, and the new entries are maybe the best kind of user acceptance testing that Nix flakes will ever get. I really hope that Nix devs take the time to read the sections on flakes, because I think @ianthehenry is pretty representative of the kind of user the Nix community needs to continue to attract and retain. This is a great opportunity to perfect some details before the everything gets stabilized in the Nix 3.0 release!

The determination and good attitude combined with frankness about what he doesn’t understand yet and directness about what it feels like to learn specific aspects of Nix are really valuable, and it’s unlikely many people will be willing to produce detailed writing like this.

PS: Thanks for posting this. I didn’t realize there were new entries in the series yet :slight_smile:


I think it bears repeating that Flakes are currently an experimental feature. It’s incomplete, a bit buggy, with some odd quirks, and incomplete documentation. It’s expected that using Flakes is not as user friendly as we hope for it to one day be. By choosing to use Flakes, you are opting into that sub-par experience in an effort to help improve it. Flakes are available as an experimental feature precisely because Nix devs are open to people’s thoughts on them.

By the same token, if you aren’t willing to be a part of the experiment, then don’t enable experimental features. I definitely see far too many people using Flakes who don’t understand this.

1 Like

I think it sometimes makes sense to remind people this, especially if they are abusive, or if their complaints center on behavior changes to unstable CLI interfaces, or if it’s clear that they’ve staked much too much on an incomplete feature. And it can be frustrating for developers to hear complaints or criticisms about things they already know are issues and that are already on their to-do lists.

At the same time, one of the things that makes Nix great is that in important areas where other tools in the same domain only offer warnings or advice, Nix offers something much better, like a guarantee or a revert button. When an experimental feature is criticized, I think community members have an opportunity to embody the same virtue as Nix: to resist relying too much on mere disclaimers, even when those disclaimers are well-motivated or valid.

I also think it’s easier to mistake the expressions of negative emotions in these particular posts as rants, or to wonder ‘Why is he complaining about still not knowing what derivations are? Why doesn’t he look them up?’ if you haven’t followed along with the series or don’t have a feel for the genre, so-to-speak. I don’t expect most people who stumble upon this thread to go back and read the whole series, because it’s a very long series of long-ish posts. But I do wanna highlight two other posts from the author for anyone who is struggling to read him as

  • approaching Nix in good faith,
  • genuinely setting out to learn,
  • trying to do something constructive, or
  • appreciative of Nix’s strengths and the value of learning Nix.

Those posts are the first post in this series, where he gives a good explanation of the genre he intends to write in (which the original post in this thread quotes a bit) and a post technically outside the series that describes Nix as a ‘secret weapon’ and explains why the author is glad he stuck with learning it.