`nixpkgs` provides a variety of wrapper functions that help build very simple derivations. Like [`stdenv.mkDerivation`](#sec-using-stdenv), each of these builders creates and returns a derivation, but the composition of the arguments passed to each are different (usually simpler) than the arguments that must be passed to `stdenv.mkDerivation`.
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.
Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1sexecutiontime).Itsavesonthenetworkround-tripandcanspeedupabuild.
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`.
`nixpkgs` provides a number of functions that produce derivations which write text into the Nix store. These include `writeTextFile`, `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin`, `writeShellScript`, and `writeShellScriptBin`, each of which is documented below.
These are useful for creating files from Nix expressions, which may be scripts or non-executable text files, depending on which of the functions is used and the arguments it takes.
The result of each of these functions will be a derivation. When you coerce the resulting derivation to text, it will evaluate to the *store path*. Importantly, it will not include the destination subpath produced by the particular function. So, for example, given the following expression:
```nix
my-file = writeTextFile {
name = "my-file";
text = ''
Contents of File
'';
destination = "/share/my-file";
}
```
If `my-file` is coerced to text, it will resolve to `/nix/store/<store path>`, like any other derivation. It will *not* evaluate to `/nix/store/<store path>/share/my-file`. So to use it elsewhere, as an example (in this case, within a shell script you're writing in a Nix expression via `writeShellScript`), you might do:
```nix
writeShellScript "evaluate-my-file.sh" ''
cat ${my-file}/share/my-file
'';
```
This will produce the desired result. However, the following will not, it will fail because the store path is a directory, and is not the `my-file` file.
`writeTextFile` takes an attribute set and expects it to contain at least two attributes: `name` and `text`.
`name` corresponds to the name used in the Nix store path identifier.
`text` will be the contents of the file.
The resulting store path will include some variation of the name, and it will be a file unless `destination` (see below) is used, in which case it will be a directory.
Common optional attributes in the attribute set are:
`executable`: make this file have the executable bit set. Defaults to `false`
`destination`: supplies a subpath under the derivation's Nix store ouput path into which to create the file. It may contain directory path elements, these are created automatically when the derivation is realized. Defaults to `""`, which indicates that the store path itself will be a file containing the text contents.
Other less-frequently used optional attributes are:
`checkPhase`: commands to run after generating the file, e.g. lints. It defaults to `""` (no checking).
`meta`: Additional metadata for the derivation. It defaults to `{}`.
`allowSubstitutes`: whether to allow substituting from a binary cache. It fefaults to `false`, as the operation is assumed to be faster performed locally. You may want to set this to true if the `checkPhase` step is expensive.
`preferLocalBuild`: whether to prefer building locally, even if faster remote builders are available. It defaults to `true` for the same reason `allowSubstitutes` defaults to `false`.
::: {.example #ex-writeTextFile}
# Usages of `writeTextFile`
```nix
# Writes my-file to /nix/store/<store path>/some/subpath/my-cool-script,
# making it executable and also supplies values for the less-used options
The commands `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin`, `writeShellScript`, and `writeShellScriptBin` documented below are convenience functions that wrap `writeTextFile`.
:::
### `writeText` {#trivial-builder-writeText}
`writeText` takes two arguments: `name` and `text`.
`name` is the name used in the Nix store path. `text` will be the contents of the file.
The store path will include the the name, and it will be a file. Any path separators and shell-reserved elements in the name are escaped to create the store path identifier.
`writeScript` takes two arguments: `name` and `text`.
`name` is the name used in the Nix store path. `text` will be the contents of the file. The created file is marked as executable.
The store path will include the the name, and it will be a file. Any path separators and shell-reserved elements in the name are escaped to create the store path identifier.
`writeScriptBin` takes two arguments: `name` and `text`.
`name` is the name used in the Nix store path and within the file generated under the store path. `text` will be the contents of the file. The created file is marked as executable.
The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
The store path will include the the name, and it will be a directory. Any path separators and shell-reserved elements in the name are escaped to create the store path identifier.
`writeShellScript` takes two arguments: `name` and `text`.
`name` is the name used in the Nix store path. `text` will be the contents of the file. The created file is marked as executable. This function is almost exactly like `writeScript`, but it prepends a shebang line that points to the runtime shell (usually bash) at the top of the file contents.
The store path will include the the name, and it will be a file. Any path separators and shell-reserved elements in the name are escaped to create the store path identifier.
`writeShellScriptBin` takes two arguments: `name` and `text`.
`name` is the name used in the Nix store path and within the file generated under the store path. `text` will be the contents of the file. This function is almost exactly like `writeScriptBin`, but it prepends a shebang line that points to the runtime shell (usually bash) at the top of the file contents.
The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
The store path will include the the name, and it will be a directory. Any path separators and shell-reserved elements in the name are escaped to create the store path identifier.
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.
`concatText` and`concatScript` are simple wrappers over `concatTextFile`.
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).
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.
