nixpkgs

[!warning] Darwin support in nixpkgs macOS support in nixpkgs is not of same quality and priority as Linux. See https://github.com/NixOS/nixpkgs/issues/145230 & https://github.com/NixOS/nixpkgs/issues/116341

[!note] macOS support While macOS doesn’t enjoy first-class support in nixpkgs yet, improvements are underway.

A flake can refer to other flakes in its inputs. Phrased differently, a flake’s outputs can be used as inputs in other flakes. The most common example is the nixpkgs flake which gets used as an input in most flakes. Intuitively, you may visualize a flake to be a node in a larger graph, with inputs being the incoming arrows and outputs being the outgoing arrows.

Let’s do something more interesting with our flake.nix by adding the nixpkgs input:

The nixpkgs flake has an output called legacyPackages, which is indexed by the platform (called “system” in Nix-speak), further containing all the packages for that system. We assign that package to our flake output key foo.

The official manual explains the Haskell’s infrastructure in nixpkgs detail. For our purposes, the main things to understand are:

This flake defines a flake app that can be run using nix run. This app is simply a shell script that starts a Postgres server. nixpkgs provides the convenient writeShellApplication function to generate such a script. Note that "${script}" provides the path in the nix/store where the application is located.

We used callCabal2nix function from nixpkgs to build the todo-app package above. This functio generates a Haskell package Derivation from its source, utilizing the “cabal2nix” program to convert a cabal file into a Nix derivation.

This is a tutorial series on nixifying Haskell projects. In part 1, we will begin with using nothing but nixpkgs. In the latter parts, we’ll use simplifiy our project Nix code through haskell-flake which builds on top of the Haskell infrastructure in nixpkgs.^*

The nixpkgs library provides a module system for Nix expressions. To learn it, see our tutorial: Introduction to module system.

We shall begin by understanding the low-levels: how to use evalModules from nixpkgs to define and use our own modules from scratch, using the aforementioned lsd use-case. The next tutorial in this series will go one high-level up and talk about how to work with modules across flakes, using flake-parts.

You have successfully installed NixOS. The entire system configuration is also stored in a Git repo, and can be reproduced at will during either a reinstallation or a new machine purchase. You can make changes to your configuration, commit them to Git, and push it to GitHub. Additionally we enabled Flakes permanently, which means you can now use all the modern nix commands, such as running a package directly from nixpkgs (same version pinned in flake.lock file):

As of this writing, nixpkgs has over 80,000 packages. You can search them here. Search for “cowsay” and you will find that it is available in Nixpkgs. We can download and run the cowsay package as follows:

Incidentally, we use the tree command, rather than ls, to look at the directory tree, using the package from nixpkgs of course (since it may not already be installed).

So far we have been retrieving and installing software from the nixpkgs flake, which is defined in the GitHub repository: https://github.com/nixos/nixpkgs. This information comes from the Flake registry:

The discerning readers may have noticed that the registry specifies only the branch (nixpkgs-unstable), but not the specific revision. Nix registry internally caches flakes locally and updates them automatically, thus the specific Git revision of nixpkgs used may change over time!

The cowsay Derivation produces two output paths, the second of which is the cowsay binary package (the first one is the separate documentation path), and if you inspect that^* you will see the contents of it:

We can find the current Git revision of nixpkgs used by our registry as follows:

You have installed Nix. Now let’s play with the nix command but without bothering to write any Nix expressions yet (we reserve that for the next tutorial). In particular, we will learn how to use packages from the nixpkgs repository and elsewhere.

[!tip] Pinning nixpkgs To avoid the aforementioned automatic update, you can manually pin the registry entry for nixpkgs. In home-manager, we will see an automatic and declarative way of doing this (through flake inputs).

nixpkgs is not the only way to get software packaged by Nix. As you have seen immediately above, you can install programs from any flake by specifying its flake URL to the nix ? commands. For example, Emanote (which is used to build this very website) can be executed or installed directly off its flake on GitHub:

Using software outside of nixpkgs

How is nixpkgs fetched

The package shipped with the current nixpkgs might not be the desired one, follow the snippet below to override the package (assuming nixpkgs-21_11 is present in your flake’s inputs).