1. 47

  2. 6

    Thank you for writing this. I know that in the past I’ve struggled trying to search for solutions and ask questions about Nix because I wasn’t sure if I was using the right terms.

    A couple of other terms which appear in the documentation and occasionally elsewhere:

    • Instantiate: transform a nix expression into a derivation.
    • Realise: transform a derivation into an output (by building it).

    I highlight these because I think that understanding and using them helps get a clearer idea of the whole nix expression –instantiate-> derivation –realise-> output process.

    Another term which shows up a lot is package. However, I don’t know if there is a precise definition for this in a Nix context.

    Nix store

    This is the filesystem storage for derivation outputs

    It’s also where the derivations themselves (the .drv files) live. Not sure if that’s an important detail.

    1. 1

      I have not touched any of these concepts so far, so they’re still magic to me! But I will look into them. :-)

      (Only thing I’ve done with .drv files so far is sometimes cat them to find the actual output directory.)

      1. 2

        You can also use nix eval

        ❯ nix eval --raw nixpkgs.hello

        You can also use nix eval to evaluate other attributes:

        ❯ nix eval --json nixpkgs.ncdu.buildInputs

        Though at some point it’s nicer to switch to nix repl for inspecting stuff :).

        Anyway, thanks for the great post! This is something that can point people to in the future if they want to learn about core Nix concepts.

    2. 2

      fwiw, installing nix on non-NixOS linux distros is very easy, the installer guides you through it. as far as I understand it, it’s much easier than the install process on a mac

      1. 1

        Yup, it is an one-liner install on Linux and older macOS versions. On macOS catalina, you need to do a bunch of things first. I’ve written about the edge cases here.

        1. 1

          Some installation troubles are already being fixed. For example, this Nix 2.3 PR adds the necessary installer support.

          But I’m also concerned about the result of installation. For example, the upgrade procedure on macOS right now is:

          sudo -i sh -c 'nix-channel --update && nix-env -iA nixpkgs.nix && launchctl remove org.nixos.nix-daemon && launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist

          Compared to nix-darwin, where you just update channels and rebuild configuration. This is also why I used the closing words to argue that these type of installs should prioritize single-user systems and let the nixpkgs channel be managed by the regular admin user, as well as a combined nix/nix-darwin installer so the installation can upgrade itself.

          I’m not sure what the installation result is on other Linux distributions, and if it also leaves Nix in a sort of do-it-yourself setup.

      2. 2

        This is a really great writeup and I wish it would become the front-page (or at least the introduction) to Nix. It lays out things is a far better and readable way than the official documentation. Thank you!

        1. 2

          It really does need to be folded into the documentation somehow. I think it’s not quite the perfect document for a total newcomer, but it does provide a good over of what all the major moving parts are and how they interact.

          1. 2

            Thanks, that’s nice to hear! This kind of post takes me days to write, so it’s great to hear people find it useful.

            I’m still playing around with the idea of contributing, so don’t know if I’d enjoy putting spare time into working on Nix documentation, for example. But if parts, passages or ideas from this article can be used for Nix documentation, feel free to take.

            1. 1

              I have had a lot of positive experiences getting PRs merged in nixspace (though sometimes you do have to give a bump now and then).

              Consider this me nudging you towards contributing :-)

        2. 2

          In the Nix language, expressions are the top-level language construct. (As opposed to, for example, statements in JavaScript / Python / Ruby, or definitions in C and friends.)

          (nitpick) this is also true of Ruby

          1. 1

            Eek! Thanks for pointing this out. I simply removed the mention of Ruby there. :-)

            1. 2

              It’s still true that Nix’s top-level construct is one expression used only for its value, while Ruby’s is a sequence of expressions used only for their side-effects…

          2. 1

            Just wanted to say thanks, this is awesome. I’ve been using Nix for a year or so, and the sentiment here about how the documentation is lacking, there being many ways to do things, etc etc rings very true. It’s documentation like this that Nix really needs to get more adoption. Even for a semi-experienced nix user, this piece has filled me in on some small gaps of things I have meaning to get around to working out what they are, but never got around to, too. Either way, I like your approach very much.

            1. 1

              This writeup is great. Nix’s manual is too thorough (as you point out), and something like this is sort of the “missing manual” folks may need to get started. I’d like to see this linked from nixos.org.