doc/builders/trivial-builders.chapter.md

   1 # Trivial builders {#chap-trivial-builders}
   2
   3 Nixpkgs provides a couple of functions that help with building derivations. The most important one, `stdenv.mkDerivation`, has already been documented above. The following functions wrap `stdenv.mkDerivation`, making it easier to use in certain cases.
   4
   5 ## `runCommand` {#trivial-builder-runCommand}
   6
   7 This takes three arguments, `name`, `env`, and `buildCommand`. `name` is just the name that Nix will append to the store path in the same way that `stdenv.mkDerivation` uses its `name` attribute. `env` is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped `stdenv.mkDerivation`. `buildCommand` specifies the commands that will be run to create this derivation. Note that you will need to create `$out` for Nix to register the command as successful.
   8
   9 An example of using `runCommand` is provided below.
  10
  11 ```nix
  12 (import <nixpkgs> {}).runCommand "my-example" {} ''
  13   echo My example command is running
  14
  15   mkdir $out
  16
  17   echo I can write data to the Nix store > $out/message
  18
  19   echo I can also run basic commands like:
  20
  21   echo ls
  22   ls
  23
  24   echo whoami
  25   whoami
  26
  27   echo date
  28   date
  29 ''
  30 ```
  31
  32 ## `runCommandCC` {#trivial-builder-runCommandCC}
  33
  34 This works just like `runCommand`. The only difference is that it also provides a C compiler in `buildCommand`'s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
  35
  36 ## `runCommandLocal` {#trivial-builder-runCommandLocal}
  37
  38 Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network round-trip and can speed up a build.
  39
  40 ::: {.note}
  41 This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
  42 :::
  43
  44 ## `writeTextFile`, `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin` {#trivial-builder-writeText}
  45
  46 These functions write `text` to the Nix store. This is useful for creating scripts from Nix expressions. `writeTextFile` takes an attribute set and expects two arguments, `name` and `text`. `name` corresponds to the name used in the Nix store path. `text` will be the contents of the file. You can also set `executable` to true to make this file have the executable bit set.
  47
  48 Many more commands wrap `writeTextFile` including `writeText`, `writeTextDir`, `writeScript`, and `writeScriptBin`. These are convenience functions over `writeTextFile`.
  49
  50 Here are a few examples:
  51 ```nix
  52 # Writes my-file to /nix/store/<store path>
  53 writeTextFile {
  54   name = "my-file";
  55   text = ''
  56     Contents of File
  57   '';
  58 }
  59 # See also the `writeText` helper function below.
  60
  61 # Writes executable my-file to /nix/store/<store path>/bin/my-file
  62 writeTextFile {
  63   name = "my-file";
  64   text = ''
  65     Contents of File
  66   '';
  67   executable = true;
  68   destination = "/bin/my-file";
  69 }
  70 # Writes contents of file to /nix/store/<store path>
  71 writeText "my-file"
  72   ''
  73   Contents of File
  74   '';
  75 # Writes contents of file to /nix/store/<store path>/share/my-file
  76 writeTextDir "share/my-file"
  77   ''
  78   Contents of File
  79   '';
  80 # Writes my-file to /nix/store/<store path> and makes executable
  81 writeScript "my-file"
  82   ''
  83   Contents of File
  84   '';
  85 # Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
  86 writeScriptBin "my-file"
  87   ''
  88   Contents of File
  89   '';
  90 # Writes my-file to /nix/store/<store path> and makes executable.
  91 writeShellScript "my-file"
  92   ''
  93   Contents of File
  94   '';
  95 # Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
  96 writeShellScriptBin "my-file"
  97   ''
  98   Contents of File
  99   '';
 100
 101 ```
 102
 103 ## `concatTextFile`, `concatText`, `concatScript` {#trivial-builder-concatText}
 104
 105 These functions concatenate `files` to the Nix store in a single file. This is useful for configuration files structured in lines of text. `concatTextFile` takes an attribute set and expects two arguments, `name` and `files`. `name` corresponds to the name used in the Nix store path. `files` will be the files to be concatenated. You can also set `executable` to true to make this file have the executable bit set.
 106 `concatText` and`concatScript` are simple wrappers over `concatTextFile`.
 107
 108 Here are a few examples:
 109 ```nix
 110
 111 # Writes my-file to /nix/store/<store path>
 112 concatTextFile {
 113   name = "my-file";
 114   files = [ drv1 "${drv2}/path/to/file" ];
 115 }
 116 # See also the `concatText` helper function below.
 117
 118 # Writes executable my-file to /nix/store/<store path>/bin/my-file
 119 concatTextFile {
 120   name = "my-file";
 121   files = [ drv1 "${drv2}/path/to/file" ];
 122   executable = true;
 123   destination = "/bin/my-file";
 124 }
 125 # Writes contents of files to /nix/store/<store path>
 126 concatText "my-file" [ file1 file2 ]
 127
 128 # Writes contents of files to /nix/store/<store path>
 129 concatScript "my-file" [ file1 file2 ]
 130 ```
 131
 132 ## `writeShellApplication` {#trivial-builder-writeShellApplication}
 133
 134 This can be used to easily produce a shell script that has some dependencies (`runtimeInputs`). It automatically sets the `PATH` of the script to contain all of the listed inputs, sets some sanity shellopts (`errexit`, `nounset`, `pipefail`), and checks the resulting script with [`shellcheck`](https://github.com/koalaman/shellcheck).
 135
 136 For example, look at the following code:
 137
 138 ```nix
 139 writeShellApplication {
 140   name = "show-nixos-org";
 141
 142   runtimeInputs = [ curl w3m ];
 143
 144   text = ''
 145     curl -s 'https://nixos.org' | w3m -dump -T text/html
 146   '';
 147 }
 148 ```
 149
 150 Unlike with normal `writeShellScriptBin`, there is no need to manually write out `${curl}/bin/curl`, setting the PATH
 151 was handled by `writeShellApplication`. Moreover, the script is being checked with `shellcheck` for more strict
 152 validation.
 153
 154 ## `symlinkJoin` {#trivial-builder-symlinkJoin}
 155
 156 This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
 157 Here is an example:
 158 ```nix
 159 # adds symlinks of hello and stack to current build and prints "links added"
 160 symlinkJoin { name = "myexample"; paths = [ pkgs.hello pkgs.stack ]; postBuild = "echo links added"; }
 161 ```
 162 This creates a derivation with a directory structure like the following:
 163 ```
 164 /nix/store/sglsr5g079a5235hy29da3mq3hv8sjmm-myexample
 165 |-- bin
 166 |   |-- hello -> /nix/store/qy93dp4a3rqyn2mz63fbxjg228hffwyw-hello-2.10/bin/hello
 167 |   `-- stack -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/bin/stack
 168 `-- share
 169     |-- bash-completion
 170     |   `-- completions
 171     |       `-- stack -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/share/bash-completion/completions/stack
 172     |-- fish
 173     |   `-- vendor_completions.d
 174     |       `-- stack.fish -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/share/fish/vendor_completions.d/stack.fish
 175 ...
 176 ```
 177
 178 ## `writeReferencesToFile` {#trivial-builder-writeReferencesToFile}
 179
 180 Writes the closure of transitive dependencies to a file.
 181
 182 This produces the equivalent of `nix-store -q --requisites`.
 183
 184 For example,
 185
 186 ```nix
 187 writeReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
 188 ```
 189
 190 produces an output path `/nix/store/<hash>-runtime-deps` containing
 191
 192 ```nix
 193 /nix/store/<hash>-hello-2.10
 194 /nix/store/<hash>-hi
 195 /nix/store/<hash>-libidn2-2.3.0
 196 /nix/store/<hash>-libunistring-0.9.10
 197 /nix/store/<hash>-glibc-2.32-40
 198 ```
 199
 200 You can see that this includes `hi`, the original input path,
 201 `hello`, which is a direct reference, but also
 202 the other paths that are indirectly required to run `hello`.
 203
 204 ## `writeDirectReferencesToFile` {#trivial-builder-writeDirectReferencesToFile}
 205
 206 Writes the set of references to the output file, that is, their immediate dependencies.
 207
 208 This produces the equivalent of `nix-store -q --references`.
 209
 210 For example,
 211
 212 ```nix
 213 writeDirectReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
 214 ```
 215
 216 produces an output path `/nix/store/<hash>-runtime-references` containing
 217
 218 ```nix
 219 /nix/store/<hash>-hello-2.10
 220 ```
 221
 222 but none of `hello`'s dependencies because those are not referenced directly
 223 by `hi`'s output.