Questions about nix-pills

build output missing at repl

In this section (Nix Pills | Nix & NixOS), the writer reviews the output from declare -xp to teach some things about the stateless nature of nix.

I am starting the repl w/ nix repl on NixOS, and I am unable to see any output from my build script. It produces the output file just fine, though.

Is nix supressing output from my build script? Wat do?

do not understand with (import <nixpkgs> {})

In this section (Nix Pills | Nix & NixOS) the author makes this statement:

Afterwards, we call the function with the empty set. We saw this already in the fifth pill. To reiterate: import <nixpkgs> {} is calling two functions, not one. Reading it as (import <nixpkgs>) {} makes this clearer.

But I am a big dumb stupid-face.

What I can’t understand is what {} is doing here??? If I had to break this down…

  1. import <nixpkgs> evaluates <nixpkgs>/default.nix, which returns a map expression
  2. with (import <nixpkgs>); ... essentially ‘destructures’ the map so it’s members are available as vars in the following expression
  3. {} is there to … i dunno.
1 Like

No, it does not. It evaluates to a function, which then gets passed {} as its argument.

It is more clear when you see things like import <nixpkgs> { config.allowUnfree = false; }.

IIRC the REPL does indeed surpress build output. I know for sure for 2.4, and assume it is the same in 2.3.

I have to say though, that the pills are not suitable for beginners, and actually not even necessary. It explains the low level way to create packages and there are much higher abstractions available within nixpkgs which are nicer to work with, like mkDerivation. I look at them more or less regularly, read half of the first pill that deals with packaging and then leave it alone. Still I wrote my packages and am maintaining them in my flake and nixpkgs. Thats fine. There are abstractions in nixpkgs (like mkDerivation) that allow you to not have to care for that low level stuff and give you a nice “phased” interface similar to one might be used to it from PKGBUILD or emerge build descriptions.


There are abstractions in nixpkgs (like mkDerivation) that allow you to not have to care for that low level stuff and give you a nice “phased” interface similar to one might be used to it from PKGBUILD or emerge build descriptions.

I don’t have any background writing Linux build packages and tbh they all look like mysterious incantations to me.

Buuuut I like NixOS and occasionally need to build things from GitHub which only have debian or arch instructions so…

There is a strong chance this is an insurmountable problem for me b/c I’m not really interested in learning nix. It’s a hoop I have to jump through to do this thing I need every few months.

I have seen some crazy workarounds in nix build expressions and don’t have the C experience or requisite Linux experience to have engineered them.

So I will likely give up at the first novel hurtle.

1 Like

If you do not want to learn nix, then why read the pills? Those teach fundamental low level nix.

Though I have to be honest, you can not use nixos without at least learning nix the language, as this is what you need to use to configure your system.

And since you got already this far with the syntax, its not far away to learn basics of mkDerivation.

At the end, it is just a function call that you pass a couple of arguments, which describe the build.

Those strings represent shell scripts which run in an isolated environment and you have basically 3 important phases:

  • configurePhase runs scripts that generate configuration or headerfiles needed for the build, but not provided by the source, as they are target specific. Ie it runs ./configure
  • buildPhase runs scripts that actually build the project as required, eg. make.
  • installPhase runs scripts that copy the previously built artifacts to their location in the store, eg. make install PREFIX=$out

Not all programs are easy to package, especially those that have strict assumptions about FHS or hardcode pathes. For those you often need to also use patchPhase or fixupPhase.

At the end, you could in theory as well just lump together all the phases into a single one and do all work, from configuration to install in that single phase, though the classic separation makes it easier to debug the build script.

If you really are in doubt, and have no clue how to proceed, ask someone if they could help you packaging something or if they package it for you.


Though I have to be honest, you can not use nixos without at least learning nix the language, as this is what you need to use to configure your system.

I have been “getting by” on my personal desktop and laptop by using the wiki and other community resources. And most of the time that’s unnecessary because the package list is straightforward and Nix has a deep well of packages to choose from.

This is the second time reading the nix pills b/c I didn’t “get it” the first time.

I could level a minor criticism about nix at this point but it wouldn’t negate the fact that I’m just not very smart.

I feel compelled to respond to this. I believe most people who encounter Nix and try to get into it have this feeling (myself included). I trust that I am pretty smart (I went through a lot of school, and I make a living with my brain, after all) and even so NixOS and Nix has been a rocky, steep, and difficult climb, sometimes with ice and freezing rain falling (overlays) and sometimes with the sun shining brightly (flakes). I am persisting only because I know there’s an amazing taco stand at the top of the mountain.

So many people who try out Nix do indeed find it difficult, perhaps believing they are not smart enough to get it, but the trick is that if everyone feels that way, then the difficulty must lie with Nix. I say this out of love and wanting desperately for things to get easier. I believe that some concerted messaging around the right way to do things, to improve the tooling (which is ongoing as we speak), improve error messages, and figure out how to curate a collection of high-quality tutorials, cookbooks, and documentation would go a very long way towards easing the new user experience. I know some of this exists already, but the very fact that people keep going back to the Pills series (which is both extremely high quality information, and extremely difficult to grok) means that it’s not enough yet. Unfortunately, I’m not sure how to help things get better myself, but as I learn things, perhaps I will try to write them down and share those writings.

Nix/NixOS is probably the best Linux distro I’ve ever used, but I really do wish I were “better at it”.

1 Like

There’s which is going in the right direction.

I think nix needs basically something like an extended, a one-stop shop for curated, goal-oriented tutorials that cover just enough to understand everything required to achieve some specific goal (i.e. “use flakes”, “override a package version”, “install a non-nix packaged application”), without too much background about how it all works (but links to provide easy looks into documentation and other information sources).

That’ll give a much easier index into the terse inner workings, and with enough reading of something like the above the nix pills lose their complexity.

I’d like to write something like that, but don’t know where to begin, especially since it’d have to be something semi-official that people will easily run into shortly after starting to experiment with nix. And also I don’t know if I actually have the time and writing skills :wink:

Basically, I think the “intermediate” documentation for nix is missing. We have great basic beginner docs (the install guide, help menus, error messages, wiki pages, options search and some other things), and lots of heavy docs on nixpkgs and nix (ranging from the nixpkgs documentation all the way to the original nix paper), but not much for slightly more complex use cases that aren’t writing a new distro.

It’s a side effect of the main user being NixOS, and most people huddling around it to make nix work properly. I do think there’s a bit of an ongoing shift, with the growing userbase and the existence of flakes, that may change this though :slight_smile:

One small thing that is changing is the new documentation theme for the official docs. Nix 2.4 came with a searchable readthedocsey thing that is much more navigable than the old HTML dump, which has IMO already significantly improved matters. There are upstream issues for doing the same for the nixpkgs and nixos docs.


Nix language is pure functional which implies a very different point of view and mindset to address problems comparatively to imperative one. By example overlay stuff is lot more simple to appreciate when you grasp the concept of fixed point (no so difficult in fine). My practical advice is to enhance your confidence in (Pure) functional language (recursion, list manipulation, higher-order functions, lazy evaluation, fixed point…)

@augu5te That doesn’t ring true to me. Maybe that’s the case for a lot of people, but I have a lengthy background w/ Clojure. All of those concepts are “old hat” for me.

1 Like

Seconded. The problem (at least for me) is emphatically not the FP nature of Nix, which will come naturally to most CS folk. While the fixed point formulation of the package set is indeed a difficult concept compared to what you find in other distros, it takes a bit of explanation and then a demonstration by example to show how it works and then most people will succeed with it most of the time.

The problem is that the gap between the descriptions of things at a more theoretical level (as presented in much of the existing docs) and a concretely usable instantiation of those ideas is too often far too large to cross easily, even for smart people who understand the ideas. I’ve closed the gap on occasion by adapting examples I find on, e.g., discourse, or asking people in the IRC channel, or attending the Friday office hours sessions, and then immediately saving what works in a Git repository so I can study it later, and absorb the practical patterns.

There’s a specific lack of examples and explanations for how a system running Nix or NixOS comes together in a specific way. That’s something I’d like to fix.

I am just now realizing that I’m just saying what @TLATER said upthread, but not as well. Consider all this another “seconded” for that post. And thanks for reminding me about–need to spend some time reading what all is there, and thinking about what still might be missing.

Honestly, I think there is a critical mass of people who are on the verge of becoming hyperproductive with Nix/NixOS, if only we could solve that “middle documentation” problem. If there isn’t common knowledge of the existence of this group, then we can’t solve that problem. So please keep speaking up and let’s see what we can do!

1 Like