mirror of
https://github.com/NixOS/nix-pills
synced 2024-11-10 05:44:14 +00:00
Convert code section to fenced, with the appropriate syntax
This commit is contained in:
Noam Yorav-Raphael
Jan Tojnar
parent
b4eeb0cdfc
commit
1699c9f1db
20 changed files with 1417 additions and 1037 deletions
|
|
@ -48,8 +48,10 @@ What we have is basically a store of all packages (with different versions occup
|
|||
|
||||
In fact, there's no ldconfig cache either. So where does bash find libc?
|
||||
|
||||
```console
|
||||
$ ldd `which bash`
|
||||
libc.so.6 => /nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19/lib/libc.so.6 (0x00007f0248cce000)
|
||||
```
|
||||
|
||||
It turns out that when bash was built, it was built against that specific version of glibc in the Nix store, and at runtime it will require exactly that glibc version.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,9 @@ Note: In a multi-user installation, such as the one used in NixOS, the store is
|
|||
|
||||
Start looking at the output of the install command:
|
||||
|
||||
```
|
||||
copying Nix to /nix/store..........................
|
||||
```
|
||||
|
||||
That's the `/nix/store` we were talking about in the first article. We're copying in the necessary software to bootstrap a Nix system. You can see bash, coreutils, the C compiler toolchain, perl libraries, sqlite and Nix itself with its own tools and libnix.
|
||||
|
||||
|
|
@ -32,7 +34,9 @@ You may have noticed that `/nix/store` can contain not only directories, but als
|
|||
|
||||
Right after copying the store, the installation process initializes a database:
|
||||
|
||||
```
|
||||
initialising Nix database...
|
||||
```
|
||||
|
||||
Yes, Nix also has a database. It's stored under `/nix/var/nix/db`. It is a sqlite database that keeps track of the dependencies between derivations.
|
||||
|
||||
|
|
@ -94,10 +98,12 @@ We'll talk about `manifest.nix` more in the next article.
|
|||
|
||||
More output from the installer:
|
||||
|
||||
```
|
||||
downloading Nix expressions from `http://releases.nixos.org/nixpkgs/nixpkgs-14.10pre46060.a1a2851/nixexprs.tar.xz'...
|
||||
unpacking channels...
|
||||
created 2 symlinks in user environment
|
||||
modifying /home/nix/.profile...
|
||||
```
|
||||
|
||||
Nix expressions are written in the [Nix language](https://nix.dev/tutorials/nix-language) and used to describe packages and how to build them. [Nixpkgs](https://nixos.org/nixpkgs/) is the repository containing all of the expressions: <https://github.com/NixOS/nixpkgs>.
|
||||
|
||||
|
|
@ -119,8 +125,10 @@ You can, but there's a good reason to keep using `/nix` instead of a different d
|
|||
|
||||
You can see for yourself, don't worry if you see multiple bash derivations:
|
||||
|
||||
```console
|
||||
$ ldd /nix/store/*bash*/bin/bash
|
||||
[...]
|
||||
```
|
||||
|
||||
Keeping the store in `/nix` means we can grab the binary cache from nixos.org (just like you grab packages from debian mirrors) otherwise:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,9 @@ In the previous article we created a Nix user, so let's start by switching to it
|
|||
|
||||
If that's not the case:
|
||||
|
||||
```console
|
||||
$ source ~/.nix-profile/etc/profile.d/nix.sh
|
||||
```
|
||||
|
||||
To remind you, `~/.nix-profile/etc` points to the `nix-2.1.3` derivation. At this point, we are in our Nix user profile.
|
||||
|
||||
|
|
@ -20,11 +22,13 @@ Finally something practical! Installation into the Nix environment is an interes
|
|||
|
||||
Back to the installation:
|
||||
|
||||
```console
|
||||
$ nix-env -i hello
|
||||
installing 'hello-2.10'
|
||||
[...]
|
||||
building '/nix/store/0vqw0ssmh6y5zj48yg34gc6macr883xk-user-environment.drv'...
|
||||
created 36 symlinks in user environment
|
||||
```
|
||||
|
||||
Now you can run `hello`. Things to notice:
|
||||
|
||||
|
|
@ -38,15 +42,19 @@ Now you can run `hello`. Things to notice:
|
|||
|
||||
We can list generations without walking through the `/nix` hierarchy:
|
||||
|
||||
```console
|
||||
$ nix-env --list-generations
|
||||
1 2014-07-24 09:23:30
|
||||
2 2014-07-25 08:45:01 (current)
|
||||
```
|
||||
|
||||
Listing installed derivations:
|
||||
|
||||
```console
|
||||
$ nix-env -q
|
||||
nix-2.1.3
|
||||
hello-2.10
|
||||
```
|
||||
|
||||
So, where did `hello` really get installed? `which hello` is `~/.nix-profile/bin/hello` which points to the store. We can also list the derivation paths with `nix-env -q --out-path`. So that's what those derivation paths are called: the **output** of a build.
|
||||
|
||||
|
|
@ -56,13 +64,16 @@ At this point you probably want to run `man` to get some documentation. Even if
|
|||
|
||||
Let's inspect the [profile](https://nixos.org/manual/nix/stable/package-management/profiles.html) a bit:
|
||||
|
||||
```console
|
||||
$ ls -l ~/.nix-profile/
|
||||
dr-xr-xr-x 2 nix nix 4096 Jan 1 1970 bin
|
||||
lrwxrwxrwx 1 nix nix 55 Jan 1 1970 etc -> /nix/store/ig31y9gfpp8pf3szdd7d4sf29zr7igbr-nix-2.1.3/etc
|
||||
[...]
|
||||
```
|
||||
|
||||
Now that's interesting. When only `nix-2.1.3` was installed, `bin` was a symlink to `nix-2.1.3`. Now that we've actually installed some things (`man`, `hello`), it's a real directory, not a symlink.
|
||||
|
||||
```console
|
||||
$ ls -l ~/.nix-profile/bin/
|
||||
[...]
|
||||
man -> /nix/store/83cn9ing5sc6644h50dqzzfxcs07r2jn-man-1.6g/bin/man
|
||||
|
|
@ -71,6 +82,7 @@ Now that's interesting. When only `nix-2.1.3` was installed, `bin` was a symlink
|
|||
[...]
|
||||
hello -> /nix/store/58r35bqb4f3lxbnbabq718svq9i2pda3-hello-2.10/bin/hello
|
||||
[...]
|
||||
```
|
||||
|
||||
Okay, that's clearer now. `nix-env` merged the paths from the installed derivations. `which man` points to the Nix profile, rather than the system `man`, because `~/.nix-profile/bin` is at the head of `$PATH`.
|
||||
|
||||
|
|
@ -78,15 +90,19 @@ Okay, that's clearer now. `nix-env` merged the paths from the installed derivati
|
|||
|
||||
The last command installed `man`. We should be at generation 3, unless you changed something in the middle. Let's say we want to rollback to the old generation:
|
||||
|
||||
```console
|
||||
$ nix-env --rollback
|
||||
switching from generation 3 to 2
|
||||
```
|
||||
|
||||
Now `nix-env -q` does not list `man` anymore. `` ls -l `which man` `` should now be your system copy.
|
||||
|
||||
Enough with the rollback, let's go back to the most recent generation:
|
||||
|
||||
```console
|
||||
$ nix-env -G 3
|
||||
switching from generation 2 to 3
|
||||
```
|
||||
|
||||
I invite you to read the manpage of `nix-env`. `nix-env` requires an operation to perform, then there are common options for all operations, as well as options specific to each operation.
|
||||
|
||||
|
|
@ -100,20 +116,24 @@ To query and manipulate the store, there's the `nix-store` command. We can do so
|
|||
|
||||
To show the direct runtime dependencies of `hello`:
|
||||
|
||||
```console
|
||||
$ nix-store -q --references `which hello`
|
||||
/nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27
|
||||
/nix/store/58r35bqb4f3lxbnbabq718svq9i2pda3-hello-2.10
|
||||
```
|
||||
|
||||
The argument to `nix-store` can be anything as long as it points to the Nix store. It will follow symlinks.
|
||||
|
||||
It may not make sense to you right now, but let's print reverse dependencies of `hello`:
|
||||
|
||||
```console
|
||||
$ nix-store -q --referrers `which hello`
|
||||
/nix/store/58r35bqb4f3lxbnbabq718svq9i2pda3-hello-2.10
|
||||
/nix/store/fhvy2550cpmjgcjcx5rzz328i0kfv3z3-env-manifest.nix
|
||||
/nix/store/yzdk0xvr0b8dcwhi2nns6d75k2ha5208-env-manifest.nix
|
||||
/nix/store/mp987abm20c70pl8p31ljw1r5by4xwfw-user-environment
|
||||
/nix/store/ppr3qbq7fk2m2pa49i2z3i32cvfhsv7p-user-environment
|
||||
```
|
||||
|
||||
Was it what you expected? It turns out that our environments depend upon `hello`. Yes, that means that the environments are in the store, and since they contain symlinks to `hello`, therefore the environment depends upon `hello`.
|
||||
|
||||
|
|
@ -125,15 +145,19 @@ The `manifest.nix` file contains metadata about the environment, such as which d
|
|||
|
||||
The closures of a derivation is a list of all its dependencies, recursively, including absolutely everything necessary to use that derivation.
|
||||
|
||||
```console
|
||||
$ nix-store -qR `which man`
|
||||
[...]
|
||||
```
|
||||
|
||||
Copying all those derivations to the Nix store of another machine makes you able to run `man` out of the box on that other machine. That's the base of deployment using Nix, and you can already foresee the potential when deploying software in the cloud (hint: `nix-copy-closures` and `nix-store --export`).
|
||||
|
||||
A nicer view of the closure:
|
||||
|
||||
```console
|
||||
$ nix-store -q --tree `which man`
|
||||
[...]
|
||||
```
|
||||
|
||||
With the above command, you can find out exactly why a _runtime_ dependency, be it direct or indirect, exists for a given derivation.
|
||||
|
||||
|
|
@ -145,10 +169,12 @@ There isn't anything like `apt` which solves a SAT problem in order to satisfy d
|
|||
|
||||
## Recovering the hard way
|
||||
|
||||
```console
|
||||
$ nix-env -e '*'
|
||||
uninstalling 'hello-2.10'
|
||||
uninstalling 'nix-2.1.3'
|
||||
[...]
|
||||
```
|
||||
|
||||
Oops, that uninstalled all derivations from the environment, including Nix. That means we can't even run `nix-env`, what now?
|
||||
|
||||
|
|
@ -158,18 +184,24 @@ First, pick one `nix-2.1.3` derivation: `ls /nix/store/*nix-2.1.3`, say `/nix/st
|
|||
|
||||
The first option is to rollback:
|
||||
|
||||
```console
|
||||
$ /nix/store/ig31y9gfpp8pf3szdd7d4sf29zr7igbr-nix-2.1.3/bin/nix-env --rollback
|
||||
```
|
||||
|
||||
The second option is to install Nix, thus creating a new generation:
|
||||
|
||||
```console
|
||||
$ /nix/store/ig31y9gfpp8pf3szdd7d4sf29zr7igbr-nix-2.1.3/bin/nix-env -i /nix/store/ig31y9gfpp8pf3szdd7d4sf29zr7igbr-nix-2.1.3/bin/nix-env
|
||||
```
|
||||
|
||||
## Channels
|
||||
|
||||
So where are we getting packages from? We said something about this already in the [second article](02-install-on-your-running.md). There's a list of channels from which we get packages, although usually we use a single channel. The tool to manage channels is [nix-channel](https://nixos.org/manual/nix/stable/command-ref/nix-channel.html).
|
||||
|
||||
```console
|
||||
$ nix-channel --list
|
||||
nixpkgs http://nixos.org/channels/nixpkgs-unstable
|
||||
```
|
||||
|
||||
If you're using NixOS, you may not see any output from the above command (if you're using the default), or you may see a channel whose name begins with "nixos-" instead of "nixpkgs".
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ Nix 2.0 contains a command named `nix repl` which is a simple command line tool
|
|||
|
||||
Launch `nix repl`. First of all, Nix supports basic arithmetic operations: `+`, `-`, `*` and `/`. (To exit `nix repl`, use the command `:q`. Help is available through the `:?` command.)
|
||||
|
||||
```console
|
||||
nix-repl> 1+3
|
||||
4
|
||||
|
||||
|
|
@ -34,19 +35,24 @@ Launch `nix repl`. First of all, Nix supports basic arithmetic operations: `+`,
|
|||
|
||||
nix-repl> 3*2
|
||||
6
|
||||
```
|
||||
|
||||
Attempting to perform division in Nix can lead to some surprises.
|
||||
|
||||
```console
|
||||
nix-repl> 6/3
|
||||
/home/nix/6/3
|
||||
```
|
||||
|
||||
What happened? Recall that Nix is not a general purpose language, it's a domain-specific language for writing packages. Integer division isn't actually that useful when writing package expressions. Nix parsed `6/3` as a relative path to the current directory. To get Nix to perform division instead, leave a space after the `/`. Alternatively, you can use `builtins.div`.
|
||||
|
||||
```console
|
||||
nix-repl> 6/ 3
|
||||
2
|
||||
|
||||
nix-repl> builtins.div 6 3
|
||||
2
|
||||
```
|
||||
|
||||
Other operators are `||`, `&&` and `!` for booleans, and relational operators such as `!=`, `==`, `<`, `>`, `<=`, `>=`. In Nix, `<`, `>`, `<=` and `>=` are not much used. There are also other operators we will see in the course of this series.
|
||||
|
||||
|
|
@ -62,10 +68,12 @@ Not all urls or paths can be parsed this way. If a syntax error occurs, it's sti
|
|||
|
||||
There's not much to say here, except that dash (`-`) is allowed in identifiers. That's convenient since many packages use dash in their names. In fact:
|
||||
|
||||
```console
|
||||
nix-repl> a-b
|
||||
error: undefined variable `a-b' at (string):1:1
|
||||
nix-repl> a - b
|
||||
error: undefined variable `a' at (string):1:1
|
||||
```
|
||||
|
||||
As you can see, `a-b` is parsed as identifier, not as a subtraction.
|
||||
|
||||
|
|
@ -73,15 +81,18 @@ As you can see, `a-b` is parsed as identifier, not as a subtraction.
|
|||
|
||||
It's important to understand the syntax for strings. When learning to read Nix expressions, you may find dollars (`$`) ambiguous, but they are very important . Strings are enclosed by double quotes (`"`), or two single quotes (`''`).
|
||||
|
||||
```console
|
||||
nix-repl> "foo"
|
||||
"foo"
|
||||
nix-repl> ''foo''
|
||||
"foo"
|
||||
```
|
||||
|
||||
In other languages like Python you can also use single quotes for strings (e.g. `'foo'`), but not in Nix.
|
||||
|
||||
It's possible to [interpolate](https://nixos.org/manual/nix/stable/expressions/language-values.html) whole Nix expressions inside strings with the `${...}` syntax and only that syntax, not `$foo` or `{$foo}` or anything else.
|
||||
|
||||
```console
|
||||
nix-repl> foo = "strval"
|
||||
nix-repl> "$foo"
|
||||
"$foo"
|
||||
|
|
@ -89,6 +100,7 @@ It's possible to [interpolate](https://nixos.org/manual/nix/stable/expressions/l
|
|||
"strval"
|
||||
nix-repl> "${2+3}"
|
||||
error: cannot coerce an integer to a string, at (string):1:2
|
||||
```
|
||||
|
||||
Note: ignore the `foo = "strval"` assignment, special syntax in `nix repl`.
|
||||
|
||||
|
|
@ -96,24 +108,30 @@ As said previously, you cannot mix integers and strings. You need to explicitly
|
|||
|
||||
Using the syntax with two single quotes is useful for writing double quotes inside strings without needing to escape them:
|
||||
|
||||
```console
|
||||
nix-repl> ''test " test''
|
||||
"test " test"
|
||||
"test \" test"
|
||||
nix-repl> ''${foo}''
|
||||
"strval"
|
||||
```
|
||||
|
||||
Escaping `${...}` within double quoted strings is done with the backslash. Within two single quotes, it's done with `''`:
|
||||
|
||||
```console
|
||||
nix-repl> "\${foo}"
|
||||
"${foo}"
|
||||
nix-repl> ''test ''${foo} test''
|
||||
"test ${foo} test"
|
||||
```
|
||||
|
||||
## Lists
|
||||
|
||||
Lists are a sequence of expressions delimited by space (_not_ comma):
|
||||
|
||||
```console
|
||||
nix-repl> [ 2 "foo" true (2+3) ]
|
||||
[ 2 "foo" true 5 ]
|
||||
```
|
||||
|
||||
Lists, like everything else in Nix, are immutable. Adding or removing elements from a list is possible, but will return a new list.
|
||||
|
||||
|
|
@ -121,30 +139,38 @@ Lists, like everything else in Nix, are immutable. Adding or removing elements f
|
|||
|
||||
An attribute set is an association between string keys and Nix values. Keys can only be strings. When writing attribute sets you can also use unquoted identifiers as keys.
|
||||
|
||||
```console
|
||||
nix-repl> s = { foo = "bar"; a-b = "baz"; "123" = "num"; }
|
||||
nix-repl> s
|
||||
{ "123" = "num"; a-b = "baz"; foo = "bar"; }
|
||||
```
|
||||
|
||||
For those reading Nix expressions from nixpkgs: do not confuse attribute sets with argument sets used in functions.
|
||||
|
||||
To access elements in the attribute set:
|
||||
|
||||
```console
|
||||
nix-repl> s.a-b
|
||||
"baz"
|
||||
nix-repl> s."123"
|
||||
"num"
|
||||
```
|
||||
|
||||
Yes, you can use strings to address keys which aren't valid identifiers.
|
||||
|
||||
Inside an attribute set you cannot normally refer to elements of the same attribute set:
|
||||
|
||||
```console
|
||||
nix-repl> { a = 3; b = a+4; }
|
||||
error: undefined variable `a' at (string):1:10
|
||||
```
|
||||
|
||||
To do so, use [recursive attribute sets](https://nixos.org/manual/nix/stable/expressions/language-constructs.html#recursive-sets):
|
||||
|
||||
```console
|
||||
nix-repl> rec { a = 3; b = a+4; }
|
||||
{ a = 3; b = 7; }
|
||||
```
|
||||
|
||||
This is very convenient when defining packages, which tend to be recursive attribute sets.
|
||||
|
||||
|
|
@ -152,10 +178,12 @@ This is very convenient when defining packages, which tend to be recursive attri
|
|||
|
||||
These are expressions, not statements.
|
||||
|
||||
```console
|
||||
nix-repl> a = 3
|
||||
nix-repl> b = 4
|
||||
nix-repl> if a > b then "yes" else "no"
|
||||
"no"
|
||||
```
|
||||
|
||||
You can't have only the `then` branch, you must specify also the `else` branch, because an expression must have a value in all cases.
|
||||
|
||||
|
|
@ -163,35 +191,47 @@ You can't have only the `then` branch, you must specify also the `else` branch,
|
|||
|
||||
This kind of expression is used to define local variables for inner expressions.
|
||||
|
||||
```console
|
||||
nix-repl> let a = "foo"; in a
|
||||
"foo"
|
||||
```
|
||||
|
||||
The syntax is: first assign variables, then `in`, then an expression which can use the defined variables. The value of the whole `let` expression will be the value of the expression after the `in`.
|
||||
|
||||
```console
|
||||
nix-repl> let a = 3; b = 4; in a + b
|
||||
7
|
||||
```
|
||||
|
||||
Let's write two `let` expressions, one inside the other:
|
||||
|
||||
```console
|
||||
nix-repl> let a = 3; in let b = 4; in a + b
|
||||
7
|
||||
```
|
||||
|
||||
With `let` you cannot assign twice to the same variable. However, you can shadow outer variables:
|
||||
|
||||
```console
|
||||
nix-repl> let a = 3; a = 8; in a
|
||||
error: attribute `a' at (string):1:12 already defined at (string):1:5
|
||||
nix-repl> let a = 3; in let a = 8; in a
|
||||
8
|
||||
```
|
||||
|
||||
You cannot refer to variables in a `let` expression outside of it:
|
||||
|
||||
```console
|
||||
nix-repl> let a = (let c = 3; in c); in c
|
||||
error: undefined variable `c' at (string):1:31
|
||||
```
|
||||
|
||||
You can refer to variables in the `let` expression when assigning variables, like with recursive attribute sets:
|
||||
|
||||
```console
|
||||
nix-repl> let a = 4; b = a + 5; in b
|
||||
9
|
||||
```
|
||||
|
||||
So beware when you want to refer to a variable from the outer scope, but it's also defined in the current let expression. The same applies to recursive attribute sets.
|
||||
|
||||
|
|
@ -199,25 +239,31 @@ So beware when you want to refer to a variable from the outer scope, but it's al
|
|||
|
||||
This kind of expression is something you rarely see in other languages. You can think of it like a more granular version of `using` from C++, or `from module import *` from Python. You decide per-expression when to include symbols into the scope.
|
||||
|
||||
```console
|
||||
nix-repl> longName = { a = 3; b = 4; }
|
||||
nix-repl> longName.a + longName.b
|
||||
7
|
||||
nix-repl> with longName; a + b
|
||||
7
|
||||
```
|
||||
|
||||
That's it, it takes an attribute set and includes symbols from it in the scope of the inner expression. Of course, only valid identifiers from the keys of the set will be included. If a symbol exists in the outer scope and would also be introduced by the `with`, it will _not_ be shadowed. You can however still refer to the attribute set:
|
||||
|
||||
```console
|
||||
nix-repl> let a = 10; in with longName; a + b
|
||||
14
|
||||
nix-repl> let a = 10; in with longName; longName.a + b
|
||||
7
|
||||
```
|
||||
|
||||
## Laziness
|
||||
|
||||
Nix evaluates expressions only when needed. This is a great feature when working with packages.
|
||||
|
||||
```console
|
||||
nix-repl> let a = builtins.div 4 0; b = 6; in b
|
||||
6
|
||||
```
|
||||
|
||||
Since `a` is not needed, there's no error about division by zero, because the expression is not in need to be evaluated. That's why we can have all the packages defined on demand, yet have access to specific packages very quickly.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,18 +10,22 @@ I remind you how to enter the Nix environment: `source ~/.nix-profile/etc/profil
|
|||
|
||||
Functions are anonymous (lambdas), and only have a single parameter. The syntax is extremely simple. Type the parameter name, then "`:`", then the body of the function.
|
||||
|
||||
```console
|
||||
nix-repl> x: x*2
|
||||
«lambda»
|
||||
```
|
||||
|
||||
So here we defined a function that takes a parameter `x`, and returns `x*2`. The problem is that we cannot use it in any way, because it's unnamed... joke!
|
||||
|
||||
We can store functions in variables.
|
||||
|
||||
```console
|
||||
nix-repl> double = x: x*2
|
||||
nix-repl> double
|
||||
«lambda»
|
||||
nix-repl> double 3
|
||||
6
|
||||
```
|
||||
|
||||
As usual, please ignore the special syntax for assignments inside `nix repl`. So, we defined a function `x: x*2` that takes one parameter `x`, and returns `x*2`. This function is then assigned to the variable `double`. Finally we did our first function call: `double 3`.
|
||||
|
||||
|
|
@ -33,6 +37,7 @@ In summary: to call a function, name the variable, then space, then the argument
|
|||
|
||||
How do we create a function that accepts more than one parameter? For people not used to functional programming, this may take a while to grasp. Let's do it step by step.
|
||||
|
||||
```console
|
||||
nix-repl> mul = a: (b: a*b)
|
||||
nix-repl> mul
|
||||
«lambda»
|
||||
|
|
@ -40,11 +45,13 @@ How do we create a function that accepts more than one parameter? For people not
|
|||
«lambda»
|
||||
nix-repl> (mul 3) 4
|
||||
12
|
||||
```
|
||||
|
||||
We defined a function that takes the parameter `a`, the body returns another function. This other function takes a parameter `b` and returns `a*b`. Therefore, calling `mul 3` returns this kind of function: `b: 3*b`. In turn, we call the returned function with `4`, and get the expected result.
|
||||
|
||||
You don't have to use parentheses at all, Nix has sane priorities when parsing the code:
|
||||
|
||||
```console
|
||||
nix-repl> mul = a: b: a*b
|
||||
nix-repl> mul
|
||||
«lambda»
|
||||
|
|
@ -54,16 +61,19 @@ You don't have to use parentheses at all, Nix has sane priorities when parsing t
|
|||
12
|
||||
nix-repl> mul (6+7) (8+9)
|
||||
221
|
||||
```
|
||||
|
||||
Much more readable, you don't even notice that functions only receive one argument. Since the argument is separated by a space, to pass more complex expressions you need parentheses. In other common languages you would write `mul(6+7, 8+9)`.
|
||||
|
||||
Given that functions have only one parameter, it is straightforward to use **partial application**:
|
||||
|
||||
```console
|
||||
nix-repl> foo = mul 3
|
||||
nix-repl> foo 4
|
||||
12
|
||||
nix-repl> foo 5
|
||||
15
|
||||
```
|
||||
|
||||
We stored the function returned by `mul 3` into a variable foo, then reused it.
|
||||
|
||||
|
|
@ -71,22 +81,26 @@ We stored the function returned by `mul 3` into a variable foo, then reused it.
|
|||
|
||||
Now this is a very cool feature of Nix. It is possible to pattern match over a set in the parameter. We write an alternative version of `mul = a: b: a*b` first by using a set as argument, then using pattern matching.
|
||||
|
||||
```console
|
||||
nix-repl> mul = s: s.a*s.b
|
||||
nix-repl> mul { a = 3; b = 4; }
|
||||
12
|
||||
nix-repl> mul = { a, b }: a*b
|
||||
nix-repl> mul { a = 3; b = 4; }
|
||||
12
|
||||
```
|
||||
|
||||
In the first case we defined a function that accepts a single parameter. We then access attributes `a` and `b` from the given set. Note how the parentheses-less syntax for function calls is very elegant in this case, instead of doing `mul({ a=3; b=4; })` in other languages.
|
||||
|
||||
In the second case we defined an argument set. It's like defining a set, except without values. We require that the passed set contains the keys `a` and `b`. Then we can use those `a` and `b` in the function body directly.
|
||||
|
||||
```console
|
||||
nix-repl> mul = { a, b }: a*b
|
||||
nix-repl> mul { a = 3; b = 4; c = 6; }
|
||||
error: anonymous function at (string):1:2 called with unexpected argument `c', at (string):1:1
|
||||
nix-repl> mul { a = 3; }
|
||||
error: anonymous function at (string):1:2 called without required argument `b', at (string):1:1
|
||||
```
|
||||
|
||||
Only a set with exactly the attributes required by the function is accepted, nothing more, nothing less.
|
||||
|
||||
|
|
@ -94,22 +108,28 @@ Only a set with exactly the attributes required by the function is accepted, not
|
|||
|
||||
It is possible to specify **default values** of attributes in the argument set:
|
||||
|
||||
```console
|
||||
nix-repl> mul = { a, b ? 2 }: a*b
|
||||
nix-repl> mul { a = 3; }
|
||||
6
|
||||
nix-repl> mul { a = 3; b = 4; }
|
||||
12
|
||||
```
|
||||
|
||||
Also you can allow passing more attributes (**variadic**) than the expected ones:
|
||||
|
||||
```console
|
||||
nix-repl> mul = { a, b, ... }: a*b
|
||||
nix-repl> mul { a = 3; b = 4; c = 2; }
|
||||
```
|
||||
|
||||
However, in the function body you cannot access the "c" attribute. The solution is to give a name to the given set with the **@-pattern**:
|
||||
|
||||
```console
|
||||
nix-repl> mul = s@{ a, b, ... }: a*b*s.c
|
||||
nix-repl> mul { a = 3; b = 4; c = 2; }
|
||||
24
|
||||
```
|
||||
|
||||
That's it, you give a name to the whole parameter with name@ before the set pattern.
|
||||
|
||||
|
|
@ -133,43 +153,59 @@ Let's start with the bare metal.
|
|||
|
||||
`a.nix`:
|
||||
|
||||
```nix
|
||||
3
|
||||
```
|
||||
|
||||
`b.nix`:
|
||||
|
||||
```nix
|
||||
4
|
||||
```
|
||||
|
||||
`mul.nix`:
|
||||
|
||||
```nix
|
||||
a: b: a*b
|
||||
```
|
||||
|
||||
```console
|
||||
nix-repl> a = import ./a.nix
|
||||
nix-repl> b = import ./b.nix
|
||||
nix-repl> mul = import ./mul.nix
|
||||
nix-repl> mul a b
|
||||
12
|
||||
```
|
||||
|
||||
Yes it's really that simple. You import a file, and it gets parsed as an expression. Note that the scope of the imported file does not inherit the scope of the importer.
|
||||
|
||||
`test.nix`:
|
||||
|
||||
```nix
|
||||
x
|
||||
```
|
||||
|
||||
```console
|
||||
nix-repl> let x = 5; in import ./test.nix
|
||||
error: undefined variable `x' at /home/lethal/test.nix:1:1
|
||||
```
|
||||
|
||||
So how do we pass information to the module? Use functions, like we did with `mul.nix`. A more complex example:
|
||||
|
||||
`test.nix`:
|
||||
|
||||
```nix
|
||||
{ a, b ? 3, trueMsg ? "yes", falseMsg ? "no" }:
|
||||
if a > b
|
||||
then builtins.trace trueMsg true
|
||||
else builtins.trace falseMsg false
|
||||
```
|
||||
|
||||
```console
|
||||
nix-repl> import ./test.nix { a = 5; trueMsg = "ok"; }
|
||||
trace: ok
|
||||
true
|
||||
```
|
||||
|
||||
Explaining:
|
||||
|
||||
|
|
|
|||
|
|
@ -22,14 +22,18 @@ The `derivation` function receives a set as its first argument. This set require
|
|||
|
||||
First of all, what's the name of our system as seen by nix?
|
||||
|
||||
```console
|
||||
nix-repl> builtins.currentSystem
|
||||
"x86_64-linux"
|
||||
```
|
||||
|
||||
Let's try to fake the name of the system:
|
||||
|
||||
```console
|
||||
nix-repl> d = derivation { name = "myname"; builder = "mybuilder"; system = "mysystem"; }
|
||||
nix-repl> d
|
||||
«derivation /nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv»
|
||||
```
|
||||
|
||||
Oh oh, what's that? Did it build the derivation? No it didn't, but it **did create the .drv file**. `nix repl` does not build derivations unless you tell it to do so.
|
||||
|
||||
|
|
@ -55,7 +59,7 @@ Note: If your version of nix doesn't have `nix derivation show`, use `nix show-d
|
|||
|
||||
</div>
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show /nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv
|
||||
{
|
||||
"/nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv": {
|
||||
|
|
@ -103,6 +107,7 @@ Back to our fake derivation.
|
|||
|
||||
Let's build our really fake derivation:
|
||||
|
||||
```console
|
||||
nix-repl> d = derivation { name = "myname"; builder = "mybuilder"; system = "mysystem"; }
|
||||
nix-repl> :b d
|
||||
[...]
|
||||
|
|
@ -110,21 +115,26 @@ Let's build our really fake derivation:
|
|||
/nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv
|
||||
building path(s) `/nix/store/40s0qmrfb45vlh6610rk29ym318dswdr-myname'
|
||||
error: a `mysystem' is required to build `/nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv', but I am a `x86_64-linux'
|
||||
```
|
||||
|
||||
The `:b` is a `nix repl` specific command to build a derivation. You can see more commands with `:?` . So in the output you can see that it takes the `.drv` as information on how to build the derivation. Then it says it's trying to produce our out path. Finally the error we were waiting for: that derivation can't be built on our system.
|
||||
|
||||
We're doing the build inside `nix repl`, but what if we don't want to use `nix repl`? You can **realise** a `.drv` with:
|
||||
|
||||
```console
|
||||
$ nix-store -r /nix/store/z3hhlxbckx4g3n9sw91nnvlkjvyw754p-myname.drv
|
||||
```
|
||||
|
||||
You will get the same output as before.
|
||||
|
||||
Let's fix the system attribute:
|
||||
|
||||
```console
|
||||
nix-repl> d = derivation { name = "myname"; builder = "mybuilder"; system = builtins.currentSystem; }
|
||||
nix-repl> :b d
|
||||
[...]
|
||||
build error: invalid file name `mybuilder'
|
||||
```
|
||||
|
||||
A step forward: of course, that `mybuilder` executable does not really exist. Stop for a moment.
|
||||
|
||||
|
|
@ -132,23 +142,29 @@ A step forward: of course, that `mybuilder` executable does not really exist. St
|
|||
|
||||
It is useful to start by inspecting the return value from the derivation function. In this case, the returned value is a plain set:
|
||||
|
||||
```console
|
||||
nix-repl> d = derivation { name = "myname"; builder = "mybuilder"; system = "mysystem"; }
|
||||
nix-repl> builtins.isAttrs d
|
||||
true
|
||||
nix-repl> builtins.attrNames d
|
||||
[ "all" "builder" "drvAttrs" "drvPath" "name" "out" "outPath" "outputName" "system" "type" ]
|
||||
```
|
||||
|
||||
You can guess what `builtins.isAttrs` does; it returns true if the argument is a set. While `builtins.attrNames` returns a list of keys of the given set. Some kind of reflection, you might say.
|
||||
|
||||
Start from drvAttrs:
|
||||
|
||||
```console
|
||||
nix-repl> d.drvAttrs
|
||||
{ builder = "mybuilder"; name = "myname"; system = "mysystem"; }
|
||||
```
|
||||
|
||||
That's basically the input we gave to the derivation function. Also the `d.name`, `d.system` and `d.builder` attributes are exactly the ones we gave as input.
|
||||
|
||||
```console
|
||||
nix-repl> (d == d.out)
|
||||
true
|
||||
```
|
||||
|
||||
So out is just the derivation itself, it seems weird but the reason is that we only have one output from the derivation. That's also the reason why `d.all` is a singleton. We'll see multiple outputs later.
|
||||
|
||||
|
|
@ -156,8 +172,10 @@ The `d.drvPath` is the path of the `.drv` file: `/nix/store/z3hhlxbckx4g3n9sw91n
|
|||
|
||||
Something interesting is the `type` attribute. It's `"derivation"`. Nix does add a little of magic to sets with type derivation, but not that much. To help you understand, you can create yourself a set with that type, it's a simple set:
|
||||
|
||||
```console
|
||||
nix-repl> { type = "derivation"; }
|
||||
«derivation ???»
|
||||
```
|
||||
|
||||
Of course it has no other information, so Nix doesn't know what to say :-) But you get it, the `type = "derivation"` is just a convention for Nix and for us to understand the set is a derivation.
|
||||
|
||||
|
|
@ -169,53 +187,67 @@ The `outPath` attribute is the build path in the nix store: `/nix/store/40s0qmrf
|
|||
|
||||
Just like dependencies in other package managers, how do we refer to other packages? How do we refer to other derivations in terms of files on the disk? We use the `outPath`. The `outPath` describes the location of the files of that derivation. To make it more convenient, Nix is able to do a conversion from a derivation set to a string.
|
||||
|
||||
```console
|
||||
nix-repl> d.outPath
|
||||
"/nix/store/40s0qmrfb45vlh6610rk29ym318dswdr-myname"
|
||||
nix-repl> builtins.toString d
|
||||
"/nix/store/40s0qmrfb45vlh6610rk29ym318dswdr-myname"
|
||||
```
|
||||
|
||||
Nix does the "set to string conversion" as long as there is the `outPath` attribute (much like a toString method in other languages):
|
||||
|
||||
```console
|
||||
nix-repl> builtins.toString { outPath = "foo"; }
|
||||
"foo"
|
||||
nix-repl> builtins.toString { a = "b"; }
|
||||
error: cannot coerce a set to a string, at (string):1:1
|
||||
```
|
||||
|
||||
Say we want to use binaries from coreutils (ignore the nixpkgs etc.):
|
||||
|
||||
```console
|
||||
nix-repl> :l <nixpkgs>
|
||||
Added 3950 variables.
|
||||
nix-repl> coreutils
|
||||
«derivation /nix/store/1zcs1y4n27lqs0gw4v038i303pb89rw6-coreutils-8.21.drv»
|
||||
nix-repl> builtins.toString coreutils
|
||||
"/nix/store/8w4cbiy7wqvaqsnsnb3zvabq1cp2zhyz-coreutils-8.21"
|
||||
```
|
||||
|
||||
Apart from the nixpkgs stuff, just think we added to the scope a series of variables. One of them is coreutils. It is the derivation of the coreutils package you all know of from other Linux distributions. It contains basic binaries for GNU/Linux systems (you may have multiple derivations of coreutils in the nix store, no worries):
|
||||
|
||||
```console
|
||||
$ ls /nix/store/*coreutils*/bin
|
||||
[...]
|
||||
```
|
||||
|
||||
I remind you, inside strings it's possible to interpolate Nix expressions with `${...}`:
|
||||
|
||||
```console
|
||||
nix-repl> "${d}"
|
||||
"/nix/store/40s0qmrfb45vlh6610rk29ym318dswdr-myname"
|
||||
nix-repl> "${coreutils}"
|
||||
"/nix/store/8w4cbiy7wqvaqsnsnb3zvabq1cp2zhyz-coreutils-8.21"
|
||||
```
|
||||
|
||||
That's very convenient, because then we could refer to e.g. the bin/true binary like this:
|
||||
|
||||
```console
|
||||
nix-repl> "${coreutils}/bin/true"
|
||||
"/nix/store/8w4cbiy7wqvaqsnsnb3zvabq1cp2zhyz-coreutils-8.21/bin/true"
|
||||
```
|
||||
|
||||
## An almost working derivation
|
||||
|
||||
In the previous attempt we used a fake builder, `mybuilder` which obviously does not exist. But we can use for example bin/true, which always exits with 0 (success).
|
||||
|
||||
```console
|
||||
nix-repl> :l <nixpkgs>
|
||||
nix-repl> d = derivation { name = "myname"; builder = "${coreutils}/bin/true"; system = builtins.currentSystem; }
|
||||
nix-repl> :b d
|
||||
[...]
|
||||
builder for `/nix/store/qyfrcd53wmc0v22ymhhd5r6sz5xmdc8a-myname.drv' failed to produce output path `/nix/store/ly2k1vswbfmswr33hw0kf0ccilrpisnk-myname'
|
||||
```
|
||||
|
||||
Another step forward, it executed the builder (bin/true), but the builder did not create the out path of course, it just exited with 0.
|
||||
|
||||
|
|
@ -223,7 +255,7 @@ Obvious note: every time we change the derivation, a new hash is created.
|
|||
|
||||
Let's examine the new `.drv` now that we referred to another derivation:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show /nix/store/qyfrcd53wmc0v22ymhhd5r6sz5xmdc8a-myname.drv
|
||||
{
|
||||
"/nix/store/qyfrcd53wmc0v22ymhhd5r6sz5xmdc8a-myname.drv": {
|
||||
|
|
|
|||
|
|
@ -20,8 +20,10 @@ In summary, we want the builder to be bash, and pass it an argument, `builder.sh
|
|||
|
||||
First of all, let's write our `builder.sh` in the current directory:
|
||||
|
||||
```sh
|
||||
declare -xp
|
||||
echo foo > $out
|
||||
```
|
||||
|
||||
The command `declare -xp` lists exported variables (`declare` is a builtin bash function). As we covered in the previous pill, Nix computes the output path of the derivation. The resulting `.drv` file contains a list of environment variables passed to the builder. One of these is `$out`.
|
||||
|
||||
|
|
@ -31,7 +33,7 @@ In addition, we print out the environment variables during the build process. We
|
|||
|
||||
Like for coreutils in the previous pill, we get a blessed bash for free from our magic nixpkgs stuff:
|
||||
|
||||
```
|
||||
```console
|
||||
nix-repl> :l <nixpkgs>
|
||||
Added 3950 variables.
|
||||
nix-repl> "${bash}"
|
||||
|
|
@ -40,7 +42,7 @@ nix-repl> "${bash}"
|
|||
|
||||
So with the usual trick, we can refer to bin/bash and create our derivation:
|
||||
|
||||
```
|
||||
```console
|
||||
nix-repl> d = derivation { name = "foo"; builder = "${bash}/bin/bash"; args = [ ./builder.sh ]; system = builtins.currentSystem; }
|
||||
nix-repl> :b d
|
||||
[1 built, 0.0 MiB DL]
|
||||
|
|
@ -57,7 +59,7 @@ Note that we used `./builder.sh` and not `"./builder.sh"`. This way, it is parse
|
|||
|
||||
We can use `nix-store --read-log` to see the logs our builder produced:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix-store --read-log /nix/store/gczb4qrag22harvv693wwnflqy7lx5pb-foo
|
||||
declare -x HOME="/homeless-shelter"
|
||||
declare -x NIX_BUILD_CORES="4"
|
||||
|
|
@ -98,7 +100,7 @@ In terms of autotools, `$out` will be the `--prefix` path. Yes, not the make `DE
|
|||
|
||||
We added something else to the derivation this time: the args attribute. Let's see how this changed the .drv compared to the previous pill:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show /nix/store/i76pr1cz0za3i9r6xq518bqqvd2raspw-foo.drv
|
||||
{
|
||||
"/nix/store/i76pr1cz0za3i9r6xq518bqqvd2raspw-foo.drv": {
|
||||
|
|
@ -138,19 +140,23 @@ Given that `builder.sh` is a plain file, it has no .drv associated with it. The
|
|||
|
||||
Start off by writing a simple C program called `simple.c`:
|
||||
|
||||
```c
|
||||
void main() {
|
||||
puts("Simple!");
|
||||
}
|
||||
```
|
||||
|
||||
And its `simple_builder.sh`:
|
||||
|
||||
```sh
|
||||
export PATH="$coreutils/bin:$gcc/bin"
|
||||
mkdir $out
|
||||
gcc -o $out/simple $src
|
||||
```
|
||||
|
||||
Don't worry too much about where those variables come from yet; let's write the derivation and build it:
|
||||
|
||||
```
|
||||
```console
|
||||
nix-repl> :l <nixpkgs>
|
||||
nix-repl> simple = derivation { name = "simple"; builder = "${bash}/bin/bash"; args = [ ./simple_builder.sh ]; gcc = gcc; coreutils = coreutils; src = ./simple.c; system = builtins.currentSystem; }
|
||||
nix-repl> :b simple
|
||||
|
|
@ -179,6 +185,7 @@ We then create `$out` as a directory and place the binary inside it. Note that g
|
|||
|
||||
Drop out of nix repl and write a file `simple.nix`:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
in
|
||||
|
|
@ -191,6 +198,7 @@ Drop out of nix repl and write a file `simple.nix`:
|
|||
src = ./simple.c;
|
||||
system = builtins.currentSystem;
|
||||
}
|
||||
```
|
||||
|
||||
Now you can build it with `nix-build simple.nix`. This will create a symlink `result` in the current directory, pointing to the out path of the derivation.
|
||||
|
||||
|
|
@ -210,6 +218,7 @@ The value returned by the nixpkgs function is a set; more specifically, it's a s
|
|||
|
||||
Below is a revised version of the `simple.nix` file, using the `inherit` keyword:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
in
|
||||
|
|
@ -221,6 +230,7 @@ Below is a revised version of the `simple.nix` file, using the `inherit` keyword
|
|||
src = ./simple.c;
|
||||
system = builtins.currentSystem;
|
||||
}
|
||||
```
|
||||
|
||||
Here we also take the opportunity to introduce the [`inherit` keyword](https://nixos.org/manual/nix/stable/expressions/language-constructs.html#inheriting-attributes). `inherit foo;` is equivalent to `foo = foo;`. Similarly, `inherit gcc coreutils;` is equivalent to `gcc = gcc; coreutils = coreutils;`. Lastly, `inherit (pkgs) gcc coreutils;` is equivalent to `gcc = pkgs.gcc; coreutils = pkgs.coreutils;`.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,15 +12,18 @@ In the previous pill we packaged a simple .c file, which was being compiled with
|
|||
|
||||
Let's create a builder script for GNU hello world, hello_builder.sh:
|
||||
|
||||
```sh
|
||||
export PATH="$gnutar/bin:$gcc/bin:$gnumake/bin:$coreutils/bin:$gawk/bin:$gzip/bin:$gnugrep/bin:$gnused/bin:$bintools/bin"
|
||||
tar -xzf $src
|
||||
cd hello-2.12.1
|
||||
./configure --prefix=$out
|
||||
make
|
||||
make install
|
||||
```
|
||||
|
||||
And the derivation hello.nix:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
in
|
||||
|
|
@ -42,12 +45,14 @@ And the derivation hello.nix:
|
|||
src = ./hello-2.12.1.tar.gz;
|
||||
system = builtins.currentSystem;
|
||||
}
|
||||
```
|
||||
|
||||
<div class="info">
|
||||
<h4>Nix on darwin</h4>
|
||||
|
||||
Darwin (i.e. macOS) builds typically use `clang` rather than `gcc` for a C compiler. We can adapt this early example for darwin by using this modified version of `hello.nix`:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
in
|
||||
|
|
@ -69,6 +74,7 @@ Darwin (i.e. macOS) builds typically use `clang` rather than `gcc` for a C compi
|
|||
src = ./hello-2.12.1.tar.gz;
|
||||
system = builtins.currentSystem;
|
||||
}
|
||||
```
|
||||
|
||||
Later, we will show how Nix can automatically handle these differences. For now, please be just aware that changes similar to the above may be needed in what follows.
|
||||
|
||||
|
|
@ -82,6 +88,7 @@ Please note the `--prefix=$out` we were talking about in the [previous pill](07-
|
|||
|
||||
Let's create a generic `builder.sh` for autotools projects:
|
||||
|
||||
```sh
|
||||
set -e
|
||||
unset PATH
|
||||
for p in $buildInputs; do
|
||||
|
|
@ -100,6 +107,7 @@ Let's create a generic `builder.sh` for autotools projects:
|
|||
./configure --prefix=$out
|
||||
make
|
||||
make install
|
||||
```
|
||||
|
||||
What do we do here?
|
||||
|
||||
|
|
@ -119,6 +127,7 @@ As you can see, there's no reference to "hello" in the builder anymore. It still
|
|||
|
||||
Now let's rewrite `hello.nix`:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
in
|
||||
|
|
@ -140,24 +149,29 @@ Now let's rewrite `hello.nix`:
|
|||
src = ./hello-2.12.1.tar.gz;
|
||||
system = builtins.currentSystem;
|
||||
}
|
||||
```
|
||||
|
||||
All clear, except that buildInputs. However it's easier than any black magic you are thinking of at this moment.
|
||||
|
||||
Nix is able to convert a list to a string. It first converts the elements to strings, and then concatenates them separated by a space:
|
||||
|
||||
```console
|
||||
nix-repl> builtins.toString 123
|
||||
"123"
|
||||
nix-repl> builtins.toString [ 123 456 ]
|
||||
"123 456"
|
||||
```
|
||||
|
||||
Recall that derivations can be converted to a string, hence:
|
||||
|
||||
```console
|
||||
nix-repl> :l <nixpkgs>
|
||||
Added 3950 variables.
|
||||
nix-repl> builtins.toString gnugrep
|
||||
"/nix/store/g5gdylclfh6d224kqh9sja290pk186xd-gnugrep-2.14"
|
||||
nix-repl> builtins.toString [ gnugrep gnused ]
|
||||
"/nix/store/g5gdylclfh6d224kqh9sja290pk186xd-gnugrep-2.14 /nix/store/krgdc4sknzpw8iyk9p20lhqfd52kjmg0-gnused-4.2.2"
|
||||
```
|
||||
|
||||
Simple! The buildInputs variable is a string with out paths separated by space, perfect for bash usage in a for loop.
|
||||
|
||||
|
|
@ -169,6 +183,7 @@ A natural approach would be to create a function that accepts an attribute set,
|
|||
|
||||
Create `autotools.nix`:
|
||||
|
||||
```nix
|
||||
pkgs: attrs:
|
||||
let
|
||||
defaultAttrs = {
|
||||
|
|
@ -190,6 +205,7 @@ Create `autotools.nix`:
|
|||
};
|
||||
in
|
||||
derivation (defaultAttrs // attrs)
|
||||
```
|
||||
|
||||
Ok now we have to remember a little about [Nix functions](05-functions-and-imports.md). The whole nix expression of this `autotools.nix` file will evaluate to a function. This function accepts a parameter `pkgs`, then returns a function which accepts a parameter `attrs`.
|
||||
|
||||
|
|
@ -207,15 +223,18 @@ So we use `defaultAttrs` as base set, and add (or override) the attributes from
|
|||
|
||||
A couple of examples ought to be enough to clear out the behavior of the operator:
|
||||
|
||||
```console
|
||||
nix-repl> { a = "b"; } // { c = "d"; }
|
||||
{ a = "b"; c = "d"; }
|
||||
nix-repl> { a = "b"; } // { a = "c"; }
|
||||
{ a = "c"; }
|
||||
```
|
||||
|
||||
**Exercise:** Complete the new `builder.sh` by adding `$baseInputs` in the `for` loop together with `$buildInputs`. As you noticed, we passed that new variable in the derivation. Instead of merging buildInputs with the base ones, we prefer to preserve buildInputs as seen by the caller, so we keep them separated. Just a matter of choice.
|
||||
|
||||
Then we rewrite `hello.nix` as follows:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
mkDerivation = import ./autotools.nix pkgs;
|
||||
|
|
@ -224,6 +243,7 @@ Then we rewrite `hello.nix` as follows:
|
|||
name = "hello";
|
||||
src = ./hello-2.12.1.tar.gz;
|
||||
}
|
||||
```
|
||||
|
||||
Finally! We got a very simple description of a package! Below are a couple of remarks that you may find useful as you're continuing to understand the nix language:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Today we stop by the GNU `hello` program to analyze build and runtime dependenci
|
|||
|
||||
Let's start analyzing build dependencies for our GNU `hello` package:
|
||||
|
||||
```console
|
||||
$ nix-instantiate hello.nix
|
||||
/nix/store/z77vn965a59irqnrrjvbspiyl2rph0jp-hello.drv
|
||||
$ nix-store -q --references /nix/store/z77vn965a59irqnrrjvbspiyl2rph0jp-hello.drv
|
||||
|
|
@ -23,6 +24,7 @@ Let's start analyzing build dependencies for our GNU `hello` package:
|
|||
/nix/store/rgyrqxz1ilv90r01zxl0sq5nq0cq7v3v-binutils-2.23.1.drv
|
||||
/nix/store/qzxhby795niy6wlagfpbja27dgsz43xk-gcc-wrapper-4.8.3.drv
|
||||
/nix/store/sk590g7fv53m3zp0ycnxsc41snc2kdhp-gzip-1.6.drv
|
||||
```
|
||||
|
||||
It has precisely the derivations referenced in the `derivation` function; nothing more, nothing less. Of course, we may not use some of them at all. However, given that our generic `mkDerivation` function always pulls such dependencies (think of it like [build-essential](https://packages.debian.org/unstable/build-essential) from Debian), we will already have these packages in the nix store for any future packages that need them.
|
||||
|
||||
|
|
@ -52,6 +54,7 @@ Nix handles runtime dependencies for us automatically. The technique it uses to
|
|||
|
||||
The snippet below shows the dependencies for `hello`.
|
||||
|
||||
```console
|
||||
$ nix-instantiate hello.nix
|
||||
/nix/store/z77vn965a59irqnrrjvbspiyl2rph0jp-hello.drv
|
||||
$ nix-store -r /nix/store/z77vn965a59irqnrrjvbspiyl2rph0jp-hello.drv
|
||||
|
|
@ -60,11 +63,14 @@ The snippet below shows the dependencies for `hello`.
|
|||
/nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19
|
||||
/nix/store/8jm0wksask7cpf85miyakihyfch1y21q-gcc-4.8.3
|
||||
/nix/store/a42k52zwv6idmf50r9lps1nzwq9khvpf-hello
|
||||
```
|
||||
|
||||
We see that `glibc` and `gcc` are runtime dependencies. Intuitively, `gcc` shouldn't be in this list! Displaying the printable strings in the `hello` binary shows that the out path of `gcc` does indeed appear:
|
||||
|
||||
```console
|
||||
$ strings result/bin/hello|grep gcc
|
||||
/nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19/lib:/nix/store/8jm0wksask7cpf85miyakihyfch1y21q-gcc-4.8.3/lib64
|
||||
```
|
||||
|
||||
This is why Nix added `gcc`. But why is that path present in the first place? The answer is that it is the [ld rpath](http://en.wikipedia.org/wiki/Rpath): the list of directories where libraries can be found at runtime. In other distributions, this is usually not abused. But in Nix, we have to refer to particular versions of libraries, and thus the rpath has an important role.
|
||||
|
||||
|
|
@ -90,7 +96,9 @@ We will add a new phase to our autotools builder. The builder has six phases alr
|
|||
|
||||
Now we will add a new phase after the installation phase, which we call the "fixup" phase. At the end of the `builder.sh`, we append:
|
||||
|
||||
```console
|
||||
find $out -type f -exec patchelf --shrink-rpath '{}' \; -exec strip '{}' \; 2>/dev/null
|
||||
```
|
||||
|
||||
That is, for each file we run `patchelf --shrink-rpath` and `strip`. Note that we used two new commands here, `find` and `patchelf`. These must be added to our derivation.
|
||||
|
||||
|
|
@ -98,20 +106,24 @@ That is, for each file we run `patchelf --shrink-rpath` and `strip`. Note that w
|
|||
|
||||
Now, we rebuild `hello.nix`...
|
||||
|
||||
```console
|
||||
$ nix-build hello.nix
|
||||
[...]
|
||||
$ nix-store -q --references result
|
||||
/nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19
|
||||
/nix/store/md4a3zv0ipqzsybhjb8ndjhhga1dj88x-hello
|
||||
```
|
||||
|
||||
and we see that `glibc` is a runtime dependency. This is exactly what we wanted.
|
||||
|
||||
The package is self-contained. This means that we can copy its closure onto another machine and we will be able to run it. Remember, only a very few components under the `/nix/store` are required to [run nix](02-install-on-your-running.md). The `hello` binary will use the exact version of `glibc` library and interpreter referred to in the binary, rather than the system one:
|
||||
|
||||
```console
|
||||
$ ldd result/bin/hello
|
||||
linux-vdso.so.1 (0x00007fff11294000)
|
||||
libc.so.6 => /nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19/lib/libc.so.6 (0x00007f7ab7362000)
|
||||
/nix/store/94n64qy99ja0vgbkf675nyk39g9b978n-glibc-2.19/lib/ld-linux-x86-64.so.2 (0x00007f7ab770f000)
|
||||
```
|
||||
|
||||
Of course, the executable will run fine as long as everything is under the `/nix/store` path.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,11 +14,13 @@ Recall that in a nix environment, we don't have access to libraries or programs
|
|||
|
||||
We can call `nix-shell` on any Nix expression which returns a derivation, but the resulting `bash` shell's `PATH` does not have the utilities we want:
|
||||
|
||||
```console
|
||||
$ nix-shell hello.nix
|
||||
[nix-shell]$ make
|
||||
bash: make: command not found
|
||||
[nix-shell]$ echo $baseInputs
|
||||
/nix/store/jff4a6zqi0yrladx3kwy4v6844s3swpc-gnutar-1.27.1 [...]
|
||||
```
|
||||
|
||||
This shell is rather useless. It would be reasonable to expect that the GNU `hello` build inputs are available in `PATH`, including GNU `make`, but this is not the case.
|
||||
|
||||
|
|
@ -26,8 +28,10 @@ However, we do have the environment variables that we set in the derivation, lik
|
|||
|
||||
This means that we can `source` our `builder.sh`, and it will build the derivation. You may get an error in the installation phase, because your user may not have the permission to write to `/nix/store`:
|
||||
|
||||
```console
|
||||
[nix-shell]$ source builder.sh
|
||||
...
|
||||
```
|
||||
|
||||
The derivation didn't install, but it did build. Note the following:
|
||||
|
||||
|
|
@ -53,6 +57,7 @@ During our refactoring, we will wrap the build phases in functions to give more
|
|||
|
||||
Here is our modified `autotools.nix`. Noteworthy is the `setup = ./setup.sh;` attribute in the derivation, which adds `setup.sh` to the nix store and correspondingly adds a `$setup` environment variable in the builder.
|
||||
|
||||
```nix
|
||||
pkgs: attrs:
|
||||
let
|
||||
defaultAttrs = {
|
||||
|
|
@ -77,17 +82,21 @@ Here is our modified `autotools.nix`. Noteworthy is the `setup = ./setup.sh;` at
|
|||
};
|
||||
in
|
||||
derivation (defaultAttrs // attrs)
|
||||
```
|
||||
|
||||
Thanks to that, we can split `builder.sh` into `setup.sh` and `builder.sh`. What `builder.sh` does is `source` `$setup` and call the `genericBuild` function. Everything else is just some changes to the bash script.
|
||||
|
||||
Here is the modified `builder.sh`:
|
||||
|
||||
```sh
|
||||
set -e
|
||||
source $setup
|
||||
genericBuild
|
||||
```
|
||||
|
||||
Here is the newly added `setup.sh`:
|
||||
|
||||
```sh
|
||||
unset PATH
|
||||
for p in $baseInputs $buildInputs; do
|
||||
export PATH=$p/bin${PATH:+:}$PATH
|
||||
|
|
@ -127,9 +136,11 @@ Here is the newly added `setup.sh`:
|
|||
installPhase
|
||||
fixupPhase
|
||||
}
|
||||
```
|
||||
|
||||
Finally, here is `hello.nix`:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
mkDerivation = import ./autotools.nix pkgs;
|
||||
|
|
@ -138,12 +149,15 @@ Finally, here is `hello.nix`:
|
|||
name = "hello";
|
||||
src = ./hello-2.12.1.tar.gz;
|
||||
}
|
||||
```
|
||||
|
||||
Now back to nix-shell:
|
||||
|
||||
```console
|
||||
$ nix-shell hello.nix
|
||||
[nix-shell]$ source $setup
|
||||
[nix-shell]$
|
||||
```
|
||||
|
||||
Now, for example, you can run `unpackPhase` which unpacks `$src` and enters the directory. And you can run commands like `./configure`, `make`, and so forth manually, or run phases with their respective functions.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,17 +20,20 @@ In summary, Nix maintains a list of GC roots. These roots can then be used to co
|
|||
|
||||
Before we begin we first run the [nix garbage collector](https://nixos.org/manual/nix/stable/command-ref/nix-collect-garbage.html) so that we have a clean setup for our experiments:
|
||||
|
||||
```console
|
||||
$ nix-collect-garbage
|
||||
finding garbage collector roots...
|
||||
[...]
|
||||
deleting unused links...
|
||||
note: currently hard linking saves -0.00 MiB
|
||||
1169 store paths deleted, 228.43 MiB freed
|
||||
```
|
||||
|
||||
If we run the garbage collector again it won't find anything new to delete, as we expect. After running the garbage collector, the nix store only contains paths with references from the GC roots.
|
||||
|
||||
We now install a new program, `bsd-games`, inspect its store path, and examine its GC root. The `nix-store -q --roots` command is used to query the GC roots that refer to a given derivation. In this case, our current user environment refers to `bsd-games`:
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.bsdgames
|
||||
$ readlink -f `which fortune`
|
||||
/nix/store/b3lxx3d3ggxcggvjw5n0m1ya1gcrmbyn-bsd-games-2.17/bin/fortune
|
||||
|
|
@ -39,20 +42,24 @@ We now install a new program, `bsd-games`, inspect its store path, and examine i
|
|||
$ nix-env --list-generations
|
||||
[...]
|
||||
9 2014-08-20 12:44:14 (current)
|
||||
```
|
||||
|
||||
Now we remove it and run the garbage collector, and note that `bsd-games` is still in the nix store:
|
||||
|
||||
```console
|
||||
$ nix-env -e bsd-games
|
||||
uninstalling `bsd-games-2.17'
|
||||
$ nix-collect-garbage
|
||||
[...]
|
||||
$ ls /nix/store/b3lxx3d3ggxcggvjw5n0m1ya1gcrmbyn-bsd-games-2.17
|
||||
bin share
|
||||
```
|
||||
|
||||
The old generation is still in the nix store because it is a GC root. As we will see below, all profiles and their generations are automatically GC roots.
|
||||
|
||||
Removing a GC root is simple. In our case, we delete the generation that refers to `bsd-games`, run the garbage collector, and note that `bsd-games` is no longer in the nix store:
|
||||
|
||||
```console
|
||||
$ rm /nix/var/nix/profiles/default-9-link
|
||||
$ nix-env --list-generations
|
||||
[...]
|
||||
|
|
@ -62,6 +69,7 @@ Removing a GC root is simple. In our case, we delete the generation that refers
|
|||
[...]
|
||||
$ ls /nix/store/b3lxx3d3ggxcggvjw5n0m1ya1gcrmbyn-bsd-games-2.17
|
||||
ls: cannot access /nix/store/b3lxx3d3ggxcggvjw5n0m1ya1gcrmbyn-bsd-games-2.17: No such file or directory
|
||||
```
|
||||
|
||||
Note: `nix-env --list-generations` does not rely on any particular metadata. It is able to list generations based solely on the file names under the profiles directory.
|
||||
|
||||
|
|
@ -73,11 +81,13 @@ Recall that building the GNU `hello` package with `nix-build` produces a `result
|
|||
|
||||
In fact, `nix-build` automatically adds the `result` symlink as a GC root. Note that this is not the built derivation, but the symlink itself. These GC roots are added under `/nix/var/nix/gcroots/auto`.
|
||||
|
||||
```console
|
||||
$ ls -l /nix/var/nix/gcroots/auto/
|
||||
total 8
|
||||
drwxr-xr-x 2 nix nix 4096 Aug 20 10:24 ./
|
||||
drwxr-xr-x 3 nix nix 4096 Jul 24 10:38 ../
|
||||
lrwxrwxrwx 1 nix nix 16 Jul 31 10:51 xlgz5x2ppa0m72z5qfc78b8wlciwvgiz -> /home/nix/result/
|
||||
```
|
||||
|
||||
The name of the GC root symlink is not important to us at this time. What is important is that such a symlink exists and points to `/home/nix/result`. This is called an **indirect GC root**. A GC root is considered indirect if its specification is outside of `/nix/var/nix/gcroots`. In this case, this means that the target of the `result` symlink will not be garbage collected.
|
||||
|
||||
|
|
@ -109,10 +119,12 @@ Other systems typically "forget" everything about their previous state after an
|
|||
|
||||
The four steps are shown below:
|
||||
|
||||
```console
|
||||
$ nix-channel --update
|
||||
$ nix-env -u --always
|
||||
$ rm /nix/var/nix/gcroots/auto/*
|
||||
$ nix-collect-garbage -d
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ We have already packaged GNU `hello`. Next, we will package a graph-drawing prog
|
|||
|
||||
First, we download `graphviz` from [gitlab](https://gitlab.com/api/v4/projects/4207231/packages/generic/graphviz-releases/2.49.3/graphviz-2.49.3.tar.gz). The `graphviz.nix` expression is straightforward:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
mkDerivation = import ./autotools.nix pkgs;
|
||||
|
|
@ -34,13 +35,16 @@ First, we download `graphviz` from [gitlab](https://gitlab.com/api/v4/projects/4
|
|||
name = "graphviz";
|
||||
src = ./graphviz-2.49.3.tar.gz;
|
||||
}
|
||||
```
|
||||
|
||||
If we build the project with `nix-build graphviz.nix`, we will get runnable binaries under `result/bin`. Notice how we reused the same `autotools.nix` of `hello.nix.`
|
||||
|
||||
By default, `graphviz` does not compile with the ability to produce `png` files. Thus, the derivation above will build a binary supporting only the native output formats, as we see below:
|
||||
|
||||
```console
|
||||
$ echo 'graph test { a -- b }'|result/bin/dot -Tpng -o test.png
|
||||
Format: "png" not recognized. Use one of: canon cmap [...]
|
||||
```
|
||||
|
||||
If we want to produce a `png` file with `graphviz`, we must add it to our derivation. The place to do so is in `autotools.nix`, where we created a `buildInputs` variable that gets concatenated to `baseInputs`. This is the exact reason for this variable: to allow users of `autotools.nix` to add additional inputs from package expressions.
|
||||
|
||||
|
|
@ -54,6 +58,7 @@ In classic POSIX systems, `pkg-config` just finds the `.pc` files of all install
|
|||
|
||||
As an alternative, we can inform `pkg-config` about the location of libraries via the `PKG_CONFIG_PATH` environment variable. We can populate this environment variable using the same trick we used for `PATH`: automatically filling the variables from `buildInputs`. This is the relevant snippet of `setup.sh`:
|
||||
|
||||
```sh
|
||||
for p in $baseInputs $buildInputs; do
|
||||
if [ -d $p/bin ]; then
|
||||
export PATH="$p/bin${PATH:+:}$PATH"
|
||||
|
|
@ -62,6 +67,7 @@ As an alternative, we can inform `pkg-config` about the location of libraries vi
|
|||
export PKG_CONFIG_PATH="$p/lib/pkgconfig${PKG_CONFIG_PATH:+:}$PKG_CONFIG_PATH"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
Now if we add derivations to `buildInputs`, their `lib/pkgconfig` and `bin` paths are automatically added in `setup.sh`.
|
||||
|
||||
|
|
@ -69,6 +75,7 @@ Now if we add derivations to `buildInputs`, their `lib/pkgconfig` and `bin` path
|
|||
|
||||
Below, we finish the expression for `graphviz` with `gd` support. Note the use of the `with` expression in `buildInputs` to avoid repeating `pkgs`:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
mkDerivation = import ./autotools.nix pkgs;
|
||||
|
|
@ -82,6 +89,7 @@ Below, we finish the expression for `graphviz` with `gd` support. Note the use o
|
|||
(pkgs.lib.getDev gd)
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
We add `pkg-config` to the derivation to make this tool available for the configure script. As `gd` is a package with [split outputs](https://nixos.org/manual/nixpkgs/stable/#sec-multiple-outputs-), we need to add both the library and development outputs.
|
||||
|
||||
|
|
@ -95,13 +103,16 @@ Using this technique we are able to abstract from the file names. Instead of ref
|
|||
|
||||
To begin, create a default.nix in the current directory:
|
||||
|
||||
```nix
|
||||
{
|
||||
hello = import ./hello.nix;
|
||||
graphviz = import ./graphviz.nix;
|
||||
}
|
||||
```
|
||||
|
||||
This file is ready to use with `nix repl`:
|
||||
|
||||
```console
|
||||
$ nix repl
|
||||
nix-repl> :l default.nix
|
||||
Added 2 variables.
|
||||
|
|
@ -109,21 +120,26 @@ This file is ready to use with `nix repl`:
|
|||
«derivation /nix/store/dkib02g54fpdqgpskswgp6m7bd7mgx89-hello.drv»
|
||||
nix-repl> graphviz
|
||||
«derivation /nix/store/zqv520v9mk13is0w980c91z7q1vkhhil-graphviz.drv»
|
||||
```
|
||||
|
||||
With `nix-build`, we can pass the -A option to access an attribute of the set from the given `.nix` expression:
|
||||
|
||||
```console
|
||||
$ nix-build default.nix -A hello
|
||||
[...]
|
||||
$ result/bin/hello
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
The `default.nix` file is special. When a directory contains a `default.nix` file, it is used as the implicit nix expression of the directory. This, for example, allows us to run `nix-build -A hello` without specifying `default.nix` explicitly.
|
||||
|
||||
We can now use `nix-env` to install the package into our user environment:
|
||||
|
||||
```console
|
||||
$ nix-env -f . -iA graphviz
|
||||
[...]
|
||||
$ dot -V
|
||||
```
|
||||
|
||||
Taking a closer look at the above command, we see the following options:
|
||||
|
||||
|
|
@ -157,6 +173,7 @@ The `./src` directory is also an input, but we wouldn't change the source from t
|
|||
|
||||
Our goal is to make package expressions independent of the repository. To achieve this, we use functions to declare inputs for a derivation. For example, with `graphviz.nix`, we make the following changes to make the derivation independent of the repository and customizable:
|
||||
|
||||
```nix
|
||||
{ mkDerivation, lib, gdSupport ? true, gd, pkg-config }:
|
||||
|
||||
mkDerivation {
|
||||
|
|
@ -171,6 +188,7 @@ Our goal is to make package expressions independent of the repository. To achiev
|
|||
]
|
||||
else [];
|
||||
}
|
||||
```
|
||||
|
||||
Recall that "`{...}: ...`" is the syntax for defining functions accepting an attribute set as argument; the above snippet just defines a function.
|
||||
|
||||
|
|
@ -178,6 +196,7 @@ We made `gd` and its dependencies optional. If `gdSupport` is true (which it is
|
|||
|
||||
Going back to back to `default.nix`, we modify our expression to utilize the inputs pattern:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> { };
|
||||
mkDerivation = import ./autotools.nix pkgs;
|
||||
|
|
@ -203,6 +222,7 @@ Going back to back to `default.nix`, we modify our expression to utilize the inp
|
|||
gdSupport = false;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
We factorized the import of `nixpkgs` and `mkDerivation`, and also added a variant of `graphviz` with `gd` support disabled. The result is that both `hello.nix` (left as an exercise for the reader) and `graphviz.nix` are independent of the repository and customizable by passing specific inputs.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,15 +10,19 @@ In the previous pill, we demonstrated how the `inputs` pattern decouples package
|
|||
|
||||
However, as with usual programming languages, there is some duplication of work: we declare parameter names and then we pass arguments, typically with the same name. For example, if we define a package derivation using the `inputs` pattern such as:
|
||||
|
||||
```nix
|
||||
{ input1, input2, ... }:
|
||||
...
|
||||
```
|
||||
|
||||
we would likely want to bundle that package derivation into a repository via a an attribute set defined as something like:
|
||||
|
||||
```nix
|
||||
rec {
|
||||
lib1 = import package1.nix { inherit input1 input2; };
|
||||
program2 = import package2.nix { inherit inputX inputY lib1; };
|
||||
}
|
||||
```
|
||||
|
||||
There are two things to note. First, that inputs often have the same name as attributes in the repository itself. Second, that (due to the `rec` keyword), the inputs to a package derivation may be other packages in the repository itself.
|
||||
|
||||
|
|
@ -26,10 +30,12 @@ Rather than passing the inputs twice, we would prefer to pass those inputs from
|
|||
|
||||
To achieve this, we will define a `callPackage` function with the following calling convention:
|
||||
|
||||
```nix
|
||||
{
|
||||
lib1 = callPackage package1.nix { };
|
||||
program2 = callPackage package2.nix { someoverride = overriddenDerivation; };
|
||||
}
|
||||
```
|
||||
|
||||
We want `callPackage` to be a function of two arguments, with the following behavior:
|
||||
|
||||
|
|
@ -45,9 +51,11 @@ In this section, we will build up the `callPackages` pattern from scratch. To st
|
|||
|
||||
Nix provides a builtin function to do this:
|
||||
|
||||
```console
|
||||
nix-repl> add = { a ? 3, b }: a+b
|
||||
nix-repl> builtins.functionArgs add
|
||||
{ a = true; b = false; }
|
||||
```
|
||||
|
||||
In addition to returning the argument names, the attribute set returned by `functionArgs` indicates whether or not the argument has a default value. For our purposes, we are only interested in the argument names; we do not care about the default values right now.
|
||||
|
||||
|
|
@ -61,21 +69,25 @@ To do this, we need two things:
|
|||
|
||||
The former is easy: we just have to set our package derivation's inputs to be package names in a repository, such as `nixpkgs`. For the latter, Nix provides another builtin function:
|
||||
|
||||
```console
|
||||
nix-repl> values = { a = 3; b = 5; c = 10; }
|
||||
nix-repl> builtins.intersectAttrs values (builtins.functionArgs add)
|
||||
{ a = true; b = false; }
|
||||
nix-repl> builtins.intersectAttrs (builtins.functionArgs add) values
|
||||
{ a = 3; b = 5; }
|
||||
```
|
||||
|
||||
The `intersectAttrs` returns an attribute set whose names are the intersection of both arguments' attribute names, with the attribute values taken from the second argument.
|
||||
|
||||
This is all we need to do: we have obtained the argument names from a function, and populated these with an existing set of attributes. This is our simple implementation of `callPackage`:
|
||||
|
||||
```console
|
||||
nix-repl> callPackage = set: f: f (builtins.intersectAttrs (builtins.functionArgs f) set)
|
||||
nix-repl> callPackage values add
|
||||
8
|
||||
nix-repl> with values; add { inherit a b; }
|
||||
8
|
||||
```
|
||||
|
||||
Let's dissect the above snippet:
|
||||
|
||||
|
|
@ -95,11 +107,13 @@ We achieved most of what we wanted: to automatically call functions given a set
|
|||
|
||||
The last missing piece is allowing users to override some of the parameters. We may not want to always call functions with values taken from the big set. Thus, we add a third parameter which takes a set of overrides:
|
||||
|
||||
```console
|
||||
nix-repl> callPackage = set: f: overrides: f ((builtins.intersectAttrs (builtins.functionArgs f) set) // overrides)
|
||||
nix-repl> callPackage values add { }
|
||||
8
|
||||
nix-repl> callPackage values add { b = 12; }
|
||||
15
|
||||
```
|
||||
|
||||
Apart from the increasing number of parentheses, it should be clear that we simply take a set union between the default arguments and the overriding set.
|
||||
|
||||
|
|
@ -107,6 +121,7 @@ Apart from the increasing number of parentheses, it should be clear that we simp
|
|||
|
||||
Given our `callPackages`, we can simplify the repository expression in `default.nix`:
|
||||
|
||||
```nix
|
||||
let
|
||||
nixpkgs = import <nixpkgs> { };
|
||||
allPkgs = nixpkgs // pkgs;
|
||||
|
|
@ -124,6 +139,7 @@ Given our `callPackages`, we can simplify the repository expression in `default.
|
|||
};
|
||||
in
|
||||
pkgs
|
||||
```
|
||||
|
||||
Let's examine this in detail:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,9 @@ In Nix, we mostly talk about **functions** that accept inputs in order to return
|
|||
|
||||
For example, let's say we have an initial derivation `drv` and we want to transform it into a `drv` with debugging information and custom patches:
|
||||
|
||||
```nix
|
||||
debugVersion (applyPatches [ ./patch1.patch ./patch2.patch ] drv)
|
||||
```
|
||||
|
||||
The final result should be the original derivation with some changes. This is both interesting and very different from other packaging approaches, which is a consequence of using a functional language to describe packages.
|
||||
|
||||
|
|
@ -24,10 +26,13 @@ In [pill 12](12-inputs-design-pattern.md) we introduced the inputs design patter
|
|||
|
||||
In our repository we have a set of attributes that import the expressions of the packages and pass these arguments, getting back a derivation. Let's take for example the graphviz attribute:
|
||||
|
||||
```nix
|
||||
graphviz = import ./graphviz.nix { inherit mkDerivation gd fontconfig libjpeg bzip2; };
|
||||
```
|
||||
|
||||
If we wanted to produce a derivation of graphviz with a customized gd version, we would have to repeat most of the above plus specifying an alternative gd:
|
||||
|
||||
```nix
|
||||
{
|
||||
mygraphviz = import ./graphviz.nix {
|
||||
inherit
|
||||
|
|
@ -39,16 +44,21 @@ If we wanted to produce a derivation of graphviz with a customized gd version, w
|
|||
gd = customgd;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
That's hard to maintain. Using `callPackage` would be easier:
|
||||
|
||||
```nix
|
||||
mygraphviz = callPackage ./graphviz.nix { gd = customgd; };
|
||||
```
|
||||
|
||||
But we may still be diverging from the original graphviz in the repository.
|
||||
|
||||
We would like to avoid specifying the nix expression again. Instead, we would like to reuse the original graphviz attribute in the repository and add our overrides like so:
|
||||
|
||||
```nix
|
||||
mygraphviz = graphviz.override { gd = customgd; };
|
||||
```
|
||||
|
||||
The difference is obvious, as well as the advantages of this approach.
|
||||
|
||||
|
|
@ -62,6 +72,7 @@ Let's start by first creating a function "`makeOverridable`". This function will
|
|||
|
||||
We will put this function in a `lib.nix`:
|
||||
|
||||
```nix
|
||||
{
|
||||
makeOverridable =
|
||||
f: origArgs:
|
||||
|
|
@ -70,6 +81,7 @@ We will put this function in a `lib.nix`:
|
|||
in
|
||||
origRes // { override = newArgs: f (origArgs // newArgs); };
|
||||
}
|
||||
```
|
||||
|
||||
`makeOverridable` takes a function and a set of original arguments. It returns the original returned set, plus a new `override` attribute.
|
||||
|
||||
|
|
@ -77,6 +89,7 @@ This `override` attribute is a function taking a set of new arguments, and retur
|
|||
|
||||
Let's try it with `nix repl`:
|
||||
|
||||
```console
|
||||
$ nix repl
|
||||
nix-repl> :l lib.nix
|
||||
Added 1 variables.
|
||||
|
|
@ -88,6 +101,7 @@ Let's try it with `nix repl`:
|
|||
{ override = «lambda»; result = 8; }
|
||||
nix-repl> res.override { a = 10; }
|
||||
{ result = 15; }
|
||||
```
|
||||
|
||||
Note that, as we specified above, the function `f` does not return the plain sum. Instead, it returns a set with the sum bound to the name `result`.
|
||||
|
||||
|
|
@ -99,6 +113,7 @@ This is a good start, but we can't override again! This is because the returned
|
|||
|
||||
The solution is simple: the `.override` function should make the result overridable again:
|
||||
|
||||
```nix
|
||||
rec {
|
||||
makeOverridable =
|
||||
f: origArgs:
|
||||
|
|
@ -107,11 +122,13 @@ The solution is simple: the `.override` function should make the result overrida
|
|||
in
|
||||
origRes // { override = newArgs: makeOverridable f (origArgs // newArgs); };
|
||||
}
|
||||
```
|
||||
|
||||
Please note the `rec` keyword. It's necessary so that we can refer to `makeOverridable` from `makeOverridable` itself.
|
||||
|
||||
Now let's try overriding twice:
|
||||
|
||||
```console
|
||||
nix-repl> :l lib.nix
|
||||
Added 1 variables.
|
||||
nix-repl> f = { a, b }: { result = a+b; }
|
||||
|
|
@ -121,6 +138,7 @@ Now let's try overriding twice:
|
|||
{ override = «lambda»; result = 15; }
|
||||
nix-repl> res2.override { b = 20; }
|
||||
{ override = «lambda»; result = 30; }
|
||||
```
|
||||
|
||||
Success! The result is 30 (as expected) because `a` is overridden to 10 in the first override, and `b` is overridden to 20 in the second.
|
||||
|
||||
|
|
@ -132,7 +150,9 @@ The "`override`" pattern simplifies the way we customize packages starting from
|
|||
|
||||
We can dream of a custom, isolated `nix-shell` environment for testing graphviz with a custom gd:
|
||||
|
||||
```nix
|
||||
debugVersion (graphviz.override { gd = customgd; })
|
||||
```
|
||||
|
||||
Once a new version of the overridden package comes out in the repository, the customized package will make use of it automatically.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,21 +22,25 @@ For ease we will use `nix-instantiate --eval` to do our tests. I remind you, [ni
|
|||
|
||||
It's useless from a nix view point, but I think it's useful for your own understanding. Let's use `PATH` itself as `NIX_PATH`, and try to locate `ping` (or another binary if you don't have it).
|
||||
|
||||
```console
|
||||
$ nix-instantiate --eval -E '<ping>'
|
||||
error: file `ping' was not found in the Nix search path (add it using $NIX_PATH or -I)
|
||||
$ NIX_PATH=$PATH nix-instantiate --eval -E '<ping>'
|
||||
/bin/ping
|
||||
$ nix-instantiate -I /bin --eval -E '<ping>'
|
||||
/bin/ping
|
||||
```
|
||||
|
||||
Great. At first attempt nix obviously said could not be found anywhere in the search path. Note that the -I option accepts a single directory. Paths added with -I take precedence over `NIX_PATH`.
|
||||
|
||||
The `NIX_PATH` also accepts a different yet very handy syntax: "`somename=somepath`". That is, instead of searching inside a directory for a name, we specify exactly the value of that name.
|
||||
|
||||
```console
|
||||
$ NIX_PATH="ping=/bin/ping" nix-instantiate --eval -E '<ping>'
|
||||
/bin/ping
|
||||
$ NIX_PATH="ping=/bin/foo" nix-instantiate --eval -E '<ping>'
|
||||
error: file `ping' was not found in the Nix search path (add it using $N
|
||||
```
|
||||
|
||||
Note in the second case how Nix checks whether the path exists or not.
|
||||
|
||||
|
|
@ -44,10 +48,12 @@ Note in the second case how Nix checks whether the path exists or not.
|
|||
|
||||
You are out of curiosity, right?
|
||||
|
||||
```console
|
||||
$ nix-instantiate --eval -E '<nixpkgs>'
|
||||
/home/nix/.nix-defexpr/channels/nixpkgs
|
||||
$ echo $NIX_PATH
|
||||
nixpkgs=/home/nix/.nix-defexpr/channels/nixpkgs
|
||||
```
|
||||
|
||||
You may have a different path, depending on how you added channels etc.. Anyway that's the whole point. The `<nixpkgs>` stranger that we used in our nix expressions, is referring to a path in the filesystem specified by `NIX_PATH`.
|
||||
|
||||
|
|
@ -59,9 +65,11 @@ You may wonder: then I can also specify a different [nixpkgs](https://github.com
|
|||
|
||||
Let's define a path for our repository, then! Let's say all the `default.nix`, `graphviz.nix` etc. are under `/home/nix/mypkgs`:
|
||||
|
||||
```console
|
||||
$ export NIX_PATH=mypkgs=/home/nix/mypkgs:$NIX_PATH
|
||||
$ nix-instantiate --eval '<mypkgs>'
|
||||
{ graphviz = <code>; graphvizCore = <code>; hello = <code>; mkDerivation = <code>; }
|
||||
```
|
||||
|
||||
Yes, `nix-build` also accepts paths with angular brackets. We first evaluate the whole repository (`default.nix`) and then pick the graphviz attribute.
|
||||
|
||||
|
|
@ -77,23 +85,29 @@ So if you run `nix-env -i graphviz` inside your repository, it will install the
|
|||
|
||||
In order to specify an alternative to `~/.nix-defexpr` it's possible to use the -f option:
|
||||
|
||||
```console
|
||||
$ nix-env -f '<mypkgs>' -i graphviz
|
||||
warning: there are multiple derivations named `graphviz'; using the first one
|
||||
replacing old `graphviz'
|
||||
installing `graphviz'
|
||||
```
|
||||
|
||||
Oh why did it say there's another derivation named graphviz? Because both `graphviz` and `graphvizCore` attributes in our repository have the name "graphviz" for the derivation:
|
||||
|
||||
```console
|
||||
$ nix-env -f '<mypkgs>' -qaP
|
||||
graphviz graphviz
|
||||
graphvizCore graphviz
|
||||
hello hello
|
||||
```
|
||||
|
||||
By default `nix-env` parses all derivations and uses the derivation names to interpret the command line. So in this case "graphviz" matched two derivations. Alternatively, like for `nix-build`, one can use -A to specify an attribute name instead of a derivation name:
|
||||
|
||||
```console
|
||||
$ nix-env -f '<mypkgs>' -i -A graphviz
|
||||
replacing old `graphviz'
|
||||
installing `graphviz'
|
||||
```
|
||||
|
||||
This form, other than being more precise, it's also faster because `nix-env` does not have to parse all the derivations.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,14 +32,18 @@ You will find this parameter in many other .nix expressions (e.g. release expres
|
|||
|
||||
`myrelease.nix`:
|
||||
|
||||
```nix
|
||||
{ system ? builtins.currentSystem }:
|
||||
|
||||
let pkgs = import <nixpkgs> { inherit system; };
|
||||
...
|
||||
```
|
||||
|
||||
Why is it useful? With this parameter it's very easy to select a set of packages for a particular system. For example:
|
||||
|
||||
```console
|
||||
nix-build -A psmisc --argstr system i686-linux
|
||||
```
|
||||
|
||||
This will build the psmisc derivation for i686-linux instead of x86_64-linux. This concept is very similar to multi-arch of Debian.
|
||||
|
||||
|
|
@ -55,6 +59,7 @@ After determining `config.nix`, it will be imported as a nix expression, and tha
|
|||
|
||||
The `config` is available in the resulting repository:
|
||||
|
||||
```console
|
||||
$ nix repl
|
||||
nix-repl> pkgs = import <nixpkgs> {}
|
||||
nix-repl> pkgs.config
|
||||
|
|
@ -62,6 +67,7 @@ The `config` is available in the resulting repository:
|
|||
nix-repl> pkgs = import <nixpkgs> { config = { foo = "bar"; }; }
|
||||
nix-repl> pkgs.config
|
||||
{ foo = "bar"; }
|
||||
```
|
||||
|
||||
What attributes go in `config` is a matter of convenience and conventions.
|
||||
|
||||
|
|
@ -79,9 +85,11 @@ In this case, nix does a trick:
|
|||
|
||||
For example you can nix-build the `.nix` file below:
|
||||
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
||||
pkgs.psmisc
|
||||
```
|
||||
|
||||
Nix is able to call the function because the pkgs parameter has a default value. This allows you to pass a different value for pkgs using the `--arg` option.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,10 +12,12 @@ We put the override function in the returned attribute set of the original funct
|
|||
|
||||
Take for example graphviz. It has an input parameter xorg. If it's null, then graphviz will build without X support.
|
||||
|
||||
```console
|
||||
$ nix repl
|
||||
nix-repl> :l <nixpkgs>
|
||||
Added 4360 variables.
|
||||
nix-repl> :b graphviz.override { withXorg = false; }
|
||||
```
|
||||
|
||||
This will build graphviz without X support, it's as simple as that.
|
||||
|
||||
|
|
@ -25,9 +27,11 @@ However, let's say a package `P` depends on graphviz, how do we make `P` depend
|
|||
|
||||
...you could do something like this:
|
||||
|
||||
```nix
|
||||
pkgs = import <nixpkgs> {};
|
||||
pkgs.graphviz = pkgs.graphviz.override { withXorg = false; };
|
||||
build(pkgs.P)
|
||||
```
|
||||
|
||||
Given `pkgs.P` depends on `pkgs.graphviz`, it's easy to build `P` with the replaced graphviz. In a pure functional language it's not that easy because you can assign to variables only once.
|
||||
|
||||
|
|
@ -37,6 +41,7 @@ The fixed point with lazy evaluation is crippling but about necessary in a langu
|
|||
|
||||
Follows the definition of fixed point in [nixpkgs](https://github.com/NixOS/nixpkgs/blob/f224a4f1b32b3e813783d22de54e231cd8ea2448/lib/fixed-points.nix#L19):
|
||||
|
||||
```nix
|
||||
{
|
||||
# Take a function and evaluate it with its own returned value.
|
||||
fix =
|
||||
|
|
@ -46,15 +51,18 @@ Follows the definition of fixed point in [nixpkgs](https://github.com/NixOS/nixp
|
|||
in
|
||||
result;
|
||||
}
|
||||
```
|
||||
|
||||
It's a function that accepts a function `f`, calls `f result` on the result just returned by `f result` and returns it. In other words it's `f(f(f(....`
|
||||
|
||||
At first sight, it's an infinite loop. With lazy evaluation it isn't, because the call is done only when needed.
|
||||
|
||||
```console
|
||||
nix-repl> fix = f: let result = f result; in result
|
||||
nix-repl> pkgs = self: { a = 3; b = 4; c = self.a+self.b; }
|
||||
nix-repl> fix pkgs
|
||||
{ a = 3; b = 4; c = 7; }
|
||||
```
|
||||
|
||||
Without the `rec` keyword, we were able to refer to `a` and `b` of the same set.
|
||||
|
||||
|
|
@ -72,11 +80,13 @@ Won't go further with the explanation here. A good post about fixed point and Ni
|
|||
|
||||
Given that `self.a` and `self.b` refer to the passed set and not to the literal set in the function, we're able to override both `a` and `b` and get a new value for `c`:
|
||||
|
||||
```console
|
||||
nix-repl> overrides = { a = 1; b = 2; }
|
||||
nix-repl> let newpkgs = pkgs (newpkgs // overrides); in newpkgs
|
||||
{ a = 3; b = 4; c = 3; }
|
||||
nix-repl> let newpkgs = pkgs (newpkgs // overrides); in newpkgs // overrides
|
||||
{ a = 1; b = 2; c = 3; }
|
||||
```
|
||||
|
||||
In the first case we computed pkgs with the overrides, in the second case we also included the overridden attributes in the result.
|
||||
|
||||
|
|
@ -88,6 +98,7 @@ To do this, `nixpkgs` offers `config.packageOverrides`. So `nixpkgs` returns a f
|
|||
|
||||
Create a `config.nix` file like this somewhere:
|
||||
|
||||
```nix
|
||||
{
|
||||
packageOverrides = pkgs: {
|
||||
graphviz = pkgs.graphviz.override {
|
||||
|
|
@ -96,11 +107,14 @@ Create a `config.nix` file like this somewhere:
|
|||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Now we can build e.g. asciidoc-full and it will automatically use the overridden graphviz:
|
||||
|
||||
```console
|
||||
nix-repl> pkgs = import <nixpkgs> { config = import ./config.nix; }
|
||||
nix-repl> :b pkgs.asciidoc-full
|
||||
```
|
||||
|
||||
Note how we pass the `config` with `packageOverrides` when importing `nixpkgs`. Then `pkgs.asciidoc-full` is a derivation that has graphviz input (`pkgs.asciidoc` is the lighter version and doesn't use graphviz at all).
|
||||
|
||||
|
|
|
|||
|
|
@ -10,17 +10,21 @@ The way store paths are computed is a little contrived, mostly due to historical
|
|||
|
||||
Let's start simple. You know nix allows relative paths to be used, such that the file or directory is stored in the nix store, that is `./myfile` gets stored into `/nix/store/.......` We want to understand how is the store path generated for such a file:
|
||||
|
||||
```console
|
||||
$ echo mycontent > myfile
|
||||
```
|
||||
|
||||
I remind you, the simplest derivation you can write has a `name`, a `builder` and the `system`:
|
||||
|
||||
```console
|
||||
$ nix repl
|
||||
nix-repl> derivation { system = "x86_64-linux"; builder = ./myfile; name = "foo"; }
|
||||
«derivation /nix/store/y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck-foo.drv»
|
||||
```
|
||||
|
||||
Now inspect the .drv to see where is `./myfile` being stored:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show /nix/store/y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck-foo.drv
|
||||
{
|
||||
"/nix/store/y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck-foo.drv": {
|
||||
|
|
@ -54,13 +58,17 @@ Great, how did nix decide to use `xv2iccirbrvklck36f1g7vldn5v58vck` ? Keep looki
|
|||
|
||||
The comments tell us to first compute the sha256 of the NAR serialization of the file. Can be done in two ways:
|
||||
|
||||
```console
|
||||
$ nix-hash --type sha256 myfile
|
||||
2bfef67de873c54551d884fdab3055d84d573e654efa79db3c0d7b98883f9ee3
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```console
|
||||
$ nix-store --dump myfile|sha256sum
|
||||
2bfef67de873c54551d884fdab3055d84d573e654efa79db3c0d7b98883f9ee3
|
||||
```
|
||||
|
||||
In general, Nix understands two contents: flat for regular files, or recursive for NAR serializations which can be anything.
|
||||
|
||||
|
|
@ -68,14 +76,18 @@ In general, Nix understands two contents: flat for regular files, or recursive f
|
|||
|
||||
Then nix uses a special string which includes the hash, the path type and the file name. We store this in another file:
|
||||
|
||||
```console
|
||||
$ echo -n "source:sha256:2bfef67de873c54551d884fdab3055d84d573e654efa79db3c0d7b98883f9ee3:/nix/store:myfile" > myfile.str
|
||||
```
|
||||
|
||||
### Step 3, compute the final hash
|
||||
|
||||
Finally the comments tell us to compute the base-32 representation of the first 160 bits (truncation) of a sha256 of the above string:
|
||||
|
||||
```console
|
||||
$ nix-hash --type sha256 --truncate --base32 --flat myfile.str
|
||||
xv2iccirbrvklck36f1g7vldn5v58vck
|
||||
```
|
||||
|
||||
## Output paths
|
||||
|
||||
|
|
@ -85,16 +97,20 @@ It's computed in a similar way to source paths, except that the .drv is hashed a
|
|||
|
||||
At the time nix computes the out path, the .drv contains an empty string for each out path. So what we do is getting our .drv and replacing the out path with an empty string:
|
||||
|
||||
```console
|
||||
$ cp -f /nix/store/y4h73bmrc9ii5bxg6i7ck6hsf5gqv8ck-foo.drv myout.drv
|
||||
$ sed -i 's,/nix/store/hs0yi5n5nw6micqhy8l1igkbhqdkzqa1-foo,,g' myout.drv
|
||||
```
|
||||
|
||||
The `myout.drv` is the .drv state in which nix is when computing the out path for our derivation:
|
||||
|
||||
```console
|
||||
$ sha256sum myout.drv
|
||||
1bdc41b9649a0d59f270a92d69ce6b5af0bc82b46cb9d9441ebc6620665f40b5 myout.drv
|
||||
$ echo -n "output:out:sha256:1bdc41b9649a0d59f270a92d69ce6b5af0bc82b46cb9d9441ebc6620665f40b5:/nix/store:foo" > myout.str
|
||||
$ nix-hash --type sha256 --truncate --base32 --flat myout.str
|
||||
hs0yi5n5nw6micqhy8l1igkbhqdkzqa1
|
||||
```
|
||||
|
||||
Then nix puts that out path in the .drv, and that's it.
|
||||
|
||||
|
|
@ -112,15 +128,17 @@ The builder must create the out path and make sure its hash is the same as the o
|
|||
|
||||
Let's say our builder should create a file whose contents is `mycontent`:
|
||||
|
||||
```console
|
||||
$ echo mycontent > myfile
|
||||
$ sha256sum myfile
|
||||
f3f3c4763037e059b4d834eaf68595bbc02ba19f6d2a500dce06d124e2cd99bb myfile
|
||||
nix-repl> derivation { name = "bar"; system = "x86_64-linux"; builder = "none"; outputHashMode = "flat"; outputHashAlgo = "sha256"; outputHash = "f3f3c4763037e059b4d834eaf68595bbc02ba19f6d2a500dce06d124e2cd99bb"; }
|
||||
«derivation /nix/store/ymsf5zcqr9wlkkqdjwhqllgwa97rff5i-bar.drv»
|
||||
```
|
||||
|
||||
Inspect the .drv and see that it also stored the fact that it's a fixed-output derivation with sha256 algorithm, compared to the previous examples:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show /nix/store/ymsf5zcqr9wlkkqdjwhqllgwa97rff5i-bar.drv
|
||||
{
|
||||
"/nix/store/ymsf5zcqr9wlkkqdjwhqllgwa97rff5i-bar.drv": {
|
||||
|
|
@ -139,15 +157,19 @@ It doesn't matter which input derivations are being used, the final out path mus
|
|||
|
||||
What nix does is to create an intermediate string representation of the fixed-output content:
|
||||
|
||||
```console
|
||||
$ echo -n "fixed:out:sha256:f3f3c4763037e059b4d834eaf68595bbc02ba19f6d2a500dce06d124e2cd99bb:" > mycontent.str
|
||||
$ sha256sum mycontent.str
|
||||
423e6fdef56d53251c5939359c375bf21ea07aaa8d89ca5798fb374dbcfd7639 myfile.str
|
||||
```
|
||||
|
||||
Then proceed as it was a normal derivation output path:
|
||||
|
||||
```console
|
||||
$ echo -n "output:out:sha256:423e6fdef56d53251c5939359c375bf21ea07aaa8d89ca5798fb374dbcfd7639:/nix/store:bar" > myfile.str
|
||||
$ nix-hash --type sha256 --truncate --base32 --flat myfile.str
|
||||
a00d5f71k0vp5a6klkls0mvr1f7sx6ch
|
||||
```
|
||||
|
||||
Hence, the store path only depends on the declared fixed-output hash.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ The `stdenv` is not treated as a special derivation by Nix, but it's very import
|
|||
|
||||
First of all, `stdenv` is a derivation, and it's a very simple one:
|
||||
|
||||
```console
|
||||
$ nix-build '<nixpkgs>' -A stdenv
|
||||
/nix/store/k4jklkcag4zq4xkqhkpy156mgfm34ipn-stdenv
|
||||
$ ls -R result/
|
||||
|
|
@ -18,24 +19,29 @@ First of all, `stdenv` is a derivation, and it's a very simple one:
|
|||
|
||||
result/nix-support:
|
||||
propagated-user-env-packages
|
||||
```
|
||||
|
||||
It has just two files: `/setup` and `/nix-support/propagated-user-env-packages`. Don't worry about the latter. It's empty, in fact. The important file is `/setup`.
|
||||
|
||||
How can this simple derivation pull in all of the toolchain and basic tools needed to compile packages? Let's look at the runtime dependencies:
|
||||
|
||||
```console
|
||||
$ nix-store -q --references result
|
||||
/nix/store/3a45nb37s0ndljp68228snsqr3qsyp96-bzip2-1.0.6
|
||||
/nix/store/a457ywa1haa0sgr9g7a1pgldrg3s798d-coreutils-8.24
|
||||
/nix/store/zmd4jk4db5lgxb8l93mhkvr3x92g2sx2-bash-4.3-p39
|
||||
/nix/store/47sfpm2qclpqvrzijizimk4md1739b1b-gcc-wrapper-4.9.3
|
||||
...
|
||||
```
|
||||
|
||||
How can it be? The package must be referring to those other packages somehow. In fact, they are hardcoded in the `/setup` file:
|
||||
|
||||
```console
|
||||
$ head result/setup
|
||||
export SHELL=/nix/store/zmd4jk4db5lgxb8l93mhkvr3x92g2sx2-bash-4.3-p39/bin/bash
|
||||
initialPath="/nix/store/a457ywa1haa0sgr9g7a1pgldrg3s798d-coreutils-8.24 ..."
|
||||
defaultNativeBuildInputs="/nix/store/sgwq15xg00xnm435gjicspm048rqg9y6-patchelf-0.8 ..."
|
||||
```
|
||||
|
||||
## The setup file
|
||||
|
||||
|
|
@ -53,6 +59,7 @@ Every phase has hooks to run commands before and after the phase has been execut
|
|||
|
||||
How to use this file? Like our old builder. To test it, we enter a fake empty derivation, source the `stdenv` `setup`, unpack the hello sources and build it:
|
||||
|
||||
```console
|
||||
$ nix-shell -E 'derivation { name = "fake"; builder = "fake"; system = "x86_64-linux"; }'
|
||||
nix-shell$ unset PATH
|
||||
nix-shell$ source /nix/store/k4jklkcag4zq4xkqhkpy156mgfm34ipn-stdenv/setup
|
||||
|
|
@ -62,6 +69,7 @@ How to use this file? Like our old builder. To test it, we enter a fake empty de
|
|||
...
|
||||
nix-shell$ buildPhase
|
||||
...
|
||||
```
|
||||
|
||||
_I unset `PATH` to further show that the `stdenv` is sufficiently self-contained to build autotools packages that have no other dependencies._
|
||||
|
||||
|
|
@ -75,26 +83,31 @@ Note how `stdenv` is a derivation but it's also an attribute set which contains
|
|||
|
||||
Let's write a `hello.nix` expression using this newly discovered `stdenv`:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> { };
|
||||
stdenv.mkDerivation {
|
||||
name = "hello";
|
||||
src = ./hello-2.10.tar.gz;
|
||||
}
|
||||
```
|
||||
|
||||
Don't be scared by the `with` expression. It pulls the `nixpkgs` repository into scope, so we can directly use `stdenv`. It looks very similar to the hello expression in [Pill 8](08-generic-builders.md).
|
||||
|
||||
It builds, and runs fine:
|
||||
|
||||
```console
|
||||
$ nix-build hello.nix
|
||||
...
|
||||
/nix/store/6y0mzdarm5qxfafvn2zm9nr01d1j0a72-hello
|
||||
$ result/bin/hello
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
## The stdenv.mkDerivation builder
|
||||
|
||||
Let's take a look at the builder used by `mkDerivation`. You can read the code [here in nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix):
|
||||
|
||||
```nix
|
||||
{
|
||||
# ...
|
||||
builder = attrs.realBuilder or shell;
|
||||
|
|
@ -106,19 +119,22 @@ Let's take a look at the builder used by `mkDerivation`. You can read the code [
|
|||
stdenv = result;
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
Also take a look at our old derivation wrapper in previous pills! The builder is bash (that shell variable), the argument to the builder (bash) is `default-builder.sh`, and then we add the environment variable `$stdenv` in the derivation which is the `stdenv` derivation.
|
||||
|
||||
You can open [default-builder.sh](https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/default-builder.sh) and see what it does:
|
||||
|
||||
```sh
|
||||
source $stdenv/setup
|
||||
genericBuild
|
||||
```
|
||||
|
||||
It's what we did in [Pill 10](10-developing-with-nix-shell.md) to make the derivations `nix-shell` friendly. When entering the shell, the setup file only sets up the environment without building anything. When doing `nix-build`, it actually runs the build process.
|
||||
|
||||
To get a clear understanding of the environment variables, look at the .drv of the hello derivation:
|
||||
|
||||
```
|
||||
```console
|
||||
$ nix derivation show $(nix-instantiate hello.nix)
|
||||
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
|
||||
{
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ Note: The complexity of the dependencies and hooks infrastructure has increased,
|
|||
|
||||
For the simplest dependencies where the current package directly needs another, we use the `buildInputs` attribute. This is exactly the pattern used in our builder in [Pill 8](08-generic-builders.html). To demo this, let's build GNU Hello, and then another package which provides a shell script that `exec`s it.
|
||||
|
||||
```nix
|
||||
let
|
||||
|
||||
nixpkgs = import <nixpkgs> { };
|
||||
|
|
@ -48,16 +49,20 @@ For the simplest dependencies where the current package directly needs another,
|
|||
};
|
||||
in
|
||||
wrappedHello
|
||||
```
|
||||
|
||||
Notice that the wrappedHello derivation finds the `hello` binary from the `PATH`. This works because stdenv contains something like:
|
||||
|
||||
```sh
|
||||
pkgs=""
|
||||
for i in $buildInputs; do
|
||||
findInputs $i
|
||||
done
|
||||
```
|
||||
|
||||
where `findInputs` is defined like:
|
||||
|
||||
```sh
|
||||
findInputs() {
|
||||
local pkg=$1
|
||||
|
||||
|
|
@ -72,15 +77,19 @@ where `findInputs` is defined like:
|
|||
|
||||
## More goes here in reality that we can ignore for now.
|
||||
}
|
||||
```
|
||||
|
||||
then after this is run:
|
||||
|
||||
```sh
|
||||
for i in $pkgs; do
|
||||
addToEnv $i
|
||||
done
|
||||
```
|
||||
|
||||
where `addToEnv` is defined like:
|
||||
|
||||
```sh
|
||||
addToEnv() {
|
||||
local pkg=$1
|
||||
|
||||
|
|
@ -90,10 +99,13 @@ where `addToEnv` is defined like:
|
|||
|
||||
## More goes here in reality that we can ignore for now.
|
||||
}
|
||||
```
|
||||
|
||||
The `addToSearchPath` call adds `$1/bin` to `_PATH` if the former exists (code [here](https://github.com/NixOS/nixpkgs/blob/6675f0a52c0962042a1000c7f20e887d0d26ae25/pkgs/stdenv/generic/setup.sh#L60-L73)). Once all the packages in `buildInputs` have been processed, then content of `_PATH` is added to `PATH`, as follows:
|
||||
|
||||
```sh
|
||||
PATH="${_PATH-}${_PATH:+${PATH:+:}}$PATH"
|
||||
```
|
||||
|
||||
With the real `hello` on the `PATH`, the `installPhase` should hopefully make sense.
|
||||
|
||||
|
|
@ -101,6 +113,7 @@ With the real `hello` on the `PATH`, the `installPhase` should hopefully make se
|
|||
|
||||
The `buildInputs` covers direct dependencies, but what about indirect dependencies where one package needs a second package which needs a third? Nix itself handles this just fine, understanding various dependency closures as covered in previous builds. But what about the conveniences that `buildInputs` provides, namely accumulating in `pkgs` environment variable and inclusion of `pkg/bin` directories on the `PATH`? For this, stdenv provides the `propagatedBuildInputs`:
|
||||
|
||||
```nix
|
||||
let
|
||||
|
||||
nixpkgs = import <nixpkgs> { };
|
||||
|
|
@ -147,11 +160,13 @@ The `buildInputs` covers direct dependencies, but what about indirect dependenci
|
|||
};
|
||||
in
|
||||
wrappedHello
|
||||
```
|
||||
|
||||
See how the intermediate package has a `propagatedBuildInputs` dependency, but the wrapper only needs a `buildInputs` dependency on the intermediary.
|
||||
|
||||
How does this work? You might think we do something in Nix, but actually it's done not at eval time but at build time in bash. let's look at part of the `fixupPhase` of stdenv:
|
||||
|
||||
```sh
|
||||
fixupPhase() {
|
||||
|
||||
## Elided
|
||||
|
|
@ -164,9 +179,11 @@ How does this work? You might think we do something in Nix, but actually it's do
|
|||
## Elided
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
This dumps the propagated build inputs in a so-named file in `$out/nix-support/`. Then, back in `findInputs` look at the lines at the bottom we elided before:
|
||||
|
||||
```sh
|
||||
findInputs() {
|
||||
local pkg=$1
|
||||
|
||||
|
|
@ -178,15 +195,18 @@ This dumps the propagated build inputs in a so-named file in `$out/nix-support/`
|
|||
done
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
See how `findInputs` is actually recursive, looking at the propagated build inputs of each dependency, and those dependencies' propagated build inputs, etc.
|
||||
|
||||
We actually simplified the `findInputs` call site from before; `propagatedBuildInputs` is also looped over in reality:
|
||||
|
||||
```sh
|
||||
pkgs=""
|
||||
for i in $buildInputs $propagatedBuildInputs; do
|
||||
findInputs $i
|
||||
done
|
||||
```
|
||||
|
||||
This demonstrates an important point. For the _current_ package alone, it doesn't matter whether a dependency is propagated or not. It will be processed the same way: called with `findInputs` and `addToEnv`. (The packages discovered by `findInputs`, which are also accumulated in `pkgs` and passed to `addToEnv`, are also the same in both cases.) Downstream however, it certainly does matter because only the propagated immediate dependencies are put in the `$out/nix-support/propagated-build-inputs`.
|
||||
|
||||
|
|
@ -196,6 +216,7 @@ As we mentioned above, sometimes dependencies need to influence the packages tha
|
|||
|
||||
Setup hooks are the basic building block we have for this. In nixpkgs, a "hook" is basically a bash callback, and a setup hook is no exception. Let's look at the last part of `findInputs` we haven't covered:
|
||||
|
||||
```sh
|
||||
findInputs() {
|
||||
local pkg=$1
|
||||
|
||||
|
|
@ -208,6 +229,7 @@ Setup hooks are the basic building block we have for this. In nixpkgs, a "hook"
|
|||
## More goes here in reality that we can ignore for now.
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
If a package includes the path `pkg/nix-support/setup-hook`, it will be sourced by any stdenv-based build including that as a dependency.
|
||||
|
||||
|
|
@ -221,6 +243,7 @@ As a first step, we can move that logic to a setup hook on the C compiler; indee
|
|||
|
||||
The other half of `addToEnv` is:
|
||||
|
||||
```sh
|
||||
addToEnv() {
|
||||
local pkg=$1
|
||||
|
||||
|
|
@ -231,16 +254,19 @@ The other half of `addToEnv` is:
|
|||
$i $pkg
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
Functions listed in `envHooks` are applied to every package passed to `addToEnv`. One can write a setup hook like:
|
||||
|
||||
```sh
|
||||
anEnvHook() {
|
||||
local pkg=$1
|
||||
|
||||
echo "I'm depending on "$pkg""
|
||||
echo "I'm depending on \"$pkg\""
|
||||
}
|
||||
|
||||
envHooks+=(anEnvHook)
|
||||
```
|
||||
|
||||
and if one dependency has that setup hook then all of them will be so `echo`ed. Allowing dependencies to learn about their _sibling_ dependencies is exactly what compilers need.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue