Wombat’s Book of Nix

Strings are enclosed by double quotes ("), or two single quotes (').

They can span multiple lines.

The Boolean values in Nix are true and false.

File paths play an important role in building software, so Nix has a special data type for them. Paths may be absolute (e.g. /bin/sh) or relative (e.g. ./data/file1.csv). Note that paths are not enclosed in quotation marks; they are not strings!

Enclosing a path in angle brackets, e.g. <nixpkgs> causes the directories listed in the environment variable NIX_PATH to be searched for the given file or directory name. These are called lookup paths.

List elements are enclosed in square brackets and separated by spaces (not commas). The elements need not be of the same type.

Lists can be empty.

List elements can be of any type, and can even be lists themselves.

Attribute sets associate keys with values. They are enclosed in curly brackets, and the associations are terminated by semi-colons. Note that the final semi-colon before the closing bracket is required.

The keys of an attribute set must be strings. When the key is not a valid identifier, it must be enclosed in quotation marks.

Attribute sets can be empty.

Values of attribute sets can be of any type, and can even be attribute sets themselves.

In Section 2.11.4, “Recursive attribute sets” you will be introduced to a special type of attribute set.

We’ll learn how to write functions in Section 2.12, “Functions”. For now, note that functions are "first-class values", meaning that they can be treated like any other data type. For example, a function can be assigned to a variable, appear as an element in a list, be associated with a key in an attribute set, or be passed as input to another function.

A derivation is an attribute set, but one which is a recipe for producing a Nix package. We’ll learn how to write derivations in Section 2.14, “Derivations”. For now, note that derivations are "first-class values", meaning that they can be treated like any other data type. For example, a derivation can be assigned to a variable, appear as an element in a list, be associated with a key in an attribute set, or be passed as input to a function.

You can declare variables in Nix and assign values to them.

In Nix, values are immutable; once you assign a value to a variable, you cannot change it. You can, however, create a new variable with the same name, but in a different scope. Don’t worry if you don’t completely understand the previous sentence; we will see some examples in Section 2.12, “Functions”, Section 2.16, “Let expressions”, and Section 2.17, “With expressions”.

The usual arithmetic operators are provided.

Numbers without a decimal point are assumed to be integers. To ensure that a number is interpreted as a floating-point value, add a decimal point.

In the example below, the first expression results in integer division (rounding down), while the second produces a floating-point result.

Nix provides the usual lexicographic comparison operations.

String concatenation uses the + operator.

You can use the ${variable} syntax to insert the value of a variable within a string.

Nix provides some built-in functions for working with strings; a few examples are shown below. For more information on these and other built-in functions, see the Nix Manual (https://nixos.org/manual/nix/stable/language/builtins).

How long is this string?

Given a starting position and a length, extract a substring. The first character of a string has index 0.

Convert an expression to a string.

Paths can be concatenated to produce a new path.

A path can be concatenated with a string to produce a new path.

In the example below, you might expect the result to be "home/wombat/file.nix". However, the file file.txt is copied to /nix/store/gp8ba25gpwvbqizqfr58jr014gmv1hd8-file.txt before concatenating it to the string.

When concatenating a string with a path, the path must exist.

Nix provides some built-in functions for working with paths; a few examples are shown below. For more information on these and other built-in functions, see the Nix Manual (https://nixos.org/manual/nix/stable/language/builtins).

Does the path exist?

Get a list of the files in a directory, along with the type of each file.

Read the contents of a file into a string.

Lists can be concatenated using the ++ operator.

Nix provides some built-in functions for working with lists; a few examples are shown below. For more information on these and other built-in functions, see the Nix Manual (https://nixos.org/manual/nix/stable/language/builtins).

Testing if an element appears in a list.

Selecting an item from a list by index. The first element in a list has index 0.

Determining the number of elements in a list.

Accessing the first element of a list.

Dropping the first element of a list.

Functions are useful for working with lists. Functions will be introduced in Section 2.12, “Functions”, but the following examples should be somewhat self-explanatory.

Using a function to filter (select elements from) a list.

Applying a function to all the elements in a list.

The . operator selects an attribute from a set.

We can use the ? operator to find out if a set has a particular attribute.

We can use the // operator to combine two attribute sets. Attributes in the right-hand set take preference.

This is often used to "modify" one or more values in the set. Recall that Nix values are immutable, so the result is a new value (the original is not actually modified).

An ordinary attribute set cannot refer to its own elements. To do this, you need a recursive attribute set.

Nix provides some built-in functions for working with attribute sets; a few examples are shown below. For more information on these and other built-in functions, see the Nix Manual (https://nixos.org/manual/nix/stable/language/builtins).

Get an alphabetical list of the keys.

Get the values associated with each key, in alphabetical order by the key names.

What value is associated with a key?

Does the set have a value for a key?

Remove one or more keys and associated values from a set.

Display an attribute set, including nested sets.

Functions are defined using the syntax parameter: expression, where the expression typically involves the parameter. Consider the following example.

We created a function that adds 1 to its input. However, it doesn’t have a name, so we can’t use it directly. Anonymous functions do have their uses, as we shall see shortly.

Note that the message printed by the Nix REPL when we created the function uses the term lambda. This derives from a branch of mathematics called lambda calculus. Lambda calculus was the inspiration for most functional languages such as Nix. Functional programmers often call anonymous functions "lambdas".

The Nix REPL confirms that the expression x: x + 1 defines a function.

How can we use a function? Recall from Section 2.2.8, “Functions” that functions can be treated like any other data type. In particular, we can assign it to a variable.

Procedural languages such as C or Java often use parenthesis to apply a function to a value, e.g. f(5). Nix, like lambda calculus and most functional languages, does not require parenthesis for function application. This reduces visual clutter when chaining a series of functions.

Now that our function has a name, we can use it.

Functions in Nix always have a single parameter. To define a calculation that requires more than one parameter, we create functions that return functions!

We have created a function called add. When applied to a parameter a, it returns a new function that adds a to its input. Note that the expression (b: a+b) is an anonymous function. We never call it directly, so it doesn’t need a name. Anonymous functions are useful after all!

I used parentheses to emphasise the inner function, but they aren’t necessary. More commonly we would write the following.

If we only supply one parameter to add, the result is a new function rather than a simple value. Invoking a function without supplying all of the expected parameters is called partial application.

Now let’s apply add 3 to the value 5.

In fact, the parentheses aren’t needed.

If you’ve never used a functional programming language, this all probably seems very strange. Imagine that you want to add two numbers, but you have a very unusual calculator labeled "add". This calculator never displays a result, it only produces more calculators! If you enter the value 3 into the "add" calculator, it gives you a second calculator labeled "add 3". You then enter 5 into the "add 3" calculator, which displays the result of the addition, 8.

With that image in mind, let’s walk through the steps again in the REPL, but this time in more detail. The function add takes a single parameter a, and returns a new function that takes a single parameter b, and returns the value a + b. Let’s apply add to the value 3, and give the resulting new function a name, g.

The function g takes a single parameter and adds 3 to it. The Nix REPL confirms that g is indeed a function.

Now we can apply g to a number to get a new number.

I said earlier that a function in Nix always has a single parameter. However, that parameter need not be a simple value; it could be a list or an attribute set. This approach is widely used in Nix, and the language has some special features to support it. This is an important topic, so we will cover it separately in Section 2.13, “Argument sets”.

To specify an attribute set as a function parameter, we use a set pattern, which has the form

Note that while the key-value associations in attribute sets are separated by semi-colons, the key names in the attribute set _pattern are separated by commas. Here’s an example of a function that has an attribute set as an input parameter.

We can make some values in an argument set optional by providing default values, using the syntax name ? value. This is illustrated below.

A function can allow the caller to supply argument sets that contain "extra" values. This is done with the special parameter …​.

One reason for doing this is to allow the caller to pass the same argument set to multiple functions, even though each function may not need all of the values.

Another reason for allowing variadic arguments is when a function calls another function, supplying the same argument set. An example is shown in Section 2.13.4, “@-patterns”.

It can be convenient for a function to be able to reference the argument set as a whole. This is done using an @-pattern.

Alternatively, the @-pattern can appear after the argument set, as in the example below.

An @-pattern is the only way a function can access variadic attributes, so they are often used together. In the example below, the function greet passes its argument set, including the variadic arguments, to the function confirmAddress.

When a derivation is instantiated (evaluated), the Nix expression is parsed and interpreted. The result is a .drv file containing a derivation set. The package is not built in this step.

The package itself is created when the derivation is built (realised). Any dependencies are also built at this time.

Using the derivation "d" created above…​

That .drv file is plain text; it contains the derivation in a different format. The mysterious sequence of characters in the filename is a hash of the derivation. The hash is unique to this derivation. We could have multiple derivations for a package, perhaps different versions or with different options enabled, but each one would have a unique hash. Any changes to the derivation would result in a new hash. Using the hash, Nix can tell the different derivations apart, and avoid rebuilding a derivation that has already been built.

We can inspect the derivation in the Nix repl.

We can examine the .drv file.

Or get a nicely formatted version.

Using the derivation "d" created above…​

In the Nix REPL, using the derivation "d" created above…​

Of course, this example failed to build because the builder and system are fake. We can achieve the same result at the command line.

Delete a path from the store if it is safe to do so (i.e. if it is eligible for garbage collection).

This will be a very simple development project, so that we can focus on how to use Nix. We want to package the following script.

Add the script to your directory and make it executable. Let’s test it.

This probably failed on your machine — why? The cow-hello.sh script depends on cowsay, which isn’t part of your default environment (unless you specifically configure Nix or NixOS to include it). We can create a suitable temporary environment for a quick test:

However, that approach becomes inconvenient once you have more dependencies. Let’s exit to the original (default) environment, and see that cowsay is no longer available.

For a single script like this, we could modify it by replacing the first line with a "Nix shebang", as shown later in Section 10.3, “Scripts”; then the script would run in any Nix environment. But for this exercise, we will package it as a "proper" development project.

We want to define the development environment we need for this project, so that we can recreate it at any time. Furthermore, anyone else who wants to work on our project will be able to recreate the same development environment we used. This avoids complaints of "but it works on my machine!"

We can use a function from Nixpkgs to create the environment, but we have to configure the package set for the system architecture. The function nixpkgs takes an attribute set as input, and returns a configured Nix package set that we can use. The only attribute we need to specify at this time is the system architecture name. For example, the following code creates a package set for the x86_64-linux architecture.

In Section 3.4, “pkgs.mkShell and pkgs.mkShellNoCC” we learned that Nix provides the function called mkShell, which defines a Bash environment. We need to specify that the environment should provide cowsay.

Now we’re ready to write the flake. Create the file flake.nix as shown below. If you’re not on an x86_64-linux system, modify the highlighted lines accordingly.

The description part is just a short description of the package. The inputs section should be familiar from Section 6.1, “Inputs”. So far, the outputs section only defines a development environment (we’ll add to it in Section 9.1.3, “Defining the package”).

The repetition of x86_64-linux is undesirable. In Section 9.1.4, “Supporting multiple architectures” we will refactor the code to eliminate some duplication and make it more readable. For now, we will stick with the straightforward version.

Let’s enter the shell.

Because we haven’t added flake.nix to the git repository, it’s essentially invisible to Nix. Let’s correct that and try again. We’ll also add the script to the git repository (otherwise we would get a confusing message about the file being "missing").

The warning is because the changes haven’t been committed to the git repository yet. We changed flake.nix of course, but when we ran nix develop it automatically created a flake.lock file. Don’t worry about the warnings for now. We can see that cowsay is now available, and our script runs.

We created an appropriate development environment, and tested our script. Now we are ready to package it.

In Section 3.5, “stdenv.mkDerivation” we learned that the function pkgs.std.mkDerivation provides a way to create a derivation by specifying the steps that need to be performed in each phase We specify the location of the source files. and use the standard unpack phase, which makes our source files available in $src during the build and installation. (We described the environment available during build and installation in Section 8.1, “The Nix standard environment”.) We don’t need to do anything in the build phase. In the install phase, we copy the script from $src to the output directory, $out, and make it executable. As with the development environment, we specify that cowsay is required.

Here’s the updated flake.nix. Again, change x86_64-linux if needed to match your system architecture.

Let’s test the package. First, we should exit the development shell so we can verify that the flake dependencies are automatically loaded. Otherwise the script could use cowsay from the development shell. We’ll also commit the changes to get rid of the warnings.

What went wrong? Although we made cowsay available in the runtime environment, the cow-hello.sh script can’t find it.

For now, we can just edit the script during the build phase. We’ll see another way to handle this in Section 10.5.1, “Access a top level package from the Nixpkgs/NixOS repo”.

Let’s try running the flake again.

Congratulations! Our package is popular, and people want to run it on aarch64-linux systems. So now we need to add an entry to packages. Of course we want to test it on the new architecture, so we’ll add an entry to devShells as well.

Let’s make sure it still runs on our system.

Of course, we should also test on an aarch64-linux system. But the flake definition is rather long now. If we need to add even more architectures…​ ugh. Even worse, notice that the definitions for x86_64-linux are almost identical to those for aarch64-linux. All that replication makes maintenance more difficult. What if we make a change to the definition for aarch64-linux, and forget to make the change to x86_64-linux?

It’s time to refactor the code to eliminate duplication and make it more readable.

In Section 3.1, “lib.genAttrs”, I introduced the lib.genAttrs function, and included a promising-looking example.

This function generates an attribute set by mapping a function over a list of attribute names. It takes two arguments. The first argument is a list; the list elements will become names of values in the resulting attribute set. The second argument is a function that, given the name of the attribute, returns the attribute’s value

In the example, we used a list of system architecture names as the first argument. For the second argument, we used a function that "pretended" to generate definitions.

What if we wrote a function which, given the name of the system architecture, would generate the development shell definition for us, and another function that would do the same for the package definition? Applying lib.genAttrs and the list of system architecture names to those functions would give us all the definitions we need for the outputs section.

The following function will generate a development shell definition. We will write the definition of nixpkgsFor.${system} shortly

And this one will generate a package definition.

So lib.genAttrs [ "x86_64-linux" "aarch64-linux" ] followed by the first function will give us the development shell definitions for both systems, and followed by the second function will give us the package definitions for both systems. We can make the flake more readable with the following definitions.

So forEachSystem is a function which takes one argument. That argument should be a function that, given the system name, generates the appropriate definition for that system, Now let’s examine the definition of nixpkgsFor.${system}.

Here we’re using forEachSystem to access the appropriate nixpkgs for a system.

Putting everything together, we have a shiny new flake. You may want to compare it carefully to the original version, in order to reassure yourself that the definitions are equivalent.

Note that if we need to support another architecture, we only need to add it to line 10. Let’s verify that it runs on our system.

I took some shortcuts in the flake definitions up to this point, just to keep it simple. Normally a flake has both a packages section and an apps section. The apps section is where we specify executable programs. If there is no apps section, then nix run will default to using the package, but that’s not ideal.

A typical flake might have multiple packages and multiple apps. (We could even have multiple development environments.) Normally we would specify a default package and a default app. The command nix run ` flakeurl#appname will run the app named appname from the `apps section of flakeurl. If we don’t specify appname, the default app is run.

To define an app, we specify the type and the path to the executable. We can re-use the definition from the packages section as shown below.

Later we might want to add overlays or some configuration options to nixpkgs in our flake. We can include the scaffolding for it with the following change.

The Nix manual has more information on config options and overlays.

Putting everything together, we have:

Let’s verify that it runs on our system.

Next, we’ll create a simple Haskell program.

Before we package the program, let’s verify that it runs. We’re going to need Haskell. By now you’ve probably figured out that we can write a flake.nix and define a development shell that includes Haskell. We’ll do that shortly, but first I want to show you a handy shortcut. We can launch a temporary shell with any Nix packages we want. This is convenient when you just want to try out some new software and you’re not sure if you’ll use it again. It’s also convenient when you’re not ready to write flake.nix (perhaps you’re not sure what tools and packages you need), and you want to experiment a bit first.

The command to enter a temporary shell is

nix shell -p installables

Where installables are flakes and other types of packages that you need. (You can learn more about these in the Nix manual.)

It’s time to write a Cabal file for this program. This is just an ordinary Cabal file; we don’t need to do anything special for Nix.

We won’t write flake.nix just yet. First we’ll try building the package manually. (If you didn’t run the nix shell command from earlier, do so now.)

The cabal command is provided by the cabal-install package. The error happens because we don’t have cabal-install available in the temporary shell. We can correct that.

Note that we’re now inside a temporary shell inside the previous temporary shell! To get back to the original shell, we have to exit twice. Alternatively, we could have done exit followed by the second nix-shell command.

After a lot of output messages, the build succeeds.

Now we should write flake.nix. We already know how to write most of the flake from the examples we did earlier. The two parts that will be different are the development shell and the package builder.

However, there’s a much simpler way, using haskell-flake. The following command will create flake.nix based on their template.

Examining the flake, you’ll notice that it is well-commented. The only thing we need to change for now is the name in packages.default; I’ve highlighted the change below.

We also need a LICENSE file. For now, this can be empty.

Let’s try out the new flake. Nix flakes only “see” files that are part of the repository. We need to add all of the important files to the repo before building or running the flake.

We’ll deal with those warnings later. The important thing for now is that the build succeeded.

Now we can run the program.

By the way, we didn’t need to do nix build earlier. The nix run command will first build the program for us if needed.

We’d like to share this package with others, but first we should do some cleanup. It’s time to deal with those warnings. When the package was built, Nix created a flake.lock file. We need to add this to the repo, and commit all important files.

You can test that your package is properly configured by going to another directory and running it from there.

If you move the project to a public repo, anyone can run it. Recall from the beginning of the tutorial that you were able to run hello-flake directly from my repo with the following command.

Modify the URL accordingly and invite someone else to run your new Haskell flake.

Next, we’ll create a simple Python program.

Before we package the program, let’s verify that it runs. We’re going to need Python. By now you’ve probably figured out that we can write a flake.nix and define a development shell that includes Python. We’ll do that shortly, but first I want to show you a handy shortcut. We can launch a temporary shell with any Nix packages we want. This is convenient when you just want to try out some new software and you’re not sure if you’ll use it again. It’s also convenient when you’re not ready to write flake.nix (perhaps you’re not sure what tools and packages you need), and you want to experiment a bit first.

The command to enter a temporary shell is

nix shell -p installables

Where installables are flakes and other types of packages that you need. (You can learn more about these in the Nix manual.)

Let’s enter a shell with Python so we can test the program.

Next, configure the package. We’ll use Python’s setuptools, but you can use other build tools. For more information on setuptools, see the Setuptools documentation, especially the section on pyproject.toml.

We won’t write flake.nix just yet. First we’ll try building the package manually. (If you didn’t run the nix shell command from earlier, do so now.)

The missing module error happens because we don’t have build available in the temporary shell. We can fix that by adding “build” to the temporary shell. When you need support for both a language and some of its packages, it’s best to use one of the Nix functions that are specific to the programming language and build system. For Python, we can use the withPackages function.

Note that we’re now inside a temporary shell inside the previous temporary shell! To get back to the original shell, we have to exit twice. Alternatively, we could have done exit followed by the second nix-shell command.

After a lot of output messages, the build succeeds.

Now we should write flake.nix. We already know how to write most of the flake from the examples we did earlier. The two parts that will be different are the development shell and the package builder.

Let’s start with the development shell. It seems logical to write something like the following.

Note that we need the parentheses to prevent python.withPackages and the argument from being processed as two separate tokens. Suppose we wanted to work with virtualenv and pip instead of build. We could write something like the following.

For the package builder, we can use the buildPythonApplication function.

If you put all the pieces together, your flake.nix should look something like this.

Let’s try out the new flake.

Nix flakes only “see” files that are part of the repository. We need to add all of the important files to the repo before building or running the flake.

We’ll deal with those warnings later. The important thing for now is that the build succeeded.

Now we can run the program.

By the way, we didn’t need to do nix build earlier. The nix run command will first build the program for us if needed.

We’d like to share this package with others, but first we should do some cleanup. It’s time to deal with those warnings. When the package was built, Nix created a flake.lock file. We need to add this to the repo, and commit all important files.

You can test that your package is properly configured by going to another directory and running it from there.

If you move the project to a public repo, anyone can run it. Recall from the beginning of the tutorial that you were able to run hello-flake directly from my repo with the following command.

Modify the URL accordingly and invite someone else to run your new Python flake.

In this example, we will use a flake defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

In this example, we will use a flake defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

Occasionally you might want to run a short Haskell program that depends on a Haskell library, but you don’t want to bother writing a cabal file.

Example: Access the extra package from the haskellPackages set in the nixpkgs repo.

Occasionally you might want to run a short Python program that depends on a Python library, but you don’t want to bother configuring a builder.

Example: Access the html_sanitizer package from the python3nnPackages set in the nixpkgs repo.

Here’s a demonstration using the shell.

In this example, we will use a flake defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

Line 5 adds hello-flake as an input to this flake. Line 8 allows the output function to reference hello-flake. Line 16 adds hello-flake as a build input for this flake.

Let’s take a closer look at the buildInputs expression from line 16.

Why is the first part hello-flake and the last part hello? The first part refers to the name we assigned in the input section of our flake, and the last part is the name of the package or app we want. (See Section 4.1, “Flake outputs” for how to identify flake outputs.)

Here’s a demonstration using the shell.

Occasionally you might want to run a short Haskell program that depends on a Haskell library, but you don’t want to bother writing a cabal file. In this example, we will access the extra package from the haskellPackages set in the nixpkgs repo.

Line 12 makes a custom GHC that knows about extra, and line 16 makes that custom GHC available in the development environment.

Here’s a short Haskell program that uses the new flake.

Here’s a demonstration using the program.

Set the value of the environment variable FOO to “bar”.

Here’s a demonstration using the shell.

In this example, we will use a nix package (not a flake) defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

The hello-nix repo provides a default.nix. If the derivation in that file allows us to supply our own package set, then our flake can call it to build hello nix. If instead it requires <nixpkgs>, it is not pure and we cannot use it.

For example, if the file begins with an expression such as

then it requires nixpkgs so we cannot use it. Instead, we have to write our own derivation (see Section 10.4.5.2, “If the nix derivation requires nixpkgs”).

Fortunately the file begins with

then it accepts a package set as an argument, only using <nixpkgs> if no argument is provided. We can use it directly to build hello-nix (see Section 10.4.5.1, “If the nix derivation does not require nixpkgs”).

In Section 9.1.3, “Defining the package”, we wrote a shell script that needed access to the Linux cowsay command. To accomplish this, we added a step to the installPhase that modified that script by including the full path to cowsay.

In this example, we will use a flake defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

Line 5 adds hello-flake as an input to this flake, Line 8 allows the output function to reference hello-flake. As expected, we need to add hello-flake as a build input, which we do in line 35. Let’s take a closer look at the buildInputs expression from line 35.

Why is the first part hello-flake and the last part hello? The first part refers to the name we assigned in the input section of our flake, and the last part is the name of the package or app we want. (See Section 4.1, “Flake outputs” for how to identify flake outputs.)

Line 35 does make hello-flake available at build and runtime, but it doesn’t put it on the path, so our hello-again script won’t be able to find it. There are various ways to deal with this problem. In this case we simply edited the script (lines 30-32) as we install it, by specifying the full path to hello-nix.

Here’s a demonstration using the flake.

If you use haskell-flake (see Section 9.2.5, “The Nix flake”) nothing special needs to be added to flake.nix. Simply list your Haskell package dependencies to your cabal file as you normally would.

In this example we will access three Haskell packages (pandoc-linear-table, pandoc-logic-proof, and pandoc-columns) that are defined as flakes on my hard drive. We are using haskell-flake, so the development environment is set up automatically; no need to define devShells.

In this example, we will use a nix package (not a flake) defined in a remote git repo. However, you can use any of the flake reference styles defined in Section 10.1.2, “Run a flake”.

We already covered how to add a non-flake input to a flake and build it in Section 10.4.5, “Access a non-flake package (not in nixpkgs)”; here we will focus on making it available at runtime. We will write a flake to package a very simple shell script. All it does is invoke hello-nix, which is the input we added earlier.

Lines 5-8 and 15 were explained in Section 10.4.5, “Access a non-flake package (not in nixpkgs)”. As expected, we need to add helloNix as a build input, which we do in line 40. That does make it available at build and runtime, but it doesn’t put it on the path, so our hello-again script won’t be able to find it.

There are various ways to deal with this problem. In this case we simply edited the script (lines 34-36) as we install it, by specifying the full path to hello-nix.

Here’s a demonstration using the flake.