Flakes is a necessary abstraction of top of Nix that improves on usability and reproducibility. Flakes is production ready despite being marked as experimental.
Flakes is a necessary abstraction of top of Nix that improves on usability and reproducibility. Flakes is production ready despite being marked as experimental.
In flakes, nixpkgs is the most commonly used input.
:lf <flake-url>flake-parts brings the NixOS module system to flakes, thus providing a cleaner and simpler way to write otherwise complex flakes.
If your project provides a flake.nix along with a development shell, it can be developed on VSCode using one of the two ways (prefer the 2nd way):
./data/<service-name>, where ./ refers to the path where the process-compose app, exported by the project flake is run (usually in the project root).The goal of this mini-tutorial is to introduce you to Nix the language, including flakes, as quickly as possible while also preparing the motivated learner to dive deeper into the whole Nix ecosystem. At the end of this introduction, you will be able to create a flake.nix that builds a package and provides a developer environment shell.
A Nix flake is defined in the flake.nix file, which denotes an attrset containing two keys inputs and outputs. Outputs can reference inputs. Thus, changing an input can change the outputs. The following is a simple example of a flake:
The goal of this mini-tutorial is to introduce you to Nix the language, including flakes, as quickly as possible while also preparing the motivated learner to dive deeper into the whole Nix ecosystem. At the end of this introduction, you will be able to create a flake.nix that builds a package and provides a developer environment shell.
Welcome to the Nixify Haskell projects series, where we start our journey by integrating a Haskell application, particularly one using a PostgreSQL database, into a single-command deployable package. By the end of this article, you’ll have a flake.nix file that’s set to build the project, establish the development environment, and execute the Haskell application along with all its dependent services like PostgreSQL and PostgREST. We’ll be using todo-app as a running case study throughout the series, demonstrating the process of building a Haskell project and effectively managing runtime dependencies, such as databases and other services, thereby illustrating the streamlined and powerful capabilities Nix introduces to Haskell development.
This module system is not natively supported in Flakes. However, flakes can define and use modules using flake-parts.
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.
Consider the following Nix code, defined in a flake:
You have just read a quick introduction to the module system, in particular how to define, use and share them in Flakes. To learn more about the module system, we recommend this video from Tweag as well the article “Module system deep dive” from nix.dev. Look out for the next tutorial in this series, where we will talk about flake-parts.
As a final step, let’s permanently enable Flakes on our system, which is particularly useful if you do a lot of software development. This time, instead of editing configuration.nix again, let’s do it in a separate module (for no particular reasons other than pedagogic purposes). Remember the modules argument to nixosSystem function in our flake.nix? It is a list of modules, so we can add a second module there:
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):
Install Nix using the experimental installer:*
Global registry of Nix flakes
A flake can be referred to using an URL-like syntax.
[!info] nix run nix run command will run the specified package from the flake. Here nixpkgs is the flake, followed by the letter #, which is followed by the package (Derivation) name cowsay that is outputted by that flake. See Flake URL for details on the syntax.
We will use Nix Flakes to configure Home Manager.
configuration.nix to be a flake
Now, /etc/nixos is technically a flake. We can “inspect” this flake using the nix flake show command:
A problem with the default NixOS configuration.nix generated by the official installer is that it is not “pure” and thus not reproducible (see here), as it still uses a mutable Nix channel (which is generally discouraged). For this reason (among others), it is recommended to immediately switch to using Flakes for our NixOS configuration. Doing this is pretty simple. Just add a flake.nix file in /etc/nixos: