nathan/nixpkgs
1
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2026-10-03 21:40:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into master

Browse Source
This commit is contained in:
PL
2024-03-29 14:38:47 +01:00
committed by GitHub
parent 2df36c1c9b 6d3145bb2a
commit cd2faa0684
2339 changed files with 71798 additions and 24560 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
.github/CODEOWNERS vendored
View File

@@ -159,7 +159,6 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @raitobezarius @ma27
# C compilers
/pkgs/development/compilers/gcc
/pkgs/development/compilers/llvm @RaitoBezarius
/pkgs/development/compilers/emscripten @raitobezarius
/doc/languages-frameworks/emscripten.section.md @raitobezarius
@@ -204,10 +203,6 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
/nixos/modules/services/databases/postgresql.nix @thoughtpolice
/nixos/tests/postgresql.nix @thoughtpolice
# Linux kernel
/pkgs/os-specific/linux/kernel @raitobezarius
/pkgs/top-level/linux-kernels.nix @raitobezarius
# Hardened profile & related modules
/nixos/modules/profiles/hardened.nix @joachifm
/nixos/modules/security/hidepid.nix @joachifm

2
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@@ -38,7 +38,7 @@ Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!
List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
Reviewing guidelines: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#reviewing-contributions
-->
---

15
.github/labeler.yml vendored
View File

@@ -295,6 +295,21 @@
- pkgs/test/texlive/**
- pkgs/tools/typesetting/tex/**/*
"6.topic: testing":
- any:
- changed-files:
- any-glob-to-any-file:
# NOTE: Let's keep the scope limited to test frameworks that are
# *developed in this repo*;
# - not individual tests
# - not packages for test frameworks
- nixos/lib/testing/**
- nixos/lib/test-driver/**
- nixos/tests/nixos-test-driver/**
- nixos/lib/testing-python.nix # legacy
- nixos/tests/make-test-python.nix # legacy
# lib/debug.nix has a test framework (runTests) but it's not the main focus
"6.topic: vim":
- any:
- changed-files:

20
.github/workflows/check-by-name.yml vendored
View File

@@ -1,11 +1,9 @@
# Checks pkgs/by-name (see pkgs/by-name/README.md)
# using the nixpkgs-check-by-name tool (see pkgs/test/nixpkgs-check-by-name)
# using the nixpkgs-check-by-name tool (see https://github.com/NixOS/nixpkgs-check-by-name)
#
# When you make changes to this workflow, also update pkgs/test/nixpkgs-check-by-name/scripts/run-local.sh adequately
# When you make changes to this workflow, also update pkgs/test/check-by-name/run-local.sh adequately
name: Check pkgs/by-name
# The tool is pinned to a pre-built version on Hydra,
# see pkgs/test/nixpkgs-check-by-name/scripts/README.md
on:
# Using pull_request_target instead of pull_request avoids having to approve first time contributors
pull_request_target:
@@ -24,8 +22,7 @@ permissions:
jobs:
check:
# This is x86_64-linux, for which the tool is always prebuilt on the nixos-* channels,
# as specified in nixos/release-combined.nix
# This needs to be x86_64-linux, because we depend on the tooling being pre-built in the GitHub releases
runs-on: ubuntu-latest
# This should take 1 minute at most, but let's be generous.
# The default of 6 hours is definitely too long
@@ -100,11 +97,14 @@ jobs:
echo "base=$base" >> "$GITHUB_ENV"
- uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
- name: Fetching the pinned tool
# Update the pinned version using pkgs/test/nixpkgs-check-by-name/scripts/update-pinned-tool.sh
# Update the pinned version using pkgs/test/check-by-name/update-pinned-tool.sh
run: |
# Get the direct /nix/store path from the pin to avoid having to evaluate Nixpkgs
toolPath=$(jq -r '."ci-path"' pkgs/test/nixpkgs-check-by-name/scripts/pinned-tool.json)
# This asks the substituter for the path, which should be there because Hydra will have pre-built and pushed it
# The pinned version of the tooling to use
toolVersion=$(<pkgs/test/check-by-name/pinned-version.txt)
# Fetch the x86_64-linux-specific release artifact containing the Gzipped NAR of the pre-built tool
toolPath=$(curl -sSfL https://github.com/NixOS/nixpkgs-check-by-name/releases/download/"$toolVersion"/x86_64-linux.nar.gz \
| gzip -cd | nix-store --import | tail -1)
# Adds a result symlink as a GC root
nix-store --realise "$toolPath" --add-root result
- name: Running nixpkgs-check-by-name
run: |

104
CONTRIBUTING.md
View File

@@ -557,7 +557,7 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
foo {
arg = ...;
arg = <...>;
}
```
@@ -566,14 +566,14 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
foo
{
arg = ...;
arg = <...>;
}
```
Also fine is
```nix
foo { arg = ...; }
foo { arg = <...>; }
```
if it's a short call.
@@ -581,41 +581,45 @@ Names of files and directories should be in lowercase, with dashes between words
- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
```nix
# A long list.
list = [
elem1
elem2
elem3
];
{
# A long list.
list = [
elem1
elem2
elem3
];
# A long attribute set.
attrs = {
attr1 = short_expr;
attr2 =
if true then big_expr else big_expr;
};
# A long attribute set.
attrs = {
attr1 = short_expr;
attr2 =
if true then big_expr else big_expr;
};
# Combined
listOfAttrs = [
{
attr1 = 3;
attr2 = "fff";
}
{
attr1 = 5;
attr2 = "ggg";
}
];
# Combined
listOfAttrs = [
{
attr1 = 3;
attr2 = "fff";
}
{
attr1 = 5;
attr2 = "ggg";
}
];
}
```
- Short lists or attribute sets can be written on one line:
```nix
# A short list.
list = [ elem1 elem2 elem3 ];
{
# A short list.
list = [ elem1 elem2 elem3 ];
# A short set.
attrs = { x = 1280; y = 1024; };
# A short set.
attrs = { x = 1280; y = 1024; };
}
```
- Breaking in the middle of a function argument can give hard-to-read code, like
@@ -649,7 +653,7 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
{ arg1, arg2 }:
assert system == "i686-linux";
stdenv.mkDerivation { ...
stdenv.mkDerivation { /* ... */ }
```
not
@@ -657,41 +661,41 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
{ arg1, arg2 }:
assert system == "i686-linux";
stdenv.mkDerivation { ...
stdenv.mkDerivation { /* ... */ }
```
- Function formal arguments are written as:
```nix
{ arg1, arg2, arg3 }:
{ arg1, arg2, arg3 }: { /* ... */ }
```
but if they don't fit on one line they're written as:
```nix
{ arg1, arg2, arg3
, arg4, ...
, # Some comment...
argN
}:
, arg4
# Some comment...
, argN
}: { }
```
- Functions should list their expected arguments as precisely as possible. That is, write
```nix
{ stdenv, fetchurl, perl }: ...
{ stdenv, fetchurl, perl }: <...>
```
instead of
```nix
args: with args; ...
args: with args; <...>
```
or
```nix
{ stdenv, fetchurl, perl, ... }: ...
{ stdenv, fetchurl, perl, ... }: <...>
```
For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
@@ -700,7 +704,7 @@ Names of files and directories should be in lowercase, with dashes between words
{ stdenv, doCoverageAnalysis ? false, ... } @ args:
stdenv.mkDerivation (args // {
... if doCoverageAnalysis then "bla" else "" ...
foo = if doCoverageAnalysis then "bla" else "";
})
```
@@ -710,32 +714,40 @@ Names of files and directories should be in lowercase, with dashes between words
args:
args.stdenv.mkDerivation (args // {
... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
foo = if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "";
})
```
- Unnecessary string conversions should be avoided. Do
```nix
rev = version;
{
rev = version;
}
```
instead of
```nix
rev = "${version}";
{
rev = "${version}";
}
```
- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
```nix
buildInputs = lib.optional stdenv.isDarwin iconv;
{
buildInputs = lib.optional stdenv.isDarwin iconv;
}
```
instead of
```nix
buildInputs = if stdenv.isDarwin then [ iconv ] else null;
{
buildInputs = if stdenv.isDarwin then [ iconv ] else null;
}
```
As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.

11
README.md
View File

@@ -1,9 +1,10 @@
<p align="center">
<a href="https://nixos.org#gh-light-mode-only">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo"/>
</a>
<a href="https://nixos.org#gh-dark-mode-only">
<img src="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png" width="500px" alt="NixOS logo"/>
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo">
</picture>
</a>
</p>

14
doc/build-helpers/fetchers.chapter.md
View File

@@ -30,7 +30,7 @@ For example, consider the following fetcher:
fetchurl {
url = "http://www.example.org/hello-1.0.tar.gz";
hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
};
}
```
A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.
@@ -39,7 +39,7 @@ A common mistake is to update a fetcher’s URL, or a version parameter, without
fetchurl {
url = "http://www.example.org/hello-1.1.tar.gz";
hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
};
}
```
**This will reuse the old contents**.
@@ -49,7 +49,7 @@ Remember to invalidate the hash argument, in this case by setting the `hash` att
fetchurl {
url = "http://www.example.org/hello-1.1.tar.gz";
hash = "";
};
}
```
Use the resulting error message to determine the correct hash.
@@ -123,7 +123,7 @@ Here is an example of `fetchDebianPatch` in action:
buildPythonPackage rec {
pname = "pysimplesoap";
version = "1.16.2";
src = ...;
src = <...>;
patches = [
(fetchDebianPatch {
@@ -134,7 +134,7 @@ buildPythonPackage rec {
})
];
...
# ...
}
```
@@ -243,7 +243,7 @@ This is a useful last-resort workaround for license restrictions that prohibit r
If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
```
```nix
requireFile {
name = "jdk-${version}_linux-x64_bin.tar.gz";
url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
@@ -270,7 +270,7 @@ It produces packages that cannot be built automatically.
`fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
```
```nix
{ fetchtorrent }:
fetchtorrent {

1
doc/build-helpers/images/dockertools.section.md
View File

@@ -1177,6 +1177,7 @@ dockerTools.buildImage {
hello
dockerTools.binSh
];
}
```
After building the image and loading it in Docker, we can create a container based on it and enter a shell inside the container.

12
doc/build-helpers/special/checkpoint-build.section.md
View File

@@ -9,13 +9,17 @@ However, we can tell Nix explicitly what the previous build state was, by repres
To change a normal derivation to a checkpoint based build, these steps must be taken:
- apply `prepareCheckpointBuild` on the desired derivation, e.g.
```nix
checkpointArtifacts = (pkgs.checkpointBuildTools.prepareCheckpointBuild pkgs.virtualbox);
{
checkpointArtifacts = (pkgs.checkpointBuildTools.prepareCheckpointBuild pkgs.virtualbox);
}
```
- change something you want in the sources of the package, e.g. use a source override:
```nix
changedVBox = pkgs.virtualbox.overrideAttrs (old: {
src = path/to/vbox/sources;
});
{
changedVBox = pkgs.virtualbox.overrideAttrs (old: {
src = path/to/vbox/sources;
});
}
```
- use `mkCheckpointBuild changedVBox checkpointArtifacts`
- enjoy shorter build times

54
doc/build-helpers/testers.chapter.md
View File

@@ -14,11 +14,13 @@ If the `moduleNames` argument is omitted, `hasPkgConfigModules` will use `meta.p
# Check that `pkg-config` modules are exposed using default values
```nix
passthru.tests.pkg-config = testers.hasPkgConfigModules {
package = finalAttrs.finalPackage;
};
{
passthru.tests.pkg-config = testers.hasPkgConfigModules {
package = finalAttrs.finalPackage;
};
meta.pkgConfigModules = [ "libfoo" ];
meta.pkgConfigModules = [ "libfoo" ];
}
```
:::
@@ -28,10 +30,12 @@ meta.pkgConfigModules = [ "libfoo" ];
# Check that `pkg-config` modules are exposed using explicit module names
```nix
passthru.tests.pkg-config = testers.hasPkgConfigModules {
package = finalAttrs.finalPackage;
moduleNames = [ "libfoo" ];
};
{
passthru.tests.pkg-config = testers.hasPkgConfigModules {
package = finalAttrs.finalPackage;
moduleNames = [ "libfoo" ];
};
}
```
:::
@@ -55,7 +59,9 @@ The default argument to the command is `--version`, and the version to be checke
This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.
```nix
passthru.tests.version = testers.testVersion { package = hello; };
{
passthru.tests.version = testers.testVersion { package = hello; };
}
```
:::
@@ -70,13 +76,15 @@ This means that an output like "leetcode 0.4.21" would fail the tests, and an ou
A common usage of the `version` attribute is to specify `version = "v${version}"`.
```nix
version = "0.4.2";
{
version = "0.4.2";
passthru.tests.version = testers.testVersion {
package = leetcode-cli;
command = "leetcode -V";
version = "leetcode ${version}";
};
passthru.tests.version = testers.testVersion {
package = leetcode-cli;
command = "leetcode -V";
version = "leetcode ${version}";
};
}
```
:::
@@ -116,7 +124,7 @@ runCommand "example" {
grep -F 'failing though' $failed/testBuildFailure.log
[[ 3 = $(cat $failed/testBuildFailure.exit) ]]
touch $out
'';
''
```
:::
@@ -193,12 +201,14 @@ once to get a derivation hash, and again to produce the final fixed output deriv
# Prevent nix from reusing the output of a fetcher
```nix
tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
name = "nix-source";
url = "https://github.com/NixOS/nix";
rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
};
{
tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
name = "nix-source";
url = "https://github.com/NixOS/nix";
rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
};
}
```
:::

38
doc/build-helpers/trivial-build-helpers.chapter.md
View File

@@ -76,12 +76,14 @@ If you need to refer to the resulting files somewhere else in a Nix expression,
For example, if the file destination is a directory:
```nix
my-file = writeTextFile {
name = "my-file";
text = ''
Contents of File
'';
destination = "/share/my-file";
{
my-file = writeTextFile {
name = "my-file";
text = ''
Contents of File
'';
destination = "/share/my-file";
};
}
```
@@ -90,7 +92,7 @@ Remember to append "/share/my-file" to the resulting store path when using it el
```nix
writeShellScript "evaluate-my-file.sh" ''
cat ${my-file}/share/my-file
'';
''
```
::::
@@ -287,7 +289,7 @@ writeTextFile {
};
allowSubstitutes = true;
preferLocalBuild = false;
};
}
```
:::
@@ -351,7 +353,7 @@ Write the string `Contents of File` to `/nix/store/<store path>`:
writeText "my-file"
''
Contents of File
'';
''
```
:::
@@ -391,7 +393,7 @@ Write the string `Contents of File` to `/nix/store/<store path>/share/my-file`:
writeTextDir "share/my-file"
''
Contents of File
'';
''
```
:::
@@ -433,7 +435,7 @@ Write the string `Contents of File` to `/nix/store/<store path>` and make the fi
writeScript "my-file"
''
Contents of File
'';
''
```
:::
@@ -475,7 +477,7 @@ The store path will include the the name, and it will be a directory.
writeScriptBin "my-script"
''
echo "hi"
'';
''
```
:::
@@ -488,7 +490,7 @@ writeTextFile {
echo "hi"
'';
executable = true;
destination = "bin/my-script"
destination = "bin/my-script";
}
```
@@ -519,7 +521,7 @@ This function is almost exactly like [](#trivial-builder-writeScript), except th
writeShellScript "my-script"
''
echo "hi"
'';
''
```
:::
@@ -562,7 +564,7 @@ This function is a combination of [](#trivial-builder-writeShellScript) and [](#
writeShellScriptBin "my-script"
''
echo "hi"
'';
''
```
:::
@@ -576,7 +578,7 @@ writeTextFile {
echo "hi"
'';
executable = true;
destination = "bin/my-script"
destination = "bin/my-script";
}
```
@@ -674,7 +676,7 @@ writeClosure [ (writeScriptBin "hi" ''${hello}/bin/hello'') ]
produces an output path `/nix/store/<hash>-runtime-deps` containing
```nix
```
/nix/store/<hash>-hello-2.10
/nix/store/<hash>-hi
/nix/store/<hash>-libidn2-2.3.0
@@ -700,7 +702,7 @@ writeDirectReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
produces an output path `/nix/store/<hash>-runtime-references` containing
```nix
```
/nix/store/<hash>-hello-2.10
```

29
doc/functions/nix-gitignore.section.md
View File

@@ -7,27 +7,30 @@
`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
```nix
{ pkgs ? import <nixpkgs> {} }:
{ pkgs ? import <nixpkgs> {} }: {
nix-gitignore.gitignoreSource [] ./source
src = nix-gitignore.gitignoreSource [] ./source;
# Simplest version
nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source
src = nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source;
# This one reads the ./source/.gitignore and concats the auxiliary ignores
nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source
src = nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source;
# Use this string as gitignore, don't read ./source/.gitignore.
nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source
src = nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n" ~/.gitignore] ./source;
# It also accepts a list (of strings and paths) that will be concatenated
# once the paths are turned to strings via readFile.
}
```
These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: true)`:
```nix
gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
gitignoreSource = gitignoreFilterSource (_: _: true);
{
gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
gitignoreSource = gitignoreFilterSource (_: _: true);
}
```
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
@@ -35,7 +38,9 @@ Those filter functions accept the same arguments the `builtins.filterSource` fun
If you want to make your own filter from scratch, you may use
```nix
gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
{
gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
}
```
## gitignore files in subdirectories {#sec-pkgs-nix-gitignore-usage-recursive}
@@ -43,7 +48,9 @@ gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
```nix
gitignoreFilterRecursiveSource = filter: patterns: root:
# OR
gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
{
# gitignoreFilterRecursiveSource = filter: patterns: root:
# OR
gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
}
```

4
doc/hooks/breakpoint.section.md
View File

@@ -3,7 +3,9 @@
This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
```nix
nativeBuildInputs = [ breakpointHook ];
{
nativeBuildInputs = [ breakpointHook ];
}
```
When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.

32
doc/hooks/installShellFiles.section.md
View File

@@ -7,19 +7,21 @@ The `installManPage` function takes one or more paths to manpages to install. Th
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
```nix
nativeBuildInputs = [ installShellFiles ];
postInstall = ''
installManPage doc/foobar.1 doc/barfoo.3
# explicit behavior
installShellCompletion --bash --name foobar.bash share/completions.bash
installShellCompletion --fish --name foobar.fish share/completions.fish
installShellCompletion --zsh --name _foobar share/completions.zsh
# implicit behavior
installShellCompletion share/completions/foobar.{bash,fish,zsh}
# using named fd
installShellCompletion --cmd foobar \
--bash <($out/bin/foobar --bash-completion) \
--fish <($out/bin/foobar --fish-completion) \
--zsh <($out/bin/foobar --zsh-completion)
'';
{
nativeBuildInputs = [ installShellFiles ];
postInstall = ''
installManPage doc/foobar.1 doc/barfoo.3
# explicit behavior
installShellCompletion --bash --name foobar.bash share/completions.bash
installShellCompletion --fish --name foobar.fish share/completions.fish
installShellCompletion --zsh --name _foobar share/completions.zsh
# implicit behavior
installShellCompletion share/completions/foobar.{bash,fish,zsh}
# using named fd
installShellCompletion --cmd foobar \
--bash <($out/bin/foobar --bash-completion) \
--fish <($out/bin/foobar --fish-completion) \
--zsh <($out/bin/foobar --zsh-completion)
'';
}
```

13
doc/hooks/mpi-check-hook.section.md
View File

@@ -12,13 +12,14 @@ Example:
```nix
{ mpiCheckPhaseHook, mpi, ... }:
{
# ...
...
nativeCheckInputs = [
openssh
mpiCheckPhaseHook
];
nativeCheckInputs = [
openssh
mpiCheckPhaseHook
];
}
```

5
doc/languages-frameworks/agda.section.md
View File

@@ -114,7 +114,7 @@ This can be overridden by a different version of `ghc` as follows:
```nix
agda.withPackages {
pkgs = [ ... ];
pkgs = [ /* ... */ ];
ghc = haskell.compiler.ghcHEAD;
}
```
@@ -180,6 +180,7 @@ To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/d
```nix
{ mkDerivation, standard-library, fetchFromGitHub }:
{}
```
Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you
@@ -193,7 +194,7 @@ mkDerivation {
version = "1.5.0";
pname = "iowa-stdlib";
src = ...
src = <...>;
libraryFile = "";
libraryName = "IAL-1.3";

26
doc/languages-frameworks/android.section.md
View File

@@ -104,18 +104,20 @@ pull from:
repo.json to the Nix store based on the given repository XMLs.
```nix
repoXmls = {
packages = [ ./xml/repository2-1.xml ];
images = [
./xml/android-sys-img2-1.xml
./xml/android-tv-sys-img2-1.xml
./xml/android-wear-sys-img2-1.xml
./xml/android-wear-cn-sys-img2-1.xml
./xml/google_apis-sys-img2-1.xml
./xml/google_apis_playstore-sys-img2-1.xml
];
addons = [ ./xml/addon2-1.xml ];
};
{
repoXmls = {
packages = [ ./xml/repository2-1.xml ];
images = [
./xml/android-sys-img2-1.xml
./xml/android-tv-sys-img2-1.xml
./xml/android-wear-sys-img2-1.xml
./xml/android-wear-cn-sys-img2-1.xml
./xml/google_apis-sys-img2-1.xml
./xml/google_apis_playstore-sys-img2-1.xml
];
addons = [ ./xml/addon2-1.xml ];
};
}
```
When building the above expression with:

8
doc/languages-frameworks/beam.section.md
View File

@@ -117,6 +117,7 @@ If there are git dependencies.
- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
```nix
{
mixNixDeps = import ./mix.nix {
inherit beamPackages lib;
overrides = (final: prev: {
@@ -138,8 +139,9 @@ If there are git dependencies.
# you can re-use the same beamDeps argument as generated
beamDeps = with final; [ prometheus ];
};
});
};
});
};
}
```
You will need to run the build process once to fix the hash to correspond to your new git src.
@@ -153,11 +155,13 @@ Practical steps
- start with the following argument to mixRelease
```nix
{
mixFodDeps = fetchMixDeps {
pname = "mix-deps-${pname}";
inherit src version;
hash = lib.fakeHash;
};
}
```
The first build will complain about the hash value, you can replace with the suggested value after that.

14
doc/languages-frameworks/bower.section.md
View File

@@ -28,7 +28,7 @@ buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
(fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
(fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
(fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
];
]; }
```
Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.
@@ -42,11 +42,13 @@ The function is implemented in [pkgs/development/bower-modules/generic/default.n
### Example buildBowerComponents {#ex-buildBowerComponents}
```nix
bowerComponents = buildBowerComponents {
name = "my-web-app";
generated = ./bower-packages.nix; # note 1
src = myWebApp; # note 2
};
{
bowerComponents = buildBowerComponents {
name = "my-web-app";
generated = ./bower-packages.nix; # note 1
src = myWebApp; # note 2
};
}
```
In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:

6
doc/languages-frameworks/chicken.section.md
View File

@@ -13,10 +13,12 @@ done in the typical Nix fashion. For example, to include support for [SRFI
might write:
```nix
{
buildInputs = [
chicken
chickenPackages.chickenEggs.srfi-189
];
}
```
Both `chicken` and its eggs have a setup hook which configures the environment
@@ -67,12 +69,12 @@ let
chickenEggs = super.chickenEggs.overrideScope' (eggself: eggsuper: {
srfi-180 = eggsuper.srfi-180.overrideAttrs {
# path to a local copy of srfi-180
src = ...
src = <...>;
};
});
});
in
# Here, `myChickenPackages.chickenEggs.json-rpc`, which depends on `srfi-180` will use
# the local copy of `srfi-180`.
# ...
<...>
```

6
doc/languages-frameworks/crystal.section.md
View File

@@ -33,22 +33,26 @@ crystal.buildCrystalPackage rec {
# Insert the path to your shards.nix file here
shardsFile = ./shards.nix;
...
# ...
}
```
This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
```nix
{
crystalBinaries.mint.src = "src/mint.cr";
# ...
}
```
Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
```nix
{
crystalBinaries.mint.options = [ "--release" "--verbose" ];
}
```
Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:

18
doc/languages-frameworks/cuda.section.md
View File

@@ -16,24 +16,28 @@ To use one or more CUDA packages in an expression, give the expression a `cudaPa
, cudaSupport ? config.cudaSupport
, cudaPackages ? { }
, ...
}:
}: {}
```
When using `callPackage`, you can choose to pass in a different variant, e.g.
when a different version of the toolkit suffices
```nix
mypkg = callPackage { cudaPackages = cudaPackages_11_5; }
{
mypkg = callPackage { cudaPackages = cudaPackages_11_5; };
}
```
If another version of say `cudnn` or `cutensor` is needed, you can override the
package set to make it the default. This guarantees you get a consistent package
set.
```nix
mypkg = let
cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
cudnn = prev.cudnn_8_3;
}});
in callPackage { inherit cudaPackages; };
{
mypkg = let
cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
cudnn = prev.cudnn_8_3;
});
in callPackage { inherit cudaPackages; };
}
```
The CUDA NVCC compiler requires flags to determine which hardware you

4
doc/languages-frameworks/cuelang.section.md
View File

@@ -26,7 +26,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
Here is an example:
```
```nix
pkgs.writeCueValidator
(pkgs.writeText "schema.cue" ''
#Def1: {
@@ -42,7 +42,7 @@ pkgs.writeCueValidator
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
Another example, given the following `validator.nix` :
```
```nix
{ pkgs ? import <nixpkgs> {} }:
let
genericValidator = version:

10
doc/languages-frameworks/dhall.section.md
View File

@@ -187,6 +187,7 @@ wish to specify `source = true` for all Dhall packages, then you can amend the
Dhall overlay like this:
```nix
{
dhallOverrides = self: super: {
# Enable source for all Dhall packages
buildDhallPackage =
@@ -194,6 +195,7 @@ Dhall overlay like this:
true = self.callPackage ./true.nix { };
};
}
```
… and now the Prelude will contain the fully decoded result of interpreting
@@ -429,22 +431,26 @@ $ dhall-to-nixpkgs github https://github.com/dhall-lang/dhall-lang.git \
the Prelude globally for all packages, like this:
```nix
{
dhallOverrides = self: super: {
true = self.callPackage ./true.nix { };
Prelude = self.callPackage ./Prelude.nix { };
};
}
```
… or selectively overriding the Prelude dependency for just the `true` package,
like this:
```nix
{
dhallOverrides = self: super: {
true = self.callPackage ./true.nix {
Prelude = self.callPackage ./Prelude.nix { };
};
};
}
```
## Overrides {#ssec-dhall-overrides}
@@ -454,11 +460,13 @@ You can override any of the arguments to `buildDhallGitHubPackage` or
For example, suppose we wanted to selectively enable `source = true` just for the Prelude. We can do that like this:
```nix
{
dhallOverrides = self: super: {
Prelude = super.Prelude.overridePackage { source = true; };
…
# ...
};
}
```
[semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages

4
doc/languages-frameworks/dotnet.section.md
View File

@@ -134,7 +134,7 @@ Here is an example `default.nix`, using some of the previously discussed argumen
{ lib, buildDotnetModule, dotnetCorePackages, ffmpeg }:
let
referencedProject = import ../../bar { ... };
referencedProject = import ../../bar { /* ... */ };
in buildDotnetModule rec {
pname = "someDotnetApplication";
version = "0.1";
@@ -236,7 +236,7 @@ the packages inside the `out` directory.
$ nuget-to-nix out > deps.nix
```
Which `nuget-to-nix` will generate an output similar to below
```
```nix
{ fetchNuGet }: [
(fetchNuGet { pname = "FosterFramework"; version = "0.1.15-alpha"; sha256 = "0pzsdfbsfx28xfqljcwy100xhbs6wyx0z1d5qxgmv3l60di9xkll"; })
(fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1gjz379y61ag9whi78qxx09bwkwcznkx2mzypgycibxk61g11da1"; })

48
doc/languages-frameworks/gnome.section.md
View File

@@ -47,6 +47,7 @@ When an application uses icons, an icon theme should be available in `XDG_DATA_D
In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
```nix
{
buildInputs = [
pantheon.elementary-icon-theme
];
@@ -56,6 +57,7 @@ In the rare case you need to use icons from dependencies (e.g. when an app force
--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
)
'';
}
```
To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
@@ -85,17 +87,19 @@ If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Gri
Given the requirements above, the package expression would become messy quickly:
```nix
preFixup = ''
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
wrapProgram "$f" \
--prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
--prefix XDG_DATA_DIRS : "$out/share" \
--prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
--prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
--prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
done
'';
{
preFixup = ''
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
wrapProgram "$f" \
--prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
--prefix XDG_DATA_DIRS : "$out/share" \
--prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
--prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
--prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
done
'';
}
```
Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
@@ -121,14 +125,16 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
```nix
preFixup = ''
gappsWrapperArgs+=(
# Thumbnailers
--prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
--prefix XDG_DATA_DIRS : "${librsvg}/share"
--prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
)
'';
{
preFixup = ''
gappsWrapperArgs+=(
# Thumbnailers
--prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
--prefix XDG_DATA_DIRS : "${librsvg}/share"
--prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
)
'';
}
```
## Updating GNOME packages {#ssec-gnome-updating}
@@ -159,7 +165,7 @@ python3.pkgs.buildPythonApplication {
nativeBuildInputs = [
wrapGAppsHook
gobject-introspection
...
# ...
];
dontWrapGApps = true;
@@ -181,7 +187,7 @@ mkDerivation {
nativeBuildInputs = [
wrapGAppsHook
qmake
...
# ...
];
dontWrapGApps = true;

78
doc/languages-frameworks/go.section.md
View File

@@ -38,24 +38,26 @@ The `buildGoModule` function accepts the following parameters in addition to the
The following is an example expression using `buildGoModule`:
```nix
pet = buildGoModule rec {
pname = "pet";
version = "0.3.4";
{
pet = buildGoModule rec {
pname = "pet";
version = "0.3.4";
src = fetchFromGitHub {
owner = "knqyf263";
repo = "pet";
rev = "v${version}";
hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
};
src = fetchFromGitHub {
owner = "knqyf263";
repo = "pet";
rev = "v${version}";
hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
};
vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
meta = {
description = "Simple command-line snippet manager, written in Go";
homepage = "https://github.com/knqyf263/pet";
license = lib.licenses.mit;
maintainers = with lib.maintainers; [ kalbasit ];
meta = {
description = "Simple command-line snippet manager, written in Go";
homepage = "https://github.com/knqyf263/pet";
license = lib.licenses.mit;
maintainers = with lib.maintainers; [ kalbasit ];
};
};
}
```
@@ -72,20 +74,22 @@ In the following is an example expression using `buildGoPackage`, the following
- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
```nix
deis = buildGoPackage rec {
pname = "deis";
version = "1.13.0";
{
deis = buildGoPackage rec {
pname = "deis";
version = "1.13.0";
goPackagePath = "github.com/deis/deis";
goPackagePath = "github.com/deis/deis";
src = fetchFromGitHub {
owner = "deis";
repo = "deis";
rev = "v${version}";
hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
src = fetchFromGitHub {
owner = "deis";
repo = "deis";
rev = "v${version}";
hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
};
goDeps = ./deps.nix;
};
goDeps = ./deps.nix;
}
```
@@ -153,10 +157,12 @@ A string list of flags to pass to the Go linker tool via the `-ldflags` argument
The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:
```nix
{
ldflags = [
"-X main.Version=${version}"
"-X main.Commit=${version}"
];
}
```
### `tags` {#var-go-tags}
@@ -164,16 +170,20 @@ The most common use case for this argument is to make the resulting executable a
A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`. These constraints control whether Go files from the source should be included in the build. For example:
```nix
{
tags = [
"production"
"sqlite"
];
}
```
Tags can also be set conditionally:
```nix
{
tags = [ "production" ] ++ lib.optionals withSqlite [ "sqlite" ];
}
```
### `deleteVendor` {#var-go-deleteVendor}
@@ -188,10 +198,12 @@ Many Go projects keep the main package in a `cmd` directory.
Following example could be used to only build the example-cli and example-server binaries:
```nix
subPackages = [
"cmd/example-cli"
"cmd/example-server"
];
{
subPackages = [
"cmd/example-cli"
"cmd/example-server"
];
}
```
### `excludedPackages` {#var-go-excludedPackages}
@@ -213,10 +225,12 @@ on a per package level using build tags (`tags`). In case CGO is disabled, these
When a Go program depends on C libraries, place those dependencies in `buildInputs`:
```nix
{
buildInputs = [
libvirt
libxml2
];
}
```
`CGO_ENABLED` defaults to `1`.
@@ -245,15 +259,18 @@ This is done with the [`-skip` or `-run`](https://pkg.go.dev/cmd/go#hdr-Testing_
For example, only a selection of tests could be run with:
```nix
{
# -run and -skip accept regular expressions
checkFlags = [
"-run=^Test(Simple|Fast)$"
];
}
```
If a larger amount of tests should be skipped, the following pattern can be used:
```nix
{
checkFlags =
let
# Skip tests that require network access
@@ -264,6 +281,7 @@ If a larger amount of tests should be skipped, the following pattern can be used
];
in
[ "-skip=^${builtins.concatStringsSep "$|^" skippedTests}$" ];
}
```
To disable tests altogether, set `doCheck = false;`.

4
doc/languages-frameworks/idris.section.md
View File

@@ -134,9 +134,9 @@ For example you could set
```nix
build-idris-package {
idrisBuildOptions = [ "--log" "1" "--verbose" ]
idrisBuildOptions = [ "--log" "1" "--verbose" ];
...
# ...
}
```

36
doc/languages-frameworks/java.section.md
View File

@@ -7,7 +7,7 @@ stdenv.mkDerivation {
pname = "...";
version = "...";
src = fetchurl { ... };
src = fetchurl { /* ... */ };
nativeBuildInputs = [
ant
@@ -48,8 +48,10 @@ installs a JAR named `foo.jar` in its `share/java` directory, and
another package declares the attribute
```nix
buildInputs = [ libfoo ];
nativeBuildInputs = [ jdk ];
{
buildInputs = [ libfoo ];
nativeBuildInputs = [ jdk ];
}
```
then `CLASSPATH` will be set to
@@ -62,13 +64,15 @@ If your Java package provides a program, you need to generate a wrapper
script to run it using a JRE. You can use `makeWrapper` for this:
```nix
nativeBuildInputs = [ makeWrapper ];
{
nativeBuildInputs = [ makeWrapper ];
installPhase = ''
mkdir -p $out/bin
makeWrapper ${jre}/bin/java $out/bin/foo \
--add-flags "-cp $out/share/java/foo.jar org.foo.Main"
'';
installPhase = ''
mkdir -p $out/bin
makeWrapper ${jre}/bin/java $out/bin/foo \
--add-flags "-cp $out/share/java/foo.jar org.foo.Main"
'';
}
```
Since the introduction of the Java Platform Module System in Java 9,
@@ -92,16 +96,18 @@ let
something = (pkgs.something.override { jre = my_jre; });
other = (pkgs.other.override { jre = my_jre; });
in
...
<...>
```
You can also specify what JDK your JRE should be based on, for example
selecting a 'headless' build to avoid including a link to GTK+:
```nix
my_jre = pkgs.jre_minimal.override {
jdk = jdk11_headless;
};
{
my_jre = pkgs.jre_minimal.override {
jdk = jdk11_headless;
};
}
```
Note all JDKs passthru `home`, so if your application requires
@@ -116,7 +122,9 @@ It is possible to use a different Java compiler than `javac` from the
OpenJDK. For instance, to use the GNU Java Compiler:
```nix
nativeBuildInputs = [ gcj ant ];
{
nativeBuildInputs = [ gcj ant ];
}
```
Here, Ant will automatically use `gij` (the GNU Java Runtime) instead of

115
doc/languages-frameworks/javascript.section.md
View File

@@ -4,11 +4,14 @@
This contains instructions on how to package javascript applications.
The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
The various tools available will be listed in the [tools-overview](#javascript-tools-overview).
Some general principles for packaging will follow.
Finally some tool specific instructions will be given.
## Getting unstuck / finding code examples {#javascript-finding-examples}
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
If you find you are lacking inspiration for packaging javascript applications, the links below might prove useful.
Searching online for prior art can be helpful if you are running into solved problems.
### Github {#javascript-finding-examples-github}
@@ -30,17 +33,23 @@ The following principles are given in order of importance with potential excepti
It is often not documented which node version is used upstream, but if it is, try to use the same version when packaging.
This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node. Some cryptic errors regarding V8 may appear.
This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node.
Some cryptic errors regarding V8 may appear.
### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of node_modules for each tool.
A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of `node_modules` for each tool.
Guidelines of package managers, recommend to commit those lock files to the repos. If a particular lock file is present, it is a strong indication of which package manager is used upstream.
Guidelines of package managers, recommend to commit those lock files to the repos.
If a particular lock file is present, it is a strong indication of which package manager is used upstream.
It's better to try to use a Nix tool that understand the lock file. Using a different tool might give you hard to understand error because different packages have been installed. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream use NPM, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
It's better to try to use a Nix tool that understand the lock file.
Using a different tool might give you hard to understand error because different packages have been installed.
An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).
Upstream use NPM, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
Using a different tool forces to commit a lock file to the repository. Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
Using a different tool forces to commit a lock file to the repository.
Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
Exceptions to this rule are:
@@ -67,28 +76,36 @@ Exceptions to this rule are:
when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
```nix
patchedPackageJSON = final.runCommand "package.json" { } ''
${jq}/bin/jq '.version = "0.4.0" |
.devDependencies."@jsdoc/cli" = "^0.2.5"
${sonar-src}/package.json > $out
'';
{
patchedPackageJSON = final.runCommand "package.json" { } ''
${jq}/bin/jq '.version = "0.4.0" |
.devDependencies."@jsdoc/cli" = "^0.2.5"
${sonar-src}/package.json > $out
'';
}
```
You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
### Using node_modules directly {#javascript-using-node_modules}
Each tool has an abstraction to just build the node_modules (dependencies) directory. You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command). The node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory.
Each tool has an abstraction to just build the node_modules (dependencies) directory.
You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command).
The node_modules abstraction can be also used to build some web framework frontends.
For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules.
Then when building the frontend you can just symlink the node_modules directory.
## Javascript packages inside nixpkgs {#javascript-packages-nixpkgs}
The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [NPM packages](https://npmjs.com/) that can be installed with the Nix package manager.
As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities. Libraries should only be added to the package set if there is a non-NPM package that requires it.
As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities.
Libraries should only be added to the package set if there is a non-NPM package that requires it.
When it is desired to use NPM libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
The package set provides support for the official stable Node.js versions. The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
The package set provides support for the official stable Node.js versions.
The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
If your package uses native addons, you need to examine what kind of native build system it uses. Here are some examples:
@@ -96,13 +113,16 @@ If your package uses native addons, you need to examine what kind of native buil
- `node-gyp-builder`
- `node-pre-gyp`
After you have identified the correct system, you need to override your package expression while adding in build system as a build input. For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
After you have identified the correct system, you need to override your package expression while adding in build system as a build input.
For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
```nix
{
dat = prev.dat.override (oldAttrs: {
buildInputs = [ final.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
meta = oldAttrs.meta // { broken = since "12"; };
});
}
```
### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
@@ -159,7 +179,8 @@ git config --global url."https://github.com/".insteadOf git://github.com/
### buildNpmPackage {#javascript-buildNpmPackage}
`buildNpmPackage` allows you to package npm-based projects in Nixpkgs without the use of an auto-generated dependencies file (as used in [node2nix](#javascript-node2nix)). It works by utilizing npm's cache functionality -- creating a reproducible cache that contains the dependencies of a project, and pointing npm to it.
`buildNpmPackage` allows you to package npm-based projects in Nixpkgs without the use of an auto-generated dependencies file (as used in [node2nix](#javascript-node2nix)).
It works by utilizing npm's cache functionality -- creating a reproducible cache that contains the dependencies of a project, and pointing npm to it.
Here's an example:
@@ -193,7 +214,9 @@ buildNpmPackage rec {
}
```
In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install in `$out/lib/node_modules/$name/`, where `$name` is the `name` string defined in the package's `package.json`. Additionally, the `bin` and `man` keys in the source's `package.json` are used to decide what binaries and manpages are supposed to be installed. If these are not defined, `npm pack` may miss some files, and no binaries will be produced.
In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install in `$out/lib/node_modules/$name/`, where `$name` is the `name` string defined in the package's `package.json`.
Additionally, the `bin` and `man` keys in the source's `package.json` are used to decide what binaries and manpages are supposed to be installed.
If these are not defined, `npm pack` may miss some files, and no binaries will be produced.
#### Arguments {#javascript-buildNpmPackage-arguments}
@@ -296,10 +319,12 @@ You will need at least a `yarn.lock` file. If upstream does not have one you nee
If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:
```nix
offlineCache = fetchYarnDeps {
yarnLock = src + "/yarn.lock";
hash = "....";
};
{
offlineCache = fetchYarnDeps {
yarnLock = src + "/yarn.lock";
hash = "....";
};
}
```
#### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
@@ -309,33 +334,41 @@ offlineCache = fetchYarnDeps {
It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
```nix
buildPhase = ''
export HOME=$(mktemp -d)
yarn --offline build
'';
{
buildPhase = ''
export HOME=$(mktemp -d)
yarn --offline build
'';
}
```
The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:
```nix
doDist = false;
{
doDist = false;
}
```
The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
```nix
configurePhase = ''
ln -s $node_modules node_modules
'';
{
configurePhase = ''
ln -s $node_modules node_modules
'';
}
```
or if you need a writeable node_modules directory:
```nix
configurePhase = ''
cp -r $node_modules node_modules
chmod +w node_modules
'';
{
configurePhase = ''
cp -r $node_modules node_modules
chmod +w node_modules
'';
}
```
#### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
@@ -375,12 +408,14 @@ mkYarnPackage rec {
- Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:
```nix
yarnPreBuild = ''
mkdir -p $HOME/.node-gyp/${nodejs.version}
echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
export npm_config_nodedir=${nodejs}
'';
{
yarnPreBuild = ''
mkdir -p $HOME/.node-gyp/${nodejs.version}
echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
export npm_config_nodedir=${nodejs}
'';
}
```
- The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>

20
doc/languages-frameworks/lisp.section.md
View File

@@ -45,7 +45,7 @@ $ sbcl
Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
```
```nix
let
sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
in mkShell {
@@ -55,10 +55,12 @@ in mkShell {
Such a Lisp can be now used e.g. to compile your sources:
```
buildPhase = ''
${sbcl'}/bin/sbcl --load my-build-file.lisp
''
```nix
{
buildPhase = ''
${sbcl'}/bin/sbcl --load my-build-file.lisp
'';
}
```
## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
@@ -173,7 +175,7 @@ into the package scope with `withOverrides`.
A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
Nixpkgs-provided scope like this:
```
```nix
let
alexandria = sbcl.buildASDFSystem rec {
pname = "alexandria";
@@ -199,7 +201,7 @@ new package with different parameters.
Example of overriding `alexandria`:
```
```nix
sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
version = "1.4";
src = fetchFromGitLab {
@@ -225,7 +227,7 @@ vice versa.
To package slashy systems, use `overrideLispAttrs`, like so:
```
```nix
ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
systems = oldAttrs.systems ++ [ "alexandria/tests" ];
lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
@@ -290,7 +292,7 @@ derivation.
This example wraps CLISP:
```
```nix
wrapLisp {
pkg = clisp;
faslExt = "fas";

37
doc/languages-frameworks/lua.section.md
View File

@@ -87,6 +87,7 @@ final: prev:
pname = "luarocks-nix";
src = /home/my_luarocks/repository;
});
};
};
luaPackages = lua.pkgs;
@@ -154,7 +155,9 @@ You can develop your package as you usually would, just don't forget to wrap it
within a `toLuaModule` call, for instance
```nix
mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
{
mynewlib = toLuaModule ( stdenv.mkDerivation { /* ... */ });
}
```
There is also the `buildLuaPackage` function that can be used when lua modules
@@ -182,24 +185,26 @@ Each interpreter has the following attributes:
The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
The following is an example:
```nix
luaposix = buildLuarocksPackage {
pname = "luaposix";
version = "34.0.4-1";
{
luaposix = buildLuarocksPackage {
pname = "luaposix";
version = "34.0.4-1";
src = fetchurl {
url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
};
disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
propagatedBuildInputs = [ bit32 lua std_normalize ];
src = fetchurl {
url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
};
disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
propagatedBuildInputs = [ bit32 lua std_normalize ];
meta = {
homepage = "https://github.com/luaposix/luaposix/";
description = "Lua bindings for POSIX";
maintainers = with lib.maintainers; [ vyp lblasc ];
license.fullName = "MIT/X11";
meta = {
homepage = "https://github.com/luaposix/luaposix/";
description = "Lua bindings for POSIX";
maintainers = with lib.maintainers; [ vyp lblasc ];
license.fullName = "MIT/X11";
};
};
};
}
```
The `buildLuarocksPackage` delegates most tasks to luarocks:

2
doc/languages-frameworks/maven.section.md
View File

@@ -40,7 +40,7 @@ maven.buildMavenPackage rec {
license = lib.licenses.gpl3Plus;
maintainers = with lib.maintainers; [ majiir ];
};
}:
}
```
This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.

1
doc/languages-frameworks/ocaml.section.md
View File

@@ -92,6 +92,7 @@ buildDunePackage rec {
license = lib.licenses.bsd3;
maintainers = with lib.maintainers; [ sternenseemann ];
};
}
```
Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.

74
doc/languages-frameworks/perl.section.md
View File

@@ -34,23 +34,27 @@ Nixpkgs provides a function `buildPerlPackage`, a generic package builder functi
Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
```nix
ClassC3 = buildPerlPackage rec {
pname = "Class-C3";
version = "0.21";
src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
{
ClassC3 = buildPerlPackage rec {
pname = "Class-C3";
version = "0.21";
src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
};
};
};
}
```
Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
```nix
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...;
inherit (perlPackages) ClassC3;
};
{
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl /* ... */;
inherit (perlPackages) ClassC3;
};
}
```
in `all-packages.nix`. You can test building a Perl package as follows:
@@ -91,17 +95,19 @@ buildPerlPackage rec {
Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
```nix
ClassC3Componentised = buildPerlPackage rec {
pname = "Class-C3-Componentised";
version = "1.0004";
src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
{
ClassC3Componentised = buildPerlPackage rec {
pname = "Class-C3-Componentised";
version = "1.0004";
src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
};
propagatedBuildInputs = [
ClassC3 ClassInspector TestException MROCompat
];
};
propagatedBuildInputs = [
ClassC3 ClassInspector TestException MROCompat
];
};
}
```
On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
@@ -109,20 +115,22 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
```nix
{ lib, stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
ImageExifTool = buildPerlPackage {
pname = "Image-ExifTool";
version = "12.50";
{
ImageExifTool = buildPerlPackage {
pname = "Image-ExifTool";
version = "12.50";
src = fetchurl {
url = "https://exiftool.org/${pname}-${version}.tar.gz";
hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
src = fetchurl {
url = "https://exiftool.org/${pname}-${version}.tar.gz";
hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
};
nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = lib.optionalString stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';
};
nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = lib.optionalString stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';
};
}
```
This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.

6
doc/languages-frameworks/php.section.md
View File

@@ -97,7 +97,7 @@ let
myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
in {
services.phpfpm.pools."foo".phpPackage = myPhp;
};
}
```
```nix
@@ -108,7 +108,7 @@ let
};
in {
services.phpfpm.pools."foo".phpPackage = myPhp;
};
}
```
#### Example usage with `nix-shell` {#ssec-php-user-guide-installing-with-extensions-nix-shell}
@@ -149,7 +149,7 @@ php.override {
extensions = prev.extensions // {
mysqlnd = prev.extensions.mysqlnd.overrideAttrs (attrs: {
patches = attrs.patches or [] ++ [
…
# ...
];
});
};

6
doc/languages-frameworks/pkg-config.section.md
View File

@@ -12,18 +12,18 @@ Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixp
A good example of all these things is zlib:
```
```nix
{ pkg-config, testers, ... }:
stdenv.mkDerivation (finalAttrs: {
...
/* ... */
nativeBuildInputs = [ pkg-config validatePkgConfig ];
passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
meta = {
...
/* ... */
pkgConfigModules = [ "zlib" ];
};
})

116
doc/languages-frameworks/python.section.md
View File

@@ -254,17 +254,19 @@ The next example shows a non trivial overriding of the `blas` implementation to
be used through out all of the Python package set:
```nix
python3MyBlas = pkgs.python3.override {
packageOverrides = self: super: {
# We need toPythonModule for the package set to evaluate this
blas = super.toPythonModule(super.pkgs.blas.override {
blasProvider = super.pkgs.mkl;
});
lapack = super.toPythonModule(super.pkgs.lapack.override {
lapackProvider = super.pkgs.mkl;
});
{
python3MyBlas = pkgs.python3.override {
packageOverrides = self: super: {
# We need toPythonModule for the package set to evaluate this
blas = super.toPythonModule(super.pkgs.blas.override {
blasProvider = super.pkgs.mkl;
});
lapack = super.toPythonModule(super.pkgs.lapack.override {
lapackProvider = super.pkgs.mkl;
});
};
};
};
}
```
This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.
@@ -322,7 +324,9 @@ python3Packages.buildPythonApplication rec {
This is then added to `all-packages.nix` just as any other application would be.
```nix
luigi = callPackage ../applications/networking/cluster/luigi { };
{
luigi = callPackage ../applications/networking/cluster/luigi { };
}
```
Since the package is an application, a consumer doesn't need to care about
@@ -342,7 +346,9 @@ the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
applied to the reference:
```nix
youtube-dl = with python3Packages; toPythonApplication youtube-dl;
{
youtube-dl = with python3Packages; toPythonApplication youtube-dl;
}
```
#### `toPythonModule` function {#topythonmodule-function}
@@ -354,10 +360,12 @@ bindings should be made available from `python-packages.nix`. The
modifications.
```nix
opencv = toPythonModule (pkgs.opencv.override {
enablePython = true;
pythonPackages = self;
});
{
opencv = toPythonModule (pkgs.opencv.override {
enablePython = true;
pythonPackages = self;
});
}
```
Do pay attention to passing in the right Python version!
@@ -1197,7 +1205,8 @@ a good indication that the package is not in a valid state.
Pytest is the most common test runner for python repositories. A trivial
test run would be:
```
```nix
{
nativeCheckInputs = [ pytest ];
checkPhase = ''
runHook preCheck
@@ -1206,6 +1215,7 @@ test run would be:
runHook postCheck
'';
}
```
However, many repositories' test suites do not translate well to nix's build
@@ -1213,7 +1223,8 @@ sandbox, and will generally need many tests to be disabled.
To filter tests using pytest, one can do the following:
```
```nix
{
nativeCheckInputs = [ pytest ];
# avoid tests which need additional data or touch network
checkPhase = ''
@@ -1223,6 +1234,7 @@ To filter tests using pytest, one can do the following:
runHook postCheck
'';
}
```
`--ignore` will tell pytest to ignore that file or directory from being
@@ -1248,7 +1260,8 @@ when a package may need many items disabled to run the test suite.
Using the example above, the analogous `pytestCheckHook` usage would be:
```
```nix
{
nativeCheckInputs = [
pytestCheckHook
];
@@ -1268,12 +1281,14 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
disabledTestPaths = [
"tests/test_failing.py"
];
}
```
This is especially useful when tests need to be conditionally disabled,
for example:
```
```nix
{
disabledTests = [
# touches network
"download"
@@ -1285,6 +1300,7 @@ for example:
# can fail when building with other packages
"socket"
];
}
```
Trying to concatenate the related strings to disable tests in a regular
@@ -1298,20 +1314,24 @@ all packages have test suites that can be run easily, and some have none at all.
To help ensure the package still works, [`pythonImportsCheck`](#using-pythonimportscheck) can attempt to import
the listed modules.
```
```nix
{
pythonImportsCheck = [
"requests"
"urllib"
];
}
```
roughly translates to:
```
```nix
{
postCheck = ''
PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
python -c "import requests; import urllib"
'';
}
```
However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).
@@ -1342,7 +1362,8 @@ pkg3>=1.0,<=2.0
we can do:
```
```nix
{
nativeBuildInputs = [
pythonRelaxDepsHook
];
@@ -1353,6 +1374,7 @@ we can do:
pythonRemoveDeps = [
"pkg2"
];
}
```
which would result in the following `requirements.txt` file:
@@ -1365,9 +1387,11 @@ pkg3
Another option is to pass `true`, that will relax/remove all dependencies, for
example:
```
```nix
{
nativeBuildInputs = [ pythonRelaxDepsHook ];
pythonRelaxDeps = true;
}
```
which would result in the following `requirements.txt` file:
@@ -1392,7 +1416,8 @@ work with any of the [existing hooks](#setup-hooks).
`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
```
```nix
{
nativeCheckInputs = [
unittestCheckHook
];
@@ -1400,6 +1425,7 @@ work with any of the [existing hooks](#setup-hooks).
unittestFlagsArray = [
"-s" "tests" "-v"
];
}
```
#### Using sphinxHook {#using-sphinxhook}
@@ -1409,7 +1435,8 @@ using the popular Sphinx documentation generator.
It is setup to automatically find common documentation source paths and
render them using the default `html` style.
```
```nix
{
outputs = [
"out"
"doc"
@@ -1418,13 +1445,15 @@ render them using the default `html` style.
nativeBuildInputs = [
sphinxHook
];
}
```
The hook will automatically build and install the artifact into the
`doc` output, if it exists. It also provides an automatic diversion
for the artifacts of the `man` builder into the `man` target.
```
```nix
{
outputs = [
"out"
"doc"
@@ -1436,14 +1465,17 @@ for the artifacts of the `man` builder into the `man` target.
"singlehtml"
"man"
];
}
```
Overwrite `sphinxRoot` when the hook is unable to find your
documentation source root.
```
```nix
{
# Configure sphinxRoot for uncommon paths
sphinxRoot = "weird/docs/path";
}
```
The hook is also available to packages outside the python ecosystem by
@@ -1827,6 +1859,7 @@ folder and not downloaded again.
If you need to change a package's attribute(s) from `configuration.nix` you could do:
```nix
{
nixpkgs.config.packageOverrides = super: {
python3 = super.python3.override {
packageOverrides = python-self: python-super: {
@@ -1841,6 +1874,7 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
};
};
};
}
```
`python3Packages.twisted` is now globally overridden.
@@ -1853,11 +1887,13 @@ To modify only a Python package set instead of a whole Python derivation, use
this snippet:
```nix
{
myPythonPackages = python3Packages.override {
overrides = self: super: {
twisted = ...;
twisted = <...>;
};
}
};
}
```
### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
@@ -1893,7 +1929,7 @@ final: prev: {
(
python-final: python-prev: {
foo = python-prev.foo.overridePythonAttrs (oldAttrs: {
...
# ...
});
}
)
@@ -1920,7 +1956,7 @@ The Python interpreters are by default not built with optimizations enabled, bec
the builds are in that case not reproducible. To enable optimizations, override the
interpreter of interest, e.g using
```
```nix
let
pkgs = import ./. {};
mypython = pkgs.python3.override {
@@ -1938,17 +1974,21 @@ Some packages define optional dependencies for additional features. With
`extras-require`, while PEP 621 calls these `optional-dependencies`.
```nix
optional-dependencies = {
complete = [ distributed ];
};
{
optional-dependencies = {
complete = [ distributed ];
};
}
```
and letting the package requiring the extra add the list to its dependencies
```nix
dependencies = [
...
] ++ dask.optional-dependencies.complete;
{
dependencies = [
# ...
] ++ dask.optional-dependencies.complete;
}
```
This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.

2
doc/languages-frameworks/ruby.section.md
View File

@@ -124,11 +124,13 @@ mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
```nix
{
gems = bundlerEnv {
name = "gems-for-some-project";
gemdir = ./.;
extraConfigPaths = [ "${./.}/.ruby-version" ];
};
}
```
### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}

130
doc/languages-frameworks/rust.section.md
View File

@@ -3,10 +3,12 @@
To install the rust compiler and cargo put
```nix
environment.systemPackages = [
rustc
cargo
];
{
environment.systemPackages = [
rustc
cargo
];
}
```
into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
@@ -51,7 +53,9 @@ preferred over `cargoSha256` which was used for traditional Nix SHA-256 hashes.
For example:
```nix
{
cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
}
```
Exception: If the application has cargo `git` dependencies, the `cargoHash`/`cargoSha256`
@@ -67,13 +71,17 @@ then be taken from the failed build. A fake hash can be used for
`cargoHash` as follows:
```nix
{
cargoHash = lib.fakeHash;
}
```
For `cargoSha256` you can use:
```nix
{
cargoSha256 = lib.fakeSha256;
}
```
Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)
@@ -162,9 +170,11 @@ doesn't add a `Cargo.lock` to your `src`, and a `Cargo.lock` is still
required to build a rust package. A simple fix is to use:
```nix
postPatch = ''
ln -s ${./Cargo.lock} Cargo.lock
'';
{
postPatch = ''
ln -s ${./Cargo.lock} Cargo.lock
'';
}
```
The output hash of each dependency that uses a git source must be
@@ -409,7 +419,7 @@ the `cargoPatches` attribute to update or add it.
```nix
rustPlatform.buildRustPackage rec {
(...)
# ...
cargoPatches = [
# a patch file to add/update Cargo.lock in the source code
./add-Cargo.lock.patch
@@ -433,10 +443,12 @@ containing `Cargo.toml` and `Cargo.lock`, `fetchCargoTarball`
can be used as follows:
```nix
cargoDeps = rustPlatform.fetchCargoTarball {
inherit src;
hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
};
{
cargoDeps = rustPlatform.fetchCargoTarball {
inherit src;
hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
};
}
```
The `src` attribute is required, as well as a hash specified through
@@ -458,23 +470,27 @@ function does not require a hash (unless git dependencies are used)
and fetches every dependency as a separate fixed-output derivation.
`importCargoLock` can be used as follows:
```
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
};
```nix
{
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
};
}
```
If the `Cargo.lock` file includes git dependencies, then their output
hashes need to be specified since they are not available through the
lock file. For example:
```
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
outputHashes = {
"rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
```nix
{
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
outputHashes = {
"rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
};
};
};
}
```
If you do not specify an output hash for a git dependency, building
@@ -651,6 +667,66 @@ buildPythonPackage rec {
}
```
#### Rust package built with `meson` {#rust-package-built-with-meson}
Some projects, especially GNOME applications, are built with the Meson Build System instead of calling Cargo directly. Using `rustPlatform.buildRustPackage` may successfully build the main program, but related files will be missing. Instead, you need to set up Cargo dependencies with `fetchCargoTarball` and `cargoSetupHook` and leave the rest to Meson. `rust` and `cargo` are still needed in `nativeBuildInputs` for Meson to use.
```nix
{ lib
, stdenv
, fetchFromGitLab
, meson
, ninja
, pkg-config
, rustPlatform
, rustc
, cargo
, wrapGAppsHook4
, blueprint-compiler
, libadwaita
, libsecret
, tracker
}:
stdenv.mkDerivation rec {
pname = "health";
version = "0.95.0";
src = fetchFromGitLab {
domain = "gitlab.gnome.org";
owner = "World";
repo = "health";
rev = version;
hash = "sha256-PrNPprSS98yN8b8yw2G6hzTSaoE65VbsM3q7FVB4mds=";
};
cargoDeps = rustPlatform.fetchCargoTarball {
inherit src;
name = "${pname}-${version}";
hash = "sha256-8fa3fa+sFi5H+49B5sr2vYPkp9C9s6CcE0zv4xB8gww=";
};
nativeBuildInputs = [
meson
ninja
pkg-config
rustPlatform.cargoSetupHook
rustc
cargo
wrapGAppsHook4
blueprint-compiler
];
buildInputs = [
libadwaita
libsecret
tracker
];
# ...
}
```
## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
### Simple operation {#simple-operation}
@@ -732,27 +808,27 @@ general. A number of other parameters can be overridden:
- The version of `rustc` used to compile the crate:
```nix
(hello {}).override { rust = pkgs.rust; };
(hello {}).override { rust = pkgs.rust; }
```
- Whether to build in release mode or debug mode (release mode by
default):
```nix
(hello {}).override { release = false; };
(hello {}).override { release = false; }
```
- Whether to print the commands sent to `rustc` when building
(equivalent to `--verbose` in cargo:
```nix
(hello {}).override { verbose = false; };
(hello {}).override { verbose = false; }
```
- Extra arguments to be passed to `rustc`:
```nix
(hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
(hello {}).override { extraRustcOpts = "-Z debuginfo=2"; }
```
- Phases, just like in any other derivation, can be specified using
@@ -768,7 +844,7 @@ general. A number of other parameters can be overridden:
preConfigure = ''
echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
'';
};
}
```
### Setting Up `nix-shell` {#setting-up-nix-shell}

28
doc/languages-frameworks/swift.section.md
View File

@@ -112,13 +112,17 @@ stdenv.mkDerivation rec {
If you'd like to build a different configuration than `release`:
```nix
swiftpmBuildConfig = "debug";
{
swiftpmBuildConfig = "debug";
}
```
It is also possible to provide additional flags to `swift build`:
```nix
swiftpmFlags = [ "--disable-dead-strip" ];
{
swiftpmFlags = [ "--disable-dead-strip" ];
}
```
The default `buildPhase` already passes `-j` for parallel building.
@@ -132,7 +136,9 @@ Including `swiftpm` in your `nativeBuildInputs` also provides a default
`checkPhase`, but it must be enabled with:
```nix
doCheck = true;
{
doCheck = true;
}
```
This essentially runs: `swift test -c release`
@@ -147,13 +153,15 @@ them, we need to make them writable.
A special function `swiftpmMakeMutable` is available to replace the symlink
with a writable copy:
```
configurePhase = generated.configure ++ ''
# Replace the dependency symlink with a writable copy.
swiftpmMakeMutable swift-crypto
# Now apply a patch.
patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
'';
```nix
{
configurePhase = generated.configure ++ ''
# Replace the dependency symlink with a writable copy.
swiftpmMakeMutable swift-crypto
# Now apply a patch.
patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
'';
}
```
## Considerations for custom build tools {#ssec-swift-considerations-for-custom-build-tools}

16
doc/languages-frameworks/vim.section.md
View File

@@ -219,9 +219,11 @@ After running the updater, if nvim-treesitter received an update, also run [`nvi
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
```nix
deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
dependencies = with super; [ deoplete-nvim vim-fish ];
});
{
deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
dependencies = with super; [ deoplete-nvim vim-fish ];
});
}
```
Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
@@ -264,8 +266,10 @@ pwntester/octo.nvim,,
You can then reference the generated vim plugins via:
```nix
myVimPlugins = pkgs.vimPlugins.extend (
(pkgs.callPackage ./generated.nix {})
);
{
myVimPlugins = pkgs.vimPlugins.extend (
(pkgs.callPackage ./generated.nix {})
);
}
```

7
doc/packages/darwin-builder.section.md
View File

@@ -81,7 +81,7 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
## Example flake usage {#sec-darwin-builder-example-flake}
```
```nix
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-22.11-darwin";
@@ -153,7 +153,8 @@ you may use it to build a modified remote builder with additional storage or mem
To do this, you just need to set the `virtualisation.darwin-builder.*` parameters as
in the example below and rebuild.
```
```nix
{
darwin-builder = nixpkgs.lib.nixosSystem {
system = linuxSystem;
modules = [
@@ -166,6 +167,8 @@ in the example below and rebuild.
virtualisation.darwin-builder.workingDirectory = "/var/lib/darwin-builder";
}
];
};
}
```
You may make any other changes to your VM in this attribute set. For example,

66
doc/packages/eclipse.section.md
View File

@@ -13,11 +13,13 @@ Once an Eclipse variant is installed, it can be run using the `eclipse` command,
If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
```nix
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
eclipse = eclipse-platform;
jvmArgs = [ "-Xmx2048m" ];
plugins = [ plugins.color-theme ];
{
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
eclipse = eclipse-platform;
jvmArgs = [ "-Xmx2048m" ];
plugins = [ plugins.color-theme ];
};
};
}
```
@@ -33,32 +35,34 @@ If there is a need to install plugins that are not available in Nixpkgs then it
Expanding the previous example with two plugins using the above functions, we have:
```nix
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
eclipse = eclipse-platform;
jvmArgs = [ "-Xmx2048m" ];
plugins = [
plugins.color-theme
(plugins.buildEclipsePlugin {
name = "myplugin1-1.0";
srcFeature = fetchurl {
url = "http://…/features/myplugin1.jar";
hash = "sha256-123…";
};
srcPlugin = fetchurl {
url = "http://…/plugins/myplugin1.jar";
hash = "sha256-123…";
};
});
(plugins.buildEclipseUpdateSite {
name = "myplugin2-1.0";
src = fetchurl {
stripRoot = false;
url = "http://…/myplugin2.zip";
hash = "sha256-123…";
};
});
];
{
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
eclipse = eclipse-platform;
jvmArgs = [ "-Xmx2048m" ];
plugins = [
plugins.color-theme
(plugins.buildEclipsePlugin {
name = "myplugin1-1.0";
srcFeature = fetchurl {
url = "http://…/features/myplugin1.jar";
hash = "sha256-123…";
};
srcPlugin = fetchurl {
url = "http://…/plugins/myplugin1.jar";
hash = "sha256-123…";
};
})
(plugins.buildEclipseUpdateSite {
name = "myplugin2-1.0";
src = fetchurl {
stripRoot = false;
url = "http://…/myplugin2.zip";
hash = "sha256-123…";
};
})
];
};
};
}
```

13
doc/packages/emacs.section.md
View File

@@ -16,7 +16,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
projectile
use-package
]));
}
};
}
```
@@ -102,10 +102,12 @@ This provides a fairly full Emacs start file. It will load in addition to the us
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to GNU-devel ELPA, and the highest for packages manually defined in `pkgs/applications/editors/emacs/elisp-packages/manual-packages`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope`.
```nix
overrides = self: super: rec {
haskell-mode = self.melpaPackages.haskell-mode;
...
};
let
overrides = self: super: rec {
haskell-mode = self.melpaPackages.haskell-mode;
# ...
};
in
((emacsPackagesFor emacs).overrideScope overrides).withPackages
(p: with p; [
# here both these package will use haskell-mode of our own choice
@@ -113,3 +115,4 @@ overrides = self: super: rec {
dante
])
```
}

2
doc/packages/steam.section.md
View File

@@ -51,7 +51,7 @@ Use `programs.steam.enable = true;` if you want to add steam to `systemPackages`
you need to add:
```nix
steam.override { withJava = true; };
steam.override { withJava = true; }
```
## steam-run {#sec-steam-run}

4
doc/packages/urxvt.section.md
View File

@@ -65,7 +65,9 @@ A plugin can be any kind of derivation, the only requirement is that it should a
If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
```nix
passthru.perlPackages = [ "self" ];
{
passthru.perlPackages = [ "self" ];
}
```
This will make the urxvt wrapper pick up the dependency and set up the Perl path accordingly.

6
doc/packages/weechat.section.md
View File

@@ -3,9 +3,9 @@
WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:
```nix
weechat.override {configure = {availablePlugins, ...}: {
weechat.override {configure = ({availablePlugins, ...}: {
plugins = with availablePlugins; [ python perl ];
}
});
}
```
@@ -59,7 +59,7 @@ weechat.override {
];
init = ''
/set plugins.var.python.jabber.key "val"
'':
'';
};
}
```

30
doc/stdenv/cross-compilation.chapter.md
View File

@@ -15,7 +15,9 @@ Nixpkgs follows the [conventions of GNU autoconf](https://gcc.gnu.org/onlinedocs
In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:
```nix
{ stdenv, fooDep, barDep, ... }: ...stdenv.buildPlatform...
{ stdenv, fooDep, barDep, ... }: {
# ...stdenv.buildPlatform...
}
```
`buildPlatform`
@@ -127,7 +129,9 @@ Some frequently encountered problems when packaging for cross-compilation should
Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.
```nix
makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
{
makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
}
```
#### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}
@@ -142,7 +146,9 @@ $ nix-build '<nixpkgs>' -A pkgsCross.raspberryPi.hello
Add the following to your `mkDerivation` invocation.
```nix
depsBuildBuild = [ buildPackages.stdenv.cc ];
{
depsBuildBuild = [ buildPackages.stdenv.cc ];
}
```
#### My package’s testsuite needs to run host platform code. {#cross-testsuite-runs-host-code}
@@ -150,7 +156,9 @@ depsBuildBuild = [ buildPackages.stdenv.cc ];
Add the following to your `mkDerivation` invocation.
```nix
doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
{
doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
}
```
#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}
@@ -159,12 +167,14 @@ Add `mesonEmulatorHook` to `nativeBuildInputs` conditionally on if the target bi
e.g.
```
nativeBuildInputs = [
meson
] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
mesonEmulatorHook
];
```nix
{
nativeBuildInputs = [
meson
] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
mesonEmulatorHook
];
}
```
Example of an error which this fixes.

50
doc/stdenv/meta.chapter.md
View File

@@ -3,17 +3,19 @@
Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:
```nix
meta = {
description = "A program that produces a familiar, friendly greeting";
longDescription = ''
GNU Hello is a program that prints "Hello, world!" when you run it.
It is fully customizable.
'';
homepage = "https://www.gnu.org/software/hello/manual/";
license = lib.licenses.gpl3Plus;
maintainers = with lib.maintainers; [ eelco ];
platforms = lib.platforms.all;
};
{
meta = {
description = "A program that produces a familiar, friendly greeting";
longDescription = ''
GNU Hello is a program that prints "Hello, world!" when you run it.
It is fully customizable.
'';
homepage = "https://www.gnu.org/software/hello/manual/";
license = lib.licenses.gpl3Plus;
maintainers = with lib.maintainers; [ eelco ];
platforms = lib.platforms.all;
};
}
```
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
@@ -82,7 +84,9 @@ The *priority* of the package, used by `nix-env` to resolve file name conflicts
The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
```nix
meta.platforms = lib.platforms.linux;
{
meta.platforms = lib.platforms.linux;
}
```
Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
@@ -95,8 +99,10 @@ In general it is preferable to set `meta.platforms = lib.platforms.all` and then
For example, a package which requires dynamic linking and cannot be linked statically could use this:
```nix
meta.platforms = lib.platforms.all;
meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
{
meta.platforms = lib.platforms.all;
meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
}
```
The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
@@ -136,7 +142,7 @@ For more on how to write and run package tests, see [](#sec-package-tests).
The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
```nix
{ /* ... */, nixosTests }:
{ /* ... , */ nixosTests }:
{
# ...
passthru.tests = {
@@ -194,8 +200,10 @@ To be effective, it must be presented directly to an evaluation process that han
The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
```nix
meta.platforms = lib.platforms.linux;
meta.hydraPlatforms = [];
{
meta.platforms = lib.platforms.linux;
meta.hydraPlatforms = [];
}
```
### `broken` {#var-meta-broken}
@@ -209,13 +217,17 @@ This means that `broken` can be used to express constraints, for example:
- Does not cross compile
```nix
meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform)
{
meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform);
}
```
- Broken if all of a certain set of its dependencies are broken
```nix
meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ])
{
meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ]);
}
```
This makes `broken` strictly more powerful than `meta.badPlatforms`.

4
doc/stdenv/multiple-output.chapter.md
View File

@@ -30,7 +30,9 @@ Here you find how to write a derivation that produces multiple outputs.
In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).
```nix
outputs = [ "bin" "dev" "out" "doc" ];
{
outputs = [ "bin" "dev" "out" "doc" ];
}
```
Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.

94
doc/stdenv/stdenv.chapter.md
View File

@@ -36,7 +36,7 @@ Many packages have dependencies that are not provided in the standard environmen
stdenv.mkDerivation {
pname = "libfoo";
version = "1.2.3";
...
# ...
buildInputs = [libbar perl ncurses];
}
```
@@ -49,7 +49,7 @@ Often it is necessary to override or modify some aspect of the build. To make th
stdenv.mkDerivation {
pname = "fnord";
version = "4.5";
...
# ...
buildPhase = ''
gcc foo.c -o foo
'';
@@ -70,7 +70,7 @@ While the standard environment provides a generic builder, you can still supply
stdenv.mkDerivation {
pname = "libfoo";
version = "1.2.3";
...
# ...
builder = ./builder.sh;
}
```
@@ -449,11 +449,13 @@ Unless set to `false`, some build systems with good support for parallel buildin
This is an attribute set which can be filled with arbitrary values. For example:
```nix
passthru = {
foo = "bar";
baz = {
value1 = 4;
value2 = 5;
{
passthru = {
foo = "bar";
baz = {
value1 = 4;
value2 = 5;
};
};
}
```
@@ -467,27 +469,33 @@ A script to be run by `maintainers/scripts/update.nix` when the package is match
- []{#var-passthru-updateScript-command} an executable file, either on the file system:
```nix
passthru.updateScript = ./update.sh;
{
passthru.updateScript = ./update.sh;
}
```
or inside the expression itself:
```nix
passthru.updateScript = writeScript "update-zoom-us" ''
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p curl pcre2 common-updater-scripts
{
passthru.updateScript = writeScript "update-zoom-us" ''
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p curl pcre2 common-updater-scripts
set -eu -o pipefail
set -eu -o pipefail
version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"
update-source-version zoom-us "$version"
'';
version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"
update-source-version zoom-us "$version"
'';
}
```
- a list, a script followed by arguments to be passed to it:
```nix
passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
{
passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
}
```
- an attribute set containing:
@@ -496,18 +504,22 @@ A script to be run by `maintainers/scripts/update.nix` when the package is match
- [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.
```nix
passthru.updateScript = {
command = [ ../../update.sh pname ];
attrPath = pname;
supportedFeatures = [ … ];
};
{
passthru.updateScript = {
command = [ ../../update.sh pname ];
attrPath = pname;
supportedFeatures = [ /* ... */ ];
};
}
```
::: {.tip}
A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):
```nix
passthru.updateScript = nix-update-script { };
{
passthru.updateScript = nix-update-script { };
}
```
For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).
@@ -846,7 +858,9 @@ The file name of the Makefile.
A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).
```nix
makeFlags = [ "PREFIX=$(out)" ];
{
makeFlags = [ "PREFIX=$(out)" ];
}
```
::: {.note}
@@ -858,9 +872,11 @@ The flags are quoted in bash, but environment variables can be specified by usin
A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.
```nix
preBuild = ''
makeFlagsArray+=(CFLAGS="-O0 -g" LDFLAGS="-lfoo -lbar")
'';
{
preBuild = ''
makeFlagsArray+=(CFLAGS="-O0 -g" LDFLAGS="-lfoo -lbar")
'';
}
```
Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.
@@ -892,7 +908,9 @@ The check phase checks whether the package was built correctly by running its te
Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should set
```nix
doCheck = true;
{
doCheck = true;
}
```
in the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.
@@ -945,7 +963,9 @@ See the [build phase](#var-stdenv-makeFlags) for details.
The make targets that perform the installation. Defaults to `install`. Example:
```nix
installTargets = "install-bin install-doc";
{
installTargets = "install-bin install-doc";
}
```
##### `installFlags` / `installFlagsArray` {#var-stdenv-installFlags}
@@ -1024,7 +1044,7 @@ This example prevents all `*.rlib` files from being stripped:
```nix
stdenv.mkDerivation {
# ...
stripExclude = [ "*.rlib" ]
stripExclude = [ "*.rlib" ];
}
```
@@ -1033,7 +1053,7 @@ This example prevents files within certain paths from being stripped:
```nix
stdenv.mkDerivation {
# ...
stripExclude = [ "lib/modules/*/build/* ]
stripExclude = [ "lib/modules/*/build/*" ];
}
```
@@ -1134,7 +1154,9 @@ It is often better to add tests that are not part of the source distribution to
Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should set
```nix
doInstallCheck = true;
{
doInstallCheck = true;
}
```
in the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.
@@ -1244,9 +1266,11 @@ To use this, add `removeReferencesTo` to `nativeBuildInputs`.
As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
Example removing all references to the compiler in the output:
```nix
postInstall = ''
find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
'';
{
postInstall = ''
find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
'';
}
```
### `substitute` \<infile\> \<outfile\> \<subs\> {#fun-substitute}

2
doc/using/configuration.chapter.md
View File

@@ -176,7 +176,7 @@ You can define a function called `packageOverrides` in your local `~/.config/nix
```nix
{
packageOverrides = pkgs: rec {
foo = pkgs.foo.override { ... };
foo = pkgs.foo.override { /* ... */ };
};
}
```

2
doc/using/overlays.chapter.md
View File

@@ -141,7 +141,7 @@ For BLAS/LAPACK switching to work correctly, all packages must depend on `blas`
assert (!blas.isILP64) && (!lapack.isILP64);
stdenv.mkDerivation {
...
# ...
}
```

54
doc/using/overrides.chapter.md
View File

@@ -13,13 +13,13 @@ It is used to override the arguments passed to a function.
Example usages:
```nix
pkgs.foo.override { arg1 = val1; arg2 = val2; ... }
pkgs.foo.override { arg1 = val1; arg2 = val2; /* ... */ }
```
It's also possible to access the previous arguments.
```nix
pkgs.foo.override (previous: { arg1 = previous.arg1; ... })
pkgs.foo.override (previous: { arg1 = previous.arg1; /* ... */ })
```
<!-- TODO: move below programlisting to a new section about extending and overlays and reference it -->
@@ -27,13 +27,15 @@ pkgs.foo.override (previous: { arg1 = previous.arg1; ... })
```nix
import pkgs.path { overlays = [ (self: super: {
foo = super.foo.override { barSupport = true ; };
})]};
})];}
```
```nix
mypkg = pkgs.callPackage ./mypkg.nix {
mydep = pkgs.mydep.override { ... };
}
{
mypkg = pkgs.callPackage ./mypkg.nix {
mydep = pkgs.mydep.override { /* ... */ };
};
}
```
In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.
@@ -45,9 +47,11 @@ The function `overrideAttrs` allows overriding the attribute set passed to a `st
Example usages:
```nix
helloBar = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
pname = previousAttrs.pname + "-bar";
});
{
helloBar = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
pname = previousAttrs.pname + "-bar";
});
}
```
In the above example, "-bar" is appended to the pname attribute, while all other attributes will be retained from the original `hello` package.
@@ -61,9 +65,11 @@ If only a one-argument function is written, the argument has the meaning of `pre
Function arguments can be omitted entirely if there is no need to access `previousAttrs` or `finalAttrs`.
```nix
helloWithDebug = pkgs.hello.overrideAttrs {
separateDebugInfo = true;
};
{
helloWithDebug = pkgs.hello.overrideAttrs {
separateDebugInfo = true;
};
}
```
In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`.
@@ -87,14 +93,16 @@ The function `overrideDerivation` creates a new derivation based on an existing
Example usage:
```nix
mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
name = "sed-4.2.2-pre";
src = fetchurl {
url = "ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2";
hash = "sha256-MxBJRcM2rYzQYwJ5XKxhXTQByvSg5jZc5cSHEZoB2IY=";
};
patches = [];
});
{
mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
name = "sed-4.2.2-pre";
src = fetchurl {
url = "ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2";
hash = "sha256-MxBJRcM2rYzQYwJ5XKxhXTQByvSg5jZc5cSHEZoB2IY=";
};
patches = [];
});
}
```
In the above example, the `name`, `src`, and `patches` of the derivation will be overridden, while all other attributes will be retained from the original derivation.
@@ -112,8 +120,10 @@ The function `lib.makeOverridable` is used to make the result of a function easi
Example usage:
```nix
f = { a, b }: { result = a+b; };
c = lib.makeOverridable f { a = 1; b = 2; };
{
f = { a, b }: { result = a+b; };
c = lib.makeOverridable f { a = 1; b = 2; };
}
```
The variable `c` is the value of the `f` function applied with some default arguments. Hence the value of `c.result` is `3`, in this example.

87
lib/cli.nix
View File

@@ -1,43 +1,64 @@
{ lib }:
rec {
/* Automatically convert an attribute set to command-line options.
/**
Automatically convert an attribute set to command-line options.
This helps protect against malformed command lines and also to reduce
boilerplate related to command-line construction for simple use cases.
This helps protect against malformed command lines and also to reduce
boilerplate related to command-line construction for simple use cases.
`toGNUCommandLine` returns a list of nix strings.
`toGNUCommandLineShell` returns an escaped shell string.
`toGNUCommandLine` returns a list of nix strings.
Example:
cli.toGNUCommandLine {} {
data = builtins.toJSON { id = 0; };
X = "PUT";
retry = 3;
retry-delay = null;
url = [ "https://example.com/foo" "https://example.com/bar" ];
silent = false;
verbose = true;
}
=> [
"-X" "PUT"
"--data" "{\"id\":0}"
"--retry" "3"
"--url" "https://example.com/foo"
"--url" "https://example.com/bar"
"--verbose"
]
`toGNUCommandLineShell` returns an escaped shell string.
cli.toGNUCommandLineShell {} {
data = builtins.toJSON { id = 0; };
X = "PUT";
retry = 3;
retry-delay = null;
url = [ "https://example.com/foo" "https://example.com/bar" ];
silent = false;
verbose = true;
}
=> "'-X' 'PUT' '--data' '{\"id\":0}' '--retry' '3' '--url' 'https://example.com/foo' '--url' 'https://example.com/bar' '--verbose'";
# Inputs
`options`
: 1\. Function argument
`attrs`
: 2\. Function argument
# Examples
:::{.example}
## `lib.cli.toGNUCommandLineShell` usage example
```nix
cli.toGNUCommandLine {} {
data = builtins.toJSON { id = 0; };
X = "PUT";
retry = 3;
retry-delay = null;
url = [ "https://example.com/foo" "https://example.com/bar" ];
silent = false;
verbose = true;
}
=> [
"-X" "PUT"
"--data" "{\"id\":0}"
"--retry" "3"
"--url" "https://example.com/foo"
"--url" "https://example.com/bar"
"--verbose"
]
cli.toGNUCommandLineShell {} {
data = builtins.toJSON { id = 0; };
X = "PUT";
retry = 3;
retry-delay = null;
url = [ "https://example.com/foo" "https://example.com/bar" ];
silent = false;
verbose = true;
}
=> "'-X' 'PUT' '--data' '{\"id\":0}' '--retry' '3' '--url' 'https://example.com/foo' '--url' 'https://example.com/bar' '--verbose'";
```
:::
*/
toGNUCommandLineShell =
options: attrs: lib.escapeShellArgs (toGNUCommandLine options attrs);

301
lib/customisation.nix
View File

@@ -15,42 +15,64 @@ in
rec {
/* `overrideDerivation drv f` takes a derivation (i.e., the result
of a call to the builtin function `derivation`) and returns a new
derivation in which the attributes of the original are overridden
according to the function `f`. The function `f` is called with
the original derivation attributes.
/**
`overrideDerivation drv f` takes a derivation (i.e., the result
of a call to the builtin function `derivation`) and returns a new
derivation in which the attributes of the original are overridden
according to the function `f`. The function `f` is called with
the original derivation attributes.
`overrideDerivation` allows certain "ad-hoc" customisation
scenarios (e.g. in ~/.config/nixpkgs/config.nix). For instance,
if you want to "patch" the derivation returned by a package
function in Nixpkgs to build another version than what the
function itself provides.
`overrideDerivation` allows certain "ad-hoc" customisation
scenarios (e.g. in ~/.config/nixpkgs/config.nix). For instance,
if you want to "patch" the derivation returned by a package
function in Nixpkgs to build another version than what the
function itself provides.
For another application, see build-support/vm, where this
function is used to build arbitrary derivations inside a QEMU
virtual machine.
For another application, see build-support/vm, where this
function is used to build arbitrary derivations inside a QEMU
virtual machine.
Note that in order to preserve evaluation errors, the new derivation's
outPath depends on the old one's, which means that this function cannot
be used in circular situations when the old derivation also depends on the
new one.
Note that in order to preserve evaluation errors, the new derivation's
outPath depends on the old one's, which means that this function cannot
be used in circular situations when the old derivation also depends on the
new one.
You should in general prefer `drv.overrideAttrs` over this function;
see the nixpkgs manual for more information on overriding.
You should in general prefer `drv.overrideAttrs` over this function;
see the nixpkgs manual for more information on overriding.
Example:
mySed = overrideDerivation pkgs.gnused (oldAttrs: {
name = "sed-4.2.2-pre";
src = fetchurl {
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
hash = "sha256-MxBJRcM2rYzQYwJ5XKxhXTQByvSg5jZc5cSHEZoB2IY=";
};
patches = [];
});
Type:
overrideDerivation :: Derivation -> ( Derivation -> AttrSet ) -> Derivation
# Inputs
`drv`
: 1\. Function argument
`f`
: 2\. Function argument
# Type
```
overrideDerivation :: Derivation -> ( Derivation -> AttrSet ) -> Derivation
```
# Examples
:::{.example}
## `lib.customisation.overrideDerivation` usage example
```nix
mySed = overrideDerivation pkgs.gnused (oldAttrs: {
name = "sed-4.2.2-pre";
src = fetchurl {
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
hash = "sha256-MxBJRcM2rYzQYwJ5XKxhXTQByvSg5jZc5cSHEZoB2IY=";
};
patches = [];
});
```
:::
*/
overrideDerivation = drv: f:
let
@@ -67,26 +89,44 @@ rec {
});
/* `makeOverridable` takes a function from attribute set to attribute set and
injects `override` attribute which can be used to override arguments of
the function.
/**
`makeOverridable` takes a function from attribute set to attribute set and
injects `override` attribute which can be used to override arguments of
the function.
Please refer to documentation on [`<pkg>.overrideDerivation`](#sec-pkg-overrideDerivation) to learn about `overrideDerivation` and caveats
related to its use.
Please refer to documentation on [`<pkg>.overrideDerivation`](#sec-pkg-overrideDerivation) to learn about `overrideDerivation` and caveats
related to its use.
Example:
nix-repl> x = {a, b}: { result = a + b; }
nix-repl> y = lib.makeOverridable x { a = 1; b = 2; }
# Inputs
nix-repl> y
{ override = «lambda»; overrideDerivation = «lambda»; result = 3; }
`f`
nix-repl> y.override { a = 10; }
{ override = «lambda»; overrideDerivation = «lambda»; result = 12; }
: 1\. Function argument
Type:
makeOverridable :: (AttrSet -> a) -> AttrSet -> a
# Type
```
makeOverridable :: (AttrSet -> a) -> AttrSet -> a
```
# Examples
:::{.example}
## `lib.customisation.makeOverridable` usage example
```nix
nix-repl> x = {a, b}: { result = a + b; }
nix-repl> y = lib.makeOverridable x { a = 1; b = 2; }
nix-repl> y
{ override = «lambda»; overrideDerivation = «lambda»; result = 3; }
nix-repl> y.override { a = 10; }
{ override = «lambda»; overrideDerivation = «lambda»; result = 12; }
```
:::
*/
makeOverridable = f:
let
@@ -120,7 +160,8 @@ rec {
else result);
/* Call the package function in the file `fn` with the required
/**
Call the package function in the file `fn` with the required
arguments automatically. The function is called with the
arguments `args`, but any missing arguments are obtained from
`autoArgs`. This function is intended to be partially
@@ -147,8 +188,26 @@ rec {
<!-- TODO: Apply "Example:" tag to the examples above -->
Type:
callPackageWith :: AttrSet -> ((AttrSet -> a) | Path) -> AttrSet -> a
# Inputs
`autoArgs`
: 1\. Function argument
`fn`
: 2\. Function argument
`args`
: 3\. Function argument
# Type
```
callPackageWith :: AttrSet -> ((AttrSet -> a) | Path) -> AttrSet -> a
```
*/
callPackageWith = autoArgs: fn: args:
let
@@ -210,12 +269,31 @@ rec {
else abort "lib.customisation.callPackageWith: ${error}";
/* Like callPackage, but for a function that returns an attribute
set of derivations. The override function is added to the
individual attributes.
/**
Like callPackage, but for a function that returns an attribute
set of derivations. The override function is added to the
individual attributes.
Type:
callPackagesWith :: AttrSet -> ((AttrSet -> AttrSet) | Path) -> AttrSet -> AttrSet
# Inputs
`autoArgs`
: 1\. Function argument
`fn`
: 2\. Function argument
`args`
: 3\. Function argument
# Type
```
callPackagesWith :: AttrSet -> ((AttrSet -> AttrSet) | Path) -> AttrSet -> AttrSet
```
*/
callPackagesWith = autoArgs: fn: args:
let
@@ -233,11 +311,30 @@ rec {
else mapAttrs mkAttrOverridable pkgs;
/* Add attributes to each output of a derivation without changing
the derivation itself and check a given condition when evaluating.
/**
Add attributes to each output of a derivation without changing
the derivation itself and check a given condition when evaluating.
Type:
extendDerivation :: Bool -> Any -> Derivation -> Derivation
# Inputs
`condition`
: 1\. Function argument
`passthru`
: 2\. Function argument
`drv`
: 3\. Function argument
# Type
```
extendDerivation :: Bool -> Any -> Derivation -> Derivation
```
*/
extendDerivation = condition: passthru: drv:
let
@@ -269,13 +366,24 @@ rec {
outPath = assert condition; drv.outPath;
};
/* Strip a derivation of all non-essential attributes, returning
only those needed by hydra-eval-jobs. Also strictly evaluate the
result to ensure that there are no thunks kept alive to prevent
garbage collection.
/**
Strip a derivation of all non-essential attributes, returning
only those needed by hydra-eval-jobs. Also strictly evaluate the
result to ensure that there are no thunks kept alive to prevent
garbage collection.
Type:
hydraJob :: (Derivation | Null) -> (Derivation | Null)
# Inputs
`drv`
: 1\. Function argument
# Type
```
hydraJob :: (Derivation | Null) -> (Derivation | Null)
```
*/
hydraJob = drv:
let
@@ -443,32 +551,65 @@ rec {
};
in self;
/* backward compatibility with old uncurried form; deprecated */
/**
backward compatibility with old uncurried form; deprecated
# Inputs
`splicePackages`
: 1\. Function argument
`newScope`
: 2\. Function argument
`otherSplices`
: 3\. Function argument
`keep`
: 4\. Function argument
`extra`
: 5\. Function argument
`f`
: 6\. Function argument
*/
makeScopeWithSplicing =
splicePackages: newScope: otherSplices: keep: extra: f:
makeScopeWithSplicing'
{ inherit splicePackages newScope; }
{ inherit otherSplices keep extra f; };
/* Like makeScope, but aims to support cross compilation. It's still ugly, but
hopefully it helps a little bit.
/**
Like makeScope, but aims to support cross compilation. It's still ugly, but
hopefully it helps a little bit.
Type:
makeScopeWithSplicing' ::
{ splicePackages :: Splice -> AttrSet
, newScope :: AttrSet -> ((AttrSet -> a) | Path) -> AttrSet -> a
}
-> { otherSplices :: Splice, keep :: AttrSet -> AttrSet, extra :: AttrSet -> AttrSet }
-> AttrSet
# Type
Splice ::
{ pkgsBuildBuild :: AttrSet
, pkgsBuildHost :: AttrSet
, pkgsBuildTarget :: AttrSet
, pkgsHostHost :: AttrSet
, pkgsHostTarget :: AttrSet
, pkgsTargetTarget :: AttrSet
}
```
makeScopeWithSplicing' ::
{ splicePackages :: Splice -> AttrSet
, newScope :: AttrSet -> ((AttrSet -> a) | Path) -> AttrSet -> a
}
-> { otherSplices :: Splice, keep :: AttrSet -> AttrSet, extra :: AttrSet -> AttrSet }
-> AttrSet
Splice ::
{ pkgsBuildBuild :: AttrSet
, pkgsBuildHost :: AttrSet
, pkgsBuildTarget :: AttrSet
, pkgsHostHost :: AttrSet
, pkgsHostTarget :: AttrSet
, pkgsTargetTarget :: AttrSet
}
```
*/
makeScopeWithSplicing' =
{ splicePackages

11
lib/licenses.nix
View File

@@ -392,6 +392,12 @@ in mkLicense lset) ({
fullName = "Common Public Attribution License 1.0";
};
commons-clause = {
fullName = "Commons Clause License";
url = "https://commonsclause.com/";
free = false;
};
cpl10 = {
spdxId = "CPL-1.0";
fullName = "Common Public License 1.0";
@@ -1266,11 +1272,6 @@ in mkLicense lset) ({
};
} // {
# TODO: remove legacy aliases
agpl3 = {
spdxId = "AGPL-3.0";
fullName = "GNU Affero General Public License v3.0";
deprecated = true;
};
gpl2 = {
spdxId = "GPL-2.0";
fullName = "GNU General Public License v2.0";

78
lib/systems/default.nix
View File

@@ -1,7 +1,25 @@
{ lib }:
let inherit (lib.attrsets) mapAttrs; in
rec {
let
inherit (lib)
any
filterAttrs
foldl
hasInfix
isFunction
isList
isString
mapAttrs
optional
optionalAttrs
optionalString
removeSuffix
replaceStrings
toUpper
;
inherit (lib.strings) toJSON;
doubles = import ./doubles.nix { inherit lib; };
parse = import ./parse.nix { inherit lib; };
inspect = import ./inspect.nix { inherit lib; };
@@ -24,7 +42,7 @@ rec {
both arguments have been `elaborate`-d.
*/
equals =
let removeFunctions = a: lib.filterAttrs (_: v: !builtins.isFunction v) a;
let removeFunctions = a: filterAttrs (_: v: !isFunction v) a;
in a: b: removeFunctions a == removeFunctions b;
/* List of all Nix system doubles the nixpkgs flake will expose the package set
@@ -41,7 +59,7 @@ rec {
# clearly preferred, and to prevent cycles. A simpler fixed point where the RHS
# always just used `final.*` would fail on both counts.
elaborate = args': let
args = if lib.isString args' then { system = args'; }
args = if isString args' then { system = args'; }
else args';
# TODO: deprecate args.rustc in favour of args.rust after 23.05 is EOL.
@@ -96,7 +114,7 @@ rec {
then "lib64"
else "lib"
else null;
extensions = lib.optionalAttrs final.hasSharedLibraries {
extensions = optionalAttrs final.hasSharedLibraries {
sharedLibrary =
if final.isDarwin then ".dylib"
else if final.isWindows then ".dll"
@@ -134,9 +152,9 @@ rec {
# uname -m
processor =
if final.isPower64
then "ppc64${lib.optionalString final.isLittleEndian "le"}"
then "ppc64${optionalString final.isLittleEndian "le"}"
else if final.isPower
then "ppc${lib.optionalString final.isLittleEndian "le"}"
then "ppc${optionalString final.isLittleEndian "le"}"
else if final.isMips64
then "mips64" # endianness is *not* included on mips64
else final.parsed.cpu.name;
@@ -202,8 +220,8 @@ rec {
else if final.isS390 && !final.isS390x then null
else if final.isx86_64 then "x86_64"
else if final.isx86 then "i386"
else if final.isMips64n32 then "mipsn32${lib.optionalString final.isLittleEndian "el"}"
else if final.isMips64 then "mips64${lib.optionalString final.isLittleEndian "el"}"
else if final.isMips64n32 then "mipsn32${optionalString final.isLittleEndian "el"}"
else if final.isMips64 then "mips64${optionalString final.isLittleEndian "el"}"
else final.uname.processor;
# Name used by UEFI for architectures.
@@ -243,10 +261,14 @@ rec {
vncSupport = false;
gtkSupport = false;
sdlSupport = false;
alsaSupport = false;
pulseSupport = false;
pipewireSupport = false;
jackSupport = false;
smbdSupport = false;
seccompSupport = false;
tpmSupport = false;
capstoneSupport = false;
enableDocs = false;
hostCpuTargets = [ "${final.qemuArch}-linux-user" ];
};
@@ -255,7 +277,7 @@ rec {
if pkgs.stdenv.hostPlatform.canExecute final
then "${pkgs.runtimeShell} -c '\"$@\"' --"
else if final.isWindows
then "${wine}/bin/wine${lib.optionalString (final.parsed.cpu.bits == 64) "64"}"
then "${wine}/bin/wine${optionalString (final.parsed.cpu.bits == 64) "64"}"
else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux && final.qemuArch != null
then "${qemu-user}/bin/qemu-${final.qemuArch}"
else if final.isWasi
@@ -306,10 +328,10 @@ rec {
let
f = args.rustc.platform.target-family;
in
if builtins.isList f then f else [ f ]
if isList f then f else [ f ]
)
else lib.optional final.isUnix "unix"
++ lib.optional final.isWindows "windows";
else optional final.isUnix "unix"
++ optional final.isWindows "windows";
# https://doc.rust-lang.org/reference/conditional-compilation.html#target_vendor
vendor = let
@@ -333,13 +355,13 @@ rec {
vendor_ = final.rust.platform.vendor;
# TODO: deprecate args.rustc in favour of args.rust after 23.05 is EOL.
in args.rust.rustcTarget or args.rustc.config
or "${cpu_}-${vendor_}-${kernel.name}${lib.optionalString (abi.name != "unknown") "-${abi.name}"}";
or "${cpu_}-${vendor_}-${kernel.name}${optionalString (abi.name != "unknown") "-${abi.name}"}";
# The name of the rust target if it is standard, or the json file
# containing the custom target spec.
rustcTargetSpec = rust.rustcTargetSpec or (
/**/ if rust ? platform
then builtins.toFile (final.rust.rustcTarget + ".json") (builtins.toJSON rust.platform)
then builtins.toFile (final.rust.rustcTarget + ".json") (toJSON rust.platform)
else final.rust.rustcTarget);
# The name of the rust target if it is standard, or the
@@ -348,7 +370,7 @@ rec {
#
# This is the name used by Cargo for target subdirectories.
cargoShortTarget =
lib.removeSuffix ".json" (baseNameOf "${final.rust.rustcTargetSpec}");
removeSuffix ".json" (baseNameOf "${final.rust.rustcTargetSpec}");
# When used as part of an environment variable name, triples are
# uppercased and have all hyphens replaced by underscores:
@@ -356,17 +378,17 @@ rec {
# https://github.com/rust-lang/cargo/pull/9169
# https://github.com/rust-lang/cargo/issues/8285#issuecomment-634202431
cargoEnvVarTarget =
lib.strings.replaceStrings ["-"] ["_"]
(lib.strings.toUpper final.rust.cargoShortTarget);
replaceStrings ["-"] ["_"]
(toUpper final.rust.cargoShortTarget);
# True if the target is no_std
# https://github.com/rust-lang/rust/blob/2e44c17c12cec45b6a682b1e53a04ac5b5fcc9d2/src/bootstrap/config.rs#L415-L421
isNoStdTarget =
builtins.any (t: lib.hasInfix t final.rust.rustcTarget) ["-none" "nvptx" "switch" "-uefi"];
any (t: hasInfix t final.rust.rustcTarget) ["-none" "nvptx" "switch" "-uefi"];
};
};
in assert final.useAndroidPrebuilt -> final.isAndroid;
assert lib.foldl
assert foldl
(pass: { assertion, message }:
if assertion final
then pass
@@ -374,4 +396,20 @@ rec {
true
(final.parsed.abi.assertions or []);
final;
in
# Everything in this attrset is the public interface of the file.
{
inherit
architectures
doubles
elaborate
equals
examples
flakeExposed
inspect
parse
platforms
;
}

49
lib/systems/inspect.nix
View File

@@ -1,10 +1,31 @@
{ lib }:
with import ./parse.nix { inherit lib; };
with lib.attrsets;
with lib.lists;
let abis_ = abis; in
let abis = lib.mapAttrs (_: abi: builtins.removeAttrs abi [ "assertions" ]) abis_; in
let
inherit (lib)
any
attrValues
concatMap
filter
hasPrefix
isList
mapAttrs
matchAttrs
recursiveUpdateUntil
toList
;
inherit (lib.strings) toJSON;
inherit (lib.systems.parse)
kernels
kernelFamilies
significantBytes
cpuTypes
execFormats
;
abis = mapAttrs (_: abi: removeAttrs abi [ "assertions" ]) lib.systems.parse.abis;
in
rec {
# these patterns are to be matched against {host,build,target}Platform.parsed
@@ -32,8 +53,8 @@ rec {
isx86 = { cpu = { family = "x86"; }; };
isAarch32 = { cpu = { family = "arm"; bits = 32; }; };
isArmv7 = map ({ arch, ... }: { cpu = { inherit arch; }; })
(lib.filter (cpu: lib.hasPrefix "armv7" cpu.arch or "")
(lib.attrValues cpuTypes));
(filter (cpu: hasPrefix "armv7" cpu.arch or "")
(attrValues cpuTypes));
isAarch64 = { cpu = { family = "arm"; bits = 64; }; };
isAarch = { cpu = { family = "arm"; }; };
isMicroBlaze = { cpu = { family = "microblaze"; }; };
@@ -111,19 +132,19 @@ rec {
let
# patterns can be either a list or a (bare) singleton; turn
# them into singletons for uniform handling
pat1 = lib.toList pat1_;
pat2 = lib.toList pat2_;
pat1 = toList pat1_;
pat2 = toList pat2_;
in
lib.concatMap (attr1:
concatMap (attr1:
map (attr2:
lib.recursiveUpdateUntil
recursiveUpdateUntil
(path: subattr1: subattr2:
if (builtins.intersectAttrs subattr1 subattr2) == {} || subattr1 == subattr2
then true
else throw ''
pattern conflict at path ${toString path}:
${builtins.toJSON subattr1}
${builtins.toJSON subattr2}
${toJSON subattr1}
${toJSON subattr2}
'')
attr1
attr2
@@ -132,7 +153,7 @@ rec {
pat1;
matchAnyAttrs = patterns:
if builtins.isList patterns then attrs: any (pattern: matchAttrs pattern attrs) patterns
if isList patterns then attrs: any (pattern: matchAttrs pattern attrs) patterns
else matchAttrs patterns;
predicates = mapAttrs (_: matchAnyAttrs) patterns;

68
lib/systems/parse.nix
View File

@@ -15,14 +15,45 @@
# systems that overlap with existing ones and won't notice something amiss.
#
{ lib }:
with lib.lists;
with lib.types;
with lib.attrsets;
with lib.strings;
with (import ./inspect.nix { inherit lib; }).predicates;
let
inherit (lib.options) mergeOneOption;
inherit (lib)
all
any
attrValues
elem
elemAt
hasPrefix
id
length
mapAttrs
mergeOneOption
optionalString
splitString
versionAtLeast
;
inherit (lib.strings) match;
inherit (lib.systems.inspect.predicates)
isAarch32
isBigEndian
isDarwin
isLinux
isPower64
isWindows
;
inherit (lib.types)
enum
float
isType
mkOptionType
number
setType
string
types
;
setTypes = type:
mapAttrs (name: value:
@@ -33,10 +64,10 @@ let
# regex `e?abi.*$` when determining the validity of a triple. In
# other words, `i386-linuxabichickenlips` is a valid triple.
removeAbiSuffix = x:
let match = builtins.match "(.*)e?abi.*" x;
in if match==null
let found = match "(.*)e?abi.*" x;
in if found == null
then x
else lib.elemAt match 0;
else elemAt found 0;
in
@@ -76,7 +107,7 @@ rec {
types.cpuType = enum (attrValues cpuTypes);
cpuTypes = with significantBytes; setTypes types.openCpuType {
cpuTypes = let inherit (significantBytes) bigEndian littleEndian; in setTypes types.openCpuType {
arm = { bits = 32; significantByte = littleEndian; family = "arm"; };
armv5tel = { bits = 32; significantByte = littleEndian; family = "arm"; version = "5"; arch = "armv5t"; };
armv6m = { bits = 32; significantByte = littleEndian; family = "arm"; version = "6"; arch = "armv6-m"; };
@@ -166,7 +197,7 @@ rec {
# Note: Since 22.11 the archs of a mode switching CPU are no longer considered
# pairwise compatible. Mode switching implies that binaries built for A
# and B respectively can't be executed at the same time.
isCompatible = a: b: with cpuTypes; lib.any lib.id [
isCompatible = with cpuTypes; a: b: any id [
# x86
(b == i386 && isCompatible a i486)
(b == i486 && isCompatible a i586)
@@ -287,7 +318,10 @@ rec {
types.kernel = enum (attrValues kernels);
kernels = with execFormats; with kernelFamilies; setTypes types.openKernel {
kernels = let
inherit (execFormats) elf pe wasm unknown macho;
inherit (kernelFamilies) bsd darwin;
in setTypes types.openKernel {
# TODO(@Ericson2314): Don't want to mass-rebuild yet to keeping 'darwin' as
# the normalized name for macOS.
macos = { execFormat = macho; families = { inherit darwin; }; name = "darwin"; };
@@ -359,7 +393,7 @@ rec {
The "gnu" ABI is ambiguous on 32-bit ARM. Use "gnueabi" or "gnueabihf" instead.
'';
}
{ assertion = platform: with platform; !(isPower64 && isBigEndian);
{ assertion = platform: !(platform.isPower64 && platform.isBigEndian);
message = ''
The "gnu" ABI is ambiguous on big-endian 64-bit PowerPC. Use "gnuabielfv2" or "gnuabielfv1" instead.
'';
@@ -480,7 +514,7 @@ rec {
/**/ if args ? abi then getAbi args.abi
else if isLinux parsed || isWindows parsed then
if isAarch32 parsed then
if lib.versionAtLeast (parsed.cpu.version or "0") "6"
if versionAtLeast (parsed.cpu.version or "0") "6"
then abis.gnueabihf
else abis.gnueabi
# Default ppc64 BE to ELFv2
@@ -491,7 +525,7 @@ rec {
in mkSystem parsed;
mkSystemFromString = s: mkSystemFromSkeleton (mkSkeletonFromList (lib.splitString "-" s));
mkSystemFromString = s: mkSystemFromSkeleton (mkSkeletonFromList (splitString "-" s));
kernelName = kernel:
kernel.name + toString (kernel.version or "");
@@ -503,10 +537,10 @@ rec {
tripleFromSystem = { cpu, vendor, kernel, abi, ... } @ sys: assert isSystem sys; let
optExecFormat =
lib.optionalString (kernel.name == "netbsd" &&
optionalString (kernel.name == "netbsd" &&
gnuNetBSDDefaultExecFormat cpu != kernel.execFormat)
kernel.execFormat.name;
optAbi = lib.optionalString (abi != abis.unknown) "-${abi.name}";
optAbi = optionalString (abi != abis.unknown) "-${abi.name}";
in "${cpu.name}-${vendor.name}-${kernelName kernel}${optExecFormat}${optAbi}";
################################################################################

8
maintainers/README.md
View File

@@ -87,8 +87,8 @@ checks should be performed:
keys = [{
fingerprint = "0000 0000 2A70 6423 0AED 3C11 F04F 7A19 AAA6 3AFE";
}];
}
};
};
}
```
First receive their key from a keyserver:
@@ -133,8 +133,8 @@ checks should be performed:
name = "Example User";
github = "ghost";
githubId = 10137;
}
};
};
}
```
First, make sure that the listed GitHub handle matches the author of

225
maintainers/maintainer-list.nix
View File

@@ -2958,6 +2958,12 @@
github = "bycEEE";
githubId = 8891115;
name = "Brian Choy";
};
ByteSudoer = {
email = "bytesudoer@gmail.com";
github = "bytesudoer";
githubId = 88513682;
name = "ByteSudoer";
};
bzizou = {
email = "Bruno@bzizou.net";
@@ -4739,6 +4745,12 @@
githubId = 4956158;
name = "Robin Stumm";
};
DerRockWolf = {
email = "git@rockwolf.eu";
github = "DerRockWolf";
githubId = 50499906;
name = "DerRockWolf";
};
DerTim1 = {
email = "tim.digel@active-group.de";
github = "DerTim1";
@@ -4820,6 +4832,12 @@
github = "dfithian";
githubId = 8409320;
};
dflores = {
email = "dflores.country455@passinbox.com";
name = "David Flores";
github = "dflores1";
githubId = 8538265;
};
dfordivam = {
email = "dfordivam+nixpkgs@gmail.com";
github = "dfordivam";
@@ -4832,6 +4850,12 @@
githubId = 4708206;
name = "Daniel Fox Franke";
};
dghubble = {
email = "dghubble@gmail.com";
github = "dghubble";
githubId = 2253428;
name = "Dalton Hubble";
};
dgliwka = {
email = "dawid.gliwka@gmail.com";
github = "dgliwka";
@@ -5423,6 +5447,7 @@
name = "Florentin Eckl";
};
eclairevoyant = {
email = "contactmeongithubinstead@proton.me";
github = "eclairevoyant";
githubId = 848000;
name = "éclairevoyant";
@@ -5689,6 +5714,12 @@
githubId = 2536303;
name = "Enno Lohmeier";
};
elpdt852 = {
email = "nix@pdtpartners.com";
github = "elpdt852";
githubId = 122112154;
name = "Edgar Lee";
};
elvishjerricco = {
email = "elvishjerricco@gmail.com";
matrix = "@elvishjerricco:matrix.org";
@@ -6180,7 +6211,7 @@
};
eymeric = {
name = "Eymeric Dechelette";
email = "hatchchcien@protonmail.com";
email = "hatchchien@protonmail.com";
github = "hatch01";
githubId = 42416805;
};
@@ -6776,6 +6807,15 @@
githubId = 21362942;
name = "Fugi";
};
funkeleinhorn = {
email = "git@funkeleinhorn.com";
github = "funkeleinhorn";
githubId = 103313934;
name = "Funkeleinhorn";
keys = [{
fingerprint = "689D 1C81 DA0D 1EB2 F029 D24E C7BE A25A 0A33 5A72";
}];
};
fusion809 = {
email = "brentonhorne77@gmail.com";
github = "fusion809";
@@ -7440,6 +7480,13 @@
githubId = 201997;
name = "Eric Seidel";
};
grimmauld = {
name = "Sören Bender";
email = "soeren@benjos.de";
github = "LordGrimmauld";
githubId = 49513131;
matrix = "@grimmauld:grimmauld.de";
};
grindhold = {
name = "grindhold";
email = "grindhold+nix@skarphed.org";
@@ -7769,6 +7816,12 @@
matrix = "@chris:netsoj.nl";
name = "Chris Josten";
};
hennk = {
email = "henning.kiel@gmail.com";
github = "hennk";
githubId = 328259;
name = "Henning Kiel";
};
henrikolsson = {
email = "henrik@fixme.se";
github = "henrikolsson";
@@ -8635,12 +8688,24 @@
github = "j0xaf";
githubId = 932697;
};
j1nxie = {
email = "rylie@rylie.moe";
name = "Nguyen Pham Quoc An";
github = "j1nxie";
githubId = 52886388;
};
j4m3s = {
name = "James Landrein";
email = "github@j4m3s.eu";
github = "j4m3s-s";
githubId = 9413812;
};
jab = {
name = "Joshua Bronson";
email = "jabronson@gmail.com";
github = "jab";
githubId = 64992;
};
jacbart = {
name = "Jack Bartlett";
email = "jacbart@gmail.com";
@@ -9027,6 +9092,12 @@
githubId = 1667473;
name = "Jethro Kuan";
};
jetpackjackson = {
email = "baileyannew@tutanota.com";
github = "JetpackJackson";
githubId = 88674707;
name = "Bailey Watkins";
};
jevy = {
email = "jevin@quickjack.ca";
github = "jevy";
@@ -9518,6 +9589,12 @@
githubId = 1843676;
name = "Jonathan Reeve";
};
jonboh = {
email = "jon.bosque.hernando@gmail.com";
github = "jonboh";
githubId = 31407988;
name = "Jon Bosque";
};
jonnybolton = {
email = "jonnybolton@gmail.com";
github = "jonnynightingale";
@@ -10292,6 +10369,12 @@
githubId = 691290;
name = "Keshav Kini";
};
kintrix = {
email = "kintrix007@proton.me";
github = "kintrix007";
githubId = 60898798;
name = "kintrix";
};
kinzoku = {
email = "kinzokudev4869@gmail.com";
github = "kinzoku-dev";
@@ -10784,6 +10867,12 @@
githubId = 695526;
name = "Benjamin Kober";
};
lampros = {
email = "hauahx@gmail.com";
github = "LamprosPitsillos";
githubId = 61395246;
name = "Lampros Pitsillos";
};
larsr = {
email = "Lars.Rasmusson@gmail.com";
github = "larsr";
@@ -11460,6 +11549,15 @@
githubId = 3717454;
name = "Lucas Bergman";
};
lucas-deangelis = {
email = "deangelis.lucas@outlook.com";
github = "lucas-deangelis";
githubId = 55180995;
name = "Lucas De Angelis";
keys = [{
fingerprint = "3C8B D3AD 93BB 1F36 B8FF 30BD 8627 E5ED F74B 5BF4";
}];
};
lucasew = {
email = "lucas59356@gmail.com";
github = "lucasew";
@@ -12458,6 +12556,12 @@
fingerprint = "D709 03C8 0BE9 ACDC 14F0 3BFB 77BF E531 397E DE94";
}];
};
mdorman = {
email = "mdorman@jaunder.io";
github = "mdorman";
githubId = 333344;
name = "Michael Alan Dorman";
};
mdr = {
email = "MattRussellUK@gmail.com";
github = "mdr";
@@ -12489,6 +12593,12 @@
githubId = 1631737;
name = "Mikhail Medvedev";
};
meebey = {
email = "meebey@meebey.net";
github = "meebey";
githubId = 318066;
name = "Mirco Bauer";
};
megheaiulian = {
email = "iulian.meghea@gmail.com";
github = "megheaiulian";
@@ -12531,6 +12641,15 @@
githubId = 15093162;
name = "Melanie B. Sigl";
};
melvyn2 = {
email = "melvyn2@dnsense.pub";
github = "melvyn2";
githubId = 9157412;
name = "melvyn";
keys = [{
fingerprint = "232B 9F00 2153 CA86 849C 9224 25A2 B728 0CE3 AFF6";
}];
};
mephistophiles = {
email = "mussitantesmortem@gmail.com";
name = "Maxim Zhukov";
@@ -13729,6 +13848,12 @@
githubId = 77314501;
name = "Maurice Zhou";
};
nealfennimore = {
email = "hi@neal.codes";
github = "nealfennimore";
githubId = 5731551;
name = "Neal Fennimore";
};
Nebucatnetzer = {
email = "andreas+nixpkgs@zweili.ch";
github = "Nebucatnetzer";
@@ -15005,6 +15130,12 @@
fingerprint = "E005 48D5 D6AC 812C AAD2 AFFA 9C42 B05E 5913 60DC";
}];
};
pbeucher = {
email = "pierre@crafteo.io";
github = "PierreBeucher";
githubId = 5041481;
name = "Pierre Beucher";
};
pblkt = {
email = "pebblekite@gmail.com";
github = "pblkt";
@@ -16136,6 +16267,15 @@
githubId = 104558;
name = "Benjamin Saunders";
};
ramblurr = {
name = "Casey Link";
email = "nix@caseylink.com";
github = "Ramblurr";
githubId = 14830;
keys = [{
fingerprint = "978C 4D08 058B A26E B97C B518 2078 2DBC ACFA ACDA";
}];
};
ramkromberg = {
email = "ramkromberg@mail.com";
github = "RamKromberg";
@@ -16504,6 +16644,11 @@
githubId = 61013287;
name = "Ricardo Steijn";
};
richar = {
github = "ri-char";
githubId = 17962023;
name = "richar";
};
richardipsum = {
email = "richardipsum@fastmail.co.uk";
github = "richardipsum";
@@ -16629,6 +16774,12 @@
githubId = 641278;
name = "Robert T. McGibbon";
};
rmgpinto = {
email = "hessian_loom_0u@icloud.com";
github = "rmgpinto";
githubId = 24584;
name = "Ricardo Gândara Pinto";
};
rnhmjoj = {
email = "rnhmjoj@inventati.org";
matrix = "@rnhmjoj:maxwell.ydns.eu";
@@ -16880,6 +17031,12 @@
github = "rski";
githubId = 2960312;
};
rsniezek = {
email = "radoslaw.sniezek@protonmail.com";
github = "rsniezek";
githubId = 19433256;
name = "Radoslaw Sniezek";
};
rsynnest = {
email = "contact@rsynnest.com";
github = "rsynnest";
@@ -17933,6 +18090,16 @@
github = "silky";
githubId = 129525;
};
sils = {
name = "Silas Schöffel";
email = "sils@sils.li";
matrix = "@sils:vhack.eu";
github = "s1ls";
githubId = 91412114;
keys = [{
fingerprint = "C1DA A551 B422 7A6F 3FD9 6B3A 467B 7D12 9EA7 3AC9";
}];
};
Silver-Golden = {
name = "Brendan Golden";
email = "github+nixpkgs@brendan.ie";
@@ -18415,6 +18582,21 @@
githubId = 950799;
name = "Tomasz Czyż";
};
spitulax = {
name = "Bintang Adiputra Pratama";
email = "bintangadiputrapratama@gmail.com";
github = "spitulax";
githubId = 96517350;
keys = [{
fingerprint = "652F FAAD 5CB8 AF1D 3F96 9521 929E D6C4 0414 D3F5";
}];
};
spk = {
email = "laurent@spkdev.net";
github = "spk";
githubId = 98590;
name = "Laurent Arnoud";
};
spoonbaker = {
github = "Spoonbaker";
githubId = 47164123;
@@ -18520,6 +18702,12 @@
githubId = 6362238;
name = "Christoph Honal";
};
starsep = {
email = "nix@starsep.com";
github = "starsep";
githubId = 2798728;
name = "Filip Czaplicki";
};
star-szr = {
email = "nixpkgs@szr.fastmail.com";
github = "star-szr";
@@ -18730,6 +18918,16 @@
githubId = 39732259;
name = "Justus K";
};
stv0g = {
name = "Steffen Vogel";
email = "post@steffenvogel.de";
matrix = "@stv0ge:matrix.org";
github = "stv0g";
githubId = 285829;
keys = [{
fingerprint = "09BE 3BAE 8D55 D4CD 8579 285A 9675 EAC3 4897 E6E2";
}];
};
SubhrajyotiSen = {
email = "subhrajyoti12@gmail.com";
github = "SubhrajyotiSen";
@@ -18989,6 +19187,12 @@
githubId = 321799;
name = "Paul Colomiets";
};
takac = {
email = "cammann.tom@gmail.com";
github = "takac";
githubId = 1015381;
name = "Tom Cammann";
};
takagiy = {
email = "takagiy.4dev@gmail.com";
github = "takagiy";
@@ -19350,6 +19554,13 @@
githubId = 42933;
name = "Andrew Childs";
};
thefossguy = {
name = "Pratham Patel";
email = "prathampatel@thefossguy.com";
matrix = "@thefossguy:matrix.org";
github = "thefossguy";
githubId = 44400303;
};
thehedgeh0g = {
name = "The Hedgehog";
email = "hedgehog@mrhedgehog.xyz";
@@ -21268,6 +21479,12 @@
githubId = 3028542;
name = "Guillermo NWDD";
};
xokdvium = {
email = "xokdvium@proton.me";
github = "xokdvium";
githubId = 145775305;
name = "Sergei Zimmerman";
};
xrelkd = {
github = "xrelkd";
githubId = 46590321;
@@ -21338,6 +21555,12 @@
github = "yanganto";
githubId = 10803111;
};
yannickulrich = {
email = "yannick.ulrich@proton.me";
github = "yannickulrich";
githubId = 749922;
name = "Yannick Ulrich";
};
yannip = {
email = "yPapandreou7@gmail.com";
github = "YanniPapandreou";

2
maintainers/scripts/README.md
View File

@@ -11,7 +11,7 @@ What follows is a (very incomplete) overview of available scripts.
### `check-by-name.sh`
An alias for `pkgs/test/nixpkgs-check-by-name/scripts/run-local.sh`, see [documentation](../../pkgs/test/nixpkgs-check-by-name/scripts/README.md).
An alias for `pkgs/test/check-by-name/run-local.sh`, see [documentation](../../pkgs/test/check-by-name/README.md).
### `get-maintainer.sh`

14
maintainers/scripts/bootstrap-files/README.md
View File

@@ -6,8 +6,9 @@ binaries (without the reliance on external inputs):
- `bootstrap-tools`: an archive with the compiler toolchain and other
helper tools enough to build the rest of the `nixpkgs`.
- initial binaries needed to unpack `bootstrap-tools.*`. On `linux`
it's just `busybox`, on `darwin` it's `sh`, `bzip2`, `mkdir` and
`cpio`. These binaries can be executed directly from the store.
it's just `busybox`, on `darwin` it is unpack.nar.xz which contains
the binaries and script needed to unpack the tools. These binaries
can be executed directly from the store.
These are called "bootstrap files".
@@ -74,12 +75,3 @@ There are two types of bootstrap files:
The `.build` job contains `/on-server/` subdirectory with binaries to
be uploaded to `tarballs.nixos.org`.
The files are uploaded to `tarballs.nixos.org` by writers to `S3` store.
## TODOs
- `pkgs/stdenv/darwin` file layout is slightly different from
`pkgs/stdenv/linux`. Once `linux` seed update becomes a routine we can
bring `darwin` in sync if it's feasible.
- `darwin` definition of `.build` `on-server/` directory layout differs
and should be updated.

33
maintainers/scripts/bootstrap-files/refresh-tarballs.bash
View File

@@ -6,6 +6,8 @@
#! nix-shell -p nix
#! nix-shell -p jq
set -o pipefail
# How the refresher works:
#
# For a given list of <targets>:
@@ -15,6 +17,9 @@
# 4. calculate hashes and craft the commit message with the details on
# how to upload the result to 'tarballs.nixos.org'
scratch_dir=$(mktemp -d)
trap 'rm -rf -- "${scratch_dir}"' EXIT
usage() {
cat >&2 <<EOF
Usage:
@@ -101,15 +106,17 @@ is_cross() {
}
nar_sri_get() {
local ouput sri
output=$(nix-build --expr \
'import <nix/fetchurl.nix> {
url = "'"$1"'";
unpack = true;
}' 2>&1 || true)
sri=$(echo "$output" | awk '/^\s+got:\s+/{ print $2 }')
[[ -z "$sri" ]] && die "$output"
echo "$sri"
local restore_path store_path
((${#@} != 2)) && die "nar_sri_get /path/to/name.nar.xz name"
restore_path="${scratch_dir}/$2"
xz -d < "$1" | nix-store --restore "${restore_path}"
[[ $? -ne 0 ]] && die "Failed to unpack '$1'"
store_path=$(nix-store --add "${restore_path}")
[[ $? -ne 0 ]] && die "Failed to add '$restore_path' to store"
rm -rf -- "${restore_path}"
nix-hash --to-sri "$(nix-store --query --hash "${store_path}")"
}
# collect passed options
@@ -239,9 +246,12 @@ EOF
executable_nix="executable = true;"
fi
unpack_nix=
if [[ $fname = *.nar.* ]]; then
name_nix=
if [[ $fname = *.nar.xz ]]; then
unpack_nix="unpack = true;"
sri=$(nar_sri_get "file://$p")
name_nix="name = \"${fname%.nar.xz}\";"
sri=$(nar_sri_get "$p" "${fname%.nar.xz}")
[[ $? -ne 0 ]] && die "Failed to get hash of '$p'"
else
sha256=$(nix-prefetch-url $executable_arg --name "$fname" "file://$p")
[[ $? -ne 0 ]] && die "Failed to get the hash for '$p'"
@@ -255,6 +265,7 @@ EOF
url = "http://tarballs.nixos.org/${s3_prefix}/${nixpkgs_revision}/$fname";
hash = "${sri}";$(
[[ -n ${executable_nix} ]] && printf "\n %s" "${executable_nix}"
[[ -n ${name_nix} ]] && printf "\n %s" "${name_nix}"
[[ -n ${unpack_nix} ]] && printf "\n %s" "${unpack_nix}"
)
};

2
maintainers/scripts/check-by-name.sh
View File

@@ -1 +1 @@
../../pkgs/test/nixpkgs-check-by-name/scripts/run-local.sh
../../pkgs/test/check-by-name/run-local.sh

2
maintainers/scripts/kde/generate-sources.py
View File

@@ -1,5 +1,5 @@
#!/usr/bin/env nix-shell
#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.beautifulsoup4 ps.click ps.httpx ps.jinja2 ps.pyyaml ])
#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.beautifulsoup4 ps.click ps.httpx ps.jinja2 ps.pyyaml ])"
import base64
import binascii
import json

3
maintainers/team-list.nix
View File

@@ -559,7 +559,7 @@ with lib.maintainers; {
ericson2314
lovek323
qyliss
raitobezarius
RossComputerGuy
rrbutani
sternenseemann
];
@@ -880,6 +880,7 @@ with lib.maintainers; {
members = [
Madouura
Flakebi
mschwaig
];
githubTeams = [
"rocm-maintainers"

6
nixos/doc/manual/administration/cleaning-store.chapter.md
View File

@@ -21,8 +21,10 @@ You can tell NixOS in `configuration.nix` to run this unit automatically
at certain points in time, for instance, every night at 03:15:
```nix
nix.gc.automatic = true;
nix.gc.dates = "03:15";
{
nix.gc.automatic = true;
nix.gc.dates = "03:15";
}
```
The commands above do not remove garbage collector roots, such as old

12
nixos/doc/manual/administration/container-networking.section.md
View File

@@ -26,9 +26,11 @@ host to rewrite container traffic to use your external IP address. This
can be accomplished using the following configuration on the host:
```nix
networking.nat.enable = true;
networking.nat.internalInterfaces = ["ve-+"];
networking.nat.externalInterface = "eth0";
{
networking.nat.enable = true;
networking.nat.internalInterfaces = ["ve-+"];
networking.nat.externalInterface = "eth0";
}
```
where `eth0` should be replaced with the desired external interface.
@@ -38,7 +40,9 @@ If you are using Network Manager, you need to explicitly prevent it from
managing container interfaces:
```nix
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
{
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
}
```
You may need to restart your system for the changes to take effect.

8
nixos/doc/manual/administration/control-groups.chapter.md
View File

@@ -39,7 +39,9 @@ they were in the same cgroup, then the PostgreSQL process would get
`configuration.nix`:
```nix
systemd.services.httpd.serviceConfig.CPUShares = 512;
{
systemd.services.httpd.serviceConfig.CPUShares = 512;
}
```
By default, every cgroup has 1024 CPU shares, so this will halve the CPU
@@ -52,7 +54,9 @@ limits can be specified in `configuration.nix`; for instance, to limit
`httpd.service` to 512 MiB of RAM (excluding swap):
```nix
systemd.services.httpd.serviceConfig.MemoryLimit = "512M";
{
systemd.services.httpd.serviceConfig.MemoryLimit = "512M";
}
```
The command `systemd-cgtop` shows a continuously updated list of all

28
nixos/doc/manual/administration/declarative-containers.section.md
View File

@@ -5,13 +5,15 @@ You can also specify containers and their configuration in the host's
shall be a container named `database` running PostgreSQL:
```nix
containers.database =
{ config =
{ config, pkgs, ... }:
{ services.postgresql.enable = true;
services.postgresql.package = pkgs.postgresql_14;
};
};
{
containers.database =
{ config =
{ config, pkgs, ... }:
{ services.postgresql.enable = true;
services.postgresql.package = pkgs.postgresql_14;
};
};
}
```
If you run `nixos-rebuild switch`, the container will be built. If the
@@ -25,11 +27,13 @@ cannot change the network configuration. You can give a container its
own network as follows:
```nix
containers.database = {
privateNetwork = true;
hostAddress = "192.168.100.10";
localAddress = "192.168.100.11";
};
{
containers.database = {
privateNetwork = true;
hostAddress = "192.168.100.10";
localAddress = "192.168.100.11";
};
}
```
This gives the container a private virtual Ethernet interface with IP

4
nixos/doc/manual/administration/service-mgmt.chapter.md
View File

@@ -82,7 +82,9 @@ In order to enable a systemd *system* service with provided upstream
package, use (e.g):
```nix
systemd.packages = [ pkgs.packagekit ];
{
systemd.packages = [ pkgs.packagekit ];
}
```
Usually NixOS modules written by the community do the above, plus take

6
nixos/doc/manual/configuration/abstractions.section.md
View File

@@ -47,9 +47,9 @@ You can write a `let` wherever an expression is allowed. Thus, you also could ha
```nix
{
services.httpd.virtualHosts =
let commonConfig = ...; in
{ "blog.example.org" = (commonConfig // { ... })
"wiki.example.org" = (commonConfig // { ... })
let commonConfig = { /* ... */ }; in
{ "blog.example.org" = (commonConfig // { /* ... */ });
"wiki.example.org" = (commonConfig // { /* ... */ });
};
}
```

10
nixos/doc/manual/configuration/ad-hoc-network-config.section.md
View File

@@ -6,8 +6,10 @@ is useful for doing network configuration not covered by the existing NixOS
modules. For instance, to statically configure an IPv6 address:
```nix
networking.localCommands =
''
ip -6 addr add 2001:610:685:1::1/64 dev eth0
'';
{
networking.localCommands =
''
ip -6 addr add 2001:610:685:1::1/64 dev eth0
'';
}
```

34
nixos/doc/manual/configuration/adding-custom-packages.section.md
View File

@@ -23,7 +23,9 @@ Then you write and test the package as described in the Nixpkgs manual.
Finally, you add it to [](#opt-environment.systemPackages), e.g.
```nix
environment.systemPackages = [ pkgs.my-package ];
{
environment.systemPackages = [ pkgs.my-package ];
}
```
and you run `nixos-rebuild`, specifying your own Nixpkgs tree:
@@ -38,24 +40,28 @@ tree. For instance, here is how you specify a build of the
`configuration.nix`:
```nix
environment.systemPackages =
let
my-hello = with pkgs; stdenv.mkDerivation rec {
name = "hello-2.8";
src = fetchurl {
url = "mirror://gnu/hello/${name}.tar.gz";
hash = "sha256-5rd/gffPfa761Kn1tl3myunD8TuM+66oy1O7XqVGDXM=";
{
environment.systemPackages =
let
my-hello = with pkgs; stdenv.mkDerivation rec {
name = "hello-2.8";
src = fetchurl {
url = "mirror://gnu/hello/${name}.tar.gz";
hash = "sha256-5rd/gffPfa761Kn1tl3myunD8TuM+66oy1O7XqVGDXM=";
};
};
};
in
[ my-hello ];
in
[ my-hello ];
}
```
Of course, you can also move the definition of `my-hello` into a
separate Nix expression, e.g.
```nix
environment.systemPackages = [ (import ./my-hello.nix) ];
{
environment.systemPackages = [ (import ./my-hello.nix) ];
}
```
where `my-hello.nix` contains:
@@ -88,7 +94,9 @@ section](#module-services-flatpak). AppImages will not run "as-is" on NixOS.
First you need to install `appimage-run`: add to `/etc/nixos/configuration.nix`
```nix
environment.systemPackages = [ pkgs.appimage-run ];
{
environment.systemPackages = [ pkgs.appimage-run ];
}
```
Then instead of running the AppImage "as-is", run `appimage-run foo.appimage`.

60
nixos/doc/manual/configuration/config-file.section.md
View File

@@ -5,7 +5,7 @@ The NixOS configuration file generally looks like this:
```nix
{ config, pkgs, ... }:
{ option definitions
{ /* option definitions */
}
```
@@ -80,7 +80,9 @@ Strings
: Strings are enclosed in double quotes, e.g.
```nix
networking.hostName = "dexter";
{
networking.hostName = "dexter";
}
```
Special characters can be escaped by prefixing them with a backslash
@@ -89,11 +91,13 @@ Strings
Multi-line strings can be enclosed in *double single quotes*, e.g.
```nix
networking.extraHosts =
''
127.0.0.2 other-localhost
10.0.0.1 server
'';
{
networking.extraHosts =
''
127.0.0.2 other-localhost
10.0.0.1 server
'';
}
```
The main difference is that it strips from each line a number of
@@ -108,8 +112,10 @@ Booleans
: These can be `true` or `false`, e.g.
```nix
networking.firewall.enable = true;
networking.firewall.allowPing = false;
{
networking.firewall.enable = true;
networking.firewall.allowPing = false;
}
```
Integers
@@ -117,7 +123,9 @@ Integers
: For example,
```nix
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
{
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
}
```
(Note that here the attribute name `net.ipv4.tcp_keepalive_time` is
@@ -132,11 +140,13 @@ Sets
braces, as in the option definition
```nix
fileSystems."/boot" =
{ device = "/dev/sda1";
fsType = "ext4";
options = [ "rw" "data=ordered" "relatime" ];
};
{
fileSystems."/boot" =
{ device = "/dev/sda1";
fsType = "ext4";
options = [ "rw" "data=ordered" "relatime" ];
};
}
```
Lists
@@ -145,13 +155,17 @@ Lists
separated by whitespace, like this:
```nix
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
{
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
}
```
List elements can be any other type, e.g. sets:
```nix
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
{
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
}
```
Packages
@@ -161,12 +175,14 @@ Packages
argument `pkgs`. Typical uses:
```nix
environment.systemPackages =
[ pkgs.thunderbird
pkgs.emacs
];
{
environment.systemPackages =
[ pkgs.thunderbird
pkgs.emacs
];
services.postgresql.package = pkgs.postgresql_14;
services.postgresql.package = pkgs.postgresql_14;
}
```
The latter option definition changes the default PostgreSQL package

52
nixos/doc/manual/configuration/customizing-packages.section.md
View File

@@ -16,18 +16,20 @@ Examples include:
You can use them like this:
```nix
environment.systemPackages = with pkgs; [
sl
(pass.withExtensions (subpkgs: with subpkgs; [
pass-audit
pass-otp
pass-genphrase
]))
(python3.withPackages (subpkgs: with subpkgs; [
requests
]))
cowsay
];
{
environment.systemPackages = with pkgs; [
sl
(pass.withExtensions (subpkgs: with subpkgs; [
pass-audit
pass-otp
pass-genphrase
]))
(python3.withPackages (subpkgs: with subpkgs; [
requests
]))
cowsay
];
}
```
:::
@@ -38,7 +40,9 @@ dependency on GTK 2. If you want to build it against GTK 3, you can
specify that as follows:
```nix
environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
{
environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
}
```
The function `override` performs the call to the Nix function that
@@ -58,12 +62,14 @@ of the package, such as the source code. For instance, if you want to
override the source code of Emacs, you can say:
```nix
environment.systemPackages = [
(pkgs.emacs.overrideAttrs (oldAttrs: {
name = "emacs-25.0-pre";
src = /path/to/my/emacs/tree;
}))
];
{
environment.systemPackages = [
(pkgs.emacs.overrideAttrs (oldAttrs: {
name = "emacs-25.0-pre";
src = /path/to/my/emacs/tree;
}))
];
}
```
Here, `overrideAttrs` takes the Nix derivation specified by `pkgs.emacs`
@@ -80,9 +86,11 @@ two instances of the package. If you want to have everything depend on
your customised instance, you can apply a *global* override as follows:
```nix
nixpkgs.config.packageOverrides = pkgs:
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
};
{
nixpkgs.config.packageOverrides = pkgs:
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
};
}
```
The effect of this definition is essentially equivalent to modifying the

4
nixos/doc/manual/configuration/declarative-packages.section.md
View File

@@ -7,7 +7,9 @@ following line to `configuration.nix` enables the Mozilla Thunderbird
email application:
```nix
environment.systemPackages = [ pkgs.thunderbird ];
{
environment.systemPackages = [ pkgs.thunderbird ];
}
```
The effect of this specification is that the Thunderbird package from

10
nixos/doc/manual/configuration/file-systems.chapter.md
View File

@@ -6,10 +6,12 @@ Ext4 file system on device `/dev/disk/by-label/data` onto the mount
point `/data`:
```nix
fileSystems."/data" =
{ device = "/dev/disk/by-label/data";
fsType = "ext4";
};
{
fileSystems."/data" =
{ device = "/dev/disk/by-label/data";
fsType = "ext4";
};
}
```
This will create an entry in `/etc/fstab`, which will generate a

18
nixos/doc/manual/configuration/firewall.section.md
View File

@@ -5,14 +5,18 @@ and other unexpected packets. The firewall applies to both IPv4 and IPv6
traffic. It is enabled by default. It can be disabled as follows:
```nix
networking.firewall.enable = false;
{
networking.firewall.enable = false;
}
```
If the firewall is enabled, you can open specific TCP ports to the
outside world:
```nix
networking.firewall.allowedTCPPorts = [ 80 443 ];
{
networking.firewall.allowedTCPPorts = [ 80 443 ];
}
```
Note that TCP port 22 (ssh) is opened automatically if the SSH daemon is
@@ -22,10 +26,12 @@ enabled (`services.openssh.enable = true`). UDP ports can be opened through
To open ranges of TCP ports:
```nix
networking.firewall.allowedTCPPortRanges = [
{ from = 4000; to = 4007; }
{ from = 8000; to = 8010; }
];
{
networking.firewall.allowedTCPPortRanges = [
{ from = 4000; to = 4007; }
{ from = 8000; to = 8010; }
];
}
```
Similarly, UDP port ranges can be opened through

58
nixos/doc/manual/configuration/gpu-accel.chapter.md
View File

@@ -55,9 +55,11 @@ supported through the rocmPackages.clr.icd package. Adding this package to
enables OpenCL support:
```nix
hardware.opengl.extraPackages = [
rocmPackages.clr.icd
];
{
hardware.opengl.extraPackages = [
rocmPackages.clr.icd
];
}
```
### Intel {#sec-gpu-accel-opencl-intel}
@@ -74,9 +76,11 @@ to enable OpenCL support. For example, for Gen8 and later GPUs, the following
configuration can be used:
```nix
hardware.opengl.extraPackages = [
intel-compute-runtime
];
{
hardware.opengl.extraPackages = [
intel-compute-runtime
];
}
```
## Vulkan {#sec-gpu-accel-vulkan}
@@ -141,20 +145,22 @@ makes amdvlk the default driver and hides radv and lavapipe from the device list
A specific driver can be forced as follows:
```nix
hardware.opengl.extraPackages = [
pkgs.amdvlk
];
{
hardware.opengl.extraPackages = [
pkgs.amdvlk
];
# To enable Vulkan support for 32-bit applications, also add:
hardware.opengl.extraPackages32 = [
pkgs.driversi686Linux.amdvlk
];
# To enable Vulkan support for 32-bit applications, also add:
hardware.opengl.extraPackages32 = [
pkgs.driversi686Linux.amdvlk
];
# Force radv
environment.variables.AMD_VULKAN_ICD = "RADV";
# Or
environment.variables.VK_ICD_FILENAMES =
"/run/opengl-driver/share/vulkan/icd.d/radeon_icd.x86_64.json";
# Force radv
environment.variables.AMD_VULKAN_ICD = "RADV";
# Or
environment.variables.VK_ICD_FILENAMES =
"/run/opengl-driver/share/vulkan/icd.d/radeon_icd.x86_64.json";
}
```
## VA-API {#sec-gpu-accel-va-api}
@@ -178,17 +184,21 @@ $ nix-shell -p libva-utils --run vainfo
Modern Intel GPUs use the iHD driver, which can be installed with:
```nix
hardware.opengl.extraPackages = [
intel-media-driver
];
{
hardware.opengl.extraPackages = [
intel-media-driver
];
}
```
Older Intel GPUs use the i965 driver, which can be installed with:
```nix
hardware.opengl.extraPackages = [
intel-vaapi-driver
];
{
hardware.opengl.extraPackages = [
intel-vaapi-driver
];
}
```
## Common issues {#sec-gpu-accel-common-issues}

20
nixos/doc/manual/configuration/ipv4-config.section.md
View File

@@ -5,18 +5,22 @@ configure network interfaces. However, you can configure an interface
manually as follows:
```nix
networking.interfaces.eth0.ipv4.addresses = [ {
address = "192.168.1.2";
prefixLength = 24;
} ];
{
networking.interfaces.eth0.ipv4.addresses = [ {
address = "192.168.1.2";
prefixLength = 24;
} ];
}
```
Typically you'll also want to set a default gateway and set of name
servers:
```nix
networking.defaultGateway = "192.168.1.1";
networking.nameservers = [ "8.8.8.8" ];
{
networking.defaultGateway = "192.168.1.1";
networking.nameservers = [ "8.8.8.8" ];
}
```
::: {.note}
@@ -28,7 +32,9 @@ configuration is performed by `network-setup.service`.
The host name is set using [](#opt-networking.hostName):
```nix
networking.hostName = "cartman";
{
networking.hostName = "cartman";
}
```
The default host name is `nixos`. Set it to the empty string (`""`) to

28
nixos/doc/manual/configuration/ipv6-config.section.md
View File

@@ -9,34 +9,42 @@ may be overridden on a per-interface basis by
IPv6 support globally by setting:
```nix
networking.enableIPv6 = false;
{
networking.enableIPv6 = false;
}
```
You can disable IPv6 on a single interface using a normal sysctl (in
this example, we use interface `eth0`):
```nix
boot.kernel.sysctl."net.ipv6.conf.eth0.disable_ipv6" = true;
{
boot.kernel.sysctl."net.ipv6.conf.eth0.disable_ipv6" = true;
}
```
As with IPv4 networking interfaces are automatically configured via
DHCPv6. You can configure an interface manually:
```nix
networking.interfaces.eth0.ipv6.addresses = [ {
address = "fe00:aa:bb:cc::2";
prefixLength = 64;
} ];
{
networking.interfaces.eth0.ipv6.addresses = [ {
address = "fe00:aa:bb:cc::2";
prefixLength = 64;
} ];
}
```
For configuring a gateway, optionally with explicitly specified
interface:
```nix
networking.defaultGateway6 = {
address = "fe00::1";
interface = "enp0s3";
};
{
networking.defaultGateway6 = {
address = "fe00::1";
interface = "enp0s3";
};
}
```
See [](#sec-ipv4) for similar examples and additional information.

30
nixos/doc/manual/configuration/kubernetes.chapter.md
View File

@@ -7,14 +7,16 @@ There are generally two ways of enabling Kubernetes on NixOS. One way is
to enable and configure cluster components appropriately by hand:
```nix
services.kubernetes = {
apiserver.enable = true;
controllerManager.enable = true;
scheduler.enable = true;
addonManager.enable = true;
proxy.enable = true;
flannel.enable = true;
};
{
services.kubernetes = {
apiserver.enable = true;
controllerManager.enable = true;
scheduler.enable = true;
addonManager.enable = true;
proxy.enable = true;
flannel.enable = true;
};
}
```
Another way is to assign cluster roles ("master" and/or "node") to
@@ -22,20 +24,26 @@ the host. This enables apiserver, controllerManager, scheduler,
addonManager, kube-proxy and etcd:
```nix
services.kubernetes.roles = [ "master" ];
{
services.kubernetes.roles = [ "master" ];
}
```
While this will enable the kubelet and kube-proxy only:
```nix
services.kubernetes.roles = [ "node" ];
{
services.kubernetes.roles = [ "node" ];
}
```
Assigning both the master and node roles is usable if you want a single
node Kubernetes cluster for dev or testing purposes:
```nix
services.kubernetes.roles = [ "master" "node" ];
{
services.kubernetes.roles = [ "master" "node" ];
}
```
Note: Assigning either role will also default both

54
nixos/doc/manual/configuration/linux-kernel.chapter.md
View File

@@ -5,7 +5,9 @@ option `boot.kernelPackages`. For instance, this selects the Linux 3.10
kernel:
```nix
boot.kernelPackages = pkgs.linuxKernel.packages.linux_3_10;
{
boot.kernelPackages = pkgs.linuxKernel.packages.linux_3_10;
}
```
Note that this not only replaces the kernel, but also packages that are
@@ -40,13 +42,15 @@ If you want to change the kernel configuration, you can use the
instance, to enable support for the kernel debugger KGDB:
```nix
nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
linuxKernel.kernels.linux_5_10 = pkgs.linuxKernel.kernels.linux_5_10.override {
extraConfig = ''
KGDB y
'';
{
nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
linuxKernel.kernels.linux_5_10 = pkgs.linuxKernel.kernels.linux_5_10.override {
extraConfig = ''
KGDB y
'';
};
};
};
}
```
`extraConfig` takes a list of Linux kernel configuration options, one
@@ -59,14 +63,18 @@ by `udev`. You can force a module to be loaded via
[](#opt-boot.kernelModules), e.g.
```nix
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
{
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
}
```
If the module is required early during the boot (e.g. to mount the root
file system), you can use [](#opt-boot.initrd.kernelModules):
```nix
boot.initrd.kernelModules = [ "cifs" ];
{
boot.initrd.kernelModules = [ "cifs" ];
}
```
This causes the specified modules and their dependencies to be added to
@@ -76,7 +84,9 @@ Kernel runtime parameters can be set through
[](#opt-boot.kernel.sysctl), e.g.
```nix
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
{
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
}
```
sets the kernel's TCP keepalive time to 120 seconds. To see the
@@ -89,7 +99,9 @@ Please refer to the Nixpkgs manual for the various ways of [building a custom ke
To use your custom kernel package in your NixOS configuration, set
```nix
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
{
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
}
```
## Rust {#sec-linux-rust}
@@ -99,15 +111,17 @@ default. For kernel versions 6.7 or newer, experimental Rust support
can be enabled. In a NixOS configuration, set:
```nix
boot.kernelPatches = [
{
name = "Rust Support";
patch = null;
features = {
rust = true;
};
}
];
{
boot.kernelPatches = [
{
name = "Rust Support";
patch = null;
features = {
rust = true;
};
}
];
}
```
## Developing kernel modules {#sec-linux-config-developing-modules}

34
nixos/doc/manual/configuration/luks-file-systems.section.md
View File

@@ -29,15 +29,19 @@ system is automatically mounted at boot time as `/`, add the following
to `configuration.nix`:
```nix
boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
fileSystems."/".device = "/dev/mapper/crypted";
{
boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
fileSystems."/".device = "/dev/mapper/crypted";
}
```
Should grub be used as bootloader, and `/boot` is located on an
encrypted partition, it is necessary to add the following grub option:
```nix
boot.loader.grub.enableCryptodisk = true;
{
boot.loader.grub.enableCryptodisk = true;
}
```
## FIDO2 {#sec-luks-file-systems-fido2}
@@ -68,8 +72,10 @@ To ensure that this file system is decrypted using the FIDO2 compatible
key, add the following to `configuration.nix`:
```nix
boot.initrd.luks.fido2Support = true;
boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";
{
boot.initrd.luks.fido2Support = true;
boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";
}
```
You can also use the FIDO2 passwordless setup, but for security reasons,
@@ -77,7 +83,9 @@ you might want to enable it only when your device is PIN protected, such
as [Trezor](https://trezor.io/).
```nix
boot.initrd.luks.devices."/dev/sda2".fido2.passwordLess = true;
{
boot.initrd.luks.devices."/dev/sda2".fido2.passwordLess = true;
}
```
### systemd Stage 1 {#sec-luks-file-systems-fido2-systemd}
@@ -88,13 +96,15 @@ unlocking the existing LUKS2 volume `root` using any enrolled FIDO2 compatible
tokens.
```nix
boot.initrd = {
luks.devices.root = {
crypttabExtraOpts = [ "fido2-device=auto" ];
device = "/dev/sda2";
{
boot.initrd = {
luks.devices.root = {
crypttabExtraOpts = [ "fido2-device=auto" ];
device = "/dev/sda2";
};
systemd.enable = true;
};
systemd.enable = true;
};
}
```
All tokens that should be used for unlocking the LUKS2-encrypted volume must

10
nixos/doc/manual/configuration/modularity.section.md
View File

@@ -16,7 +16,7 @@ including them from `configuration.nix`, e.g.:
{ imports = [ ./vpn.nix ./kde.nix ];
services.httpd.enable = true;
environment.systemPackages = [ pkgs.emacs ];
...
# ...
}
```
@@ -42,7 +42,9 @@ merged last, so for list-type options, it will appear at the end of the
merged list. If you want it to appear first, you can use `mkBefore`:
```nix
boot.kernelModules = mkBefore [ "kvm-intel" ];
{
boot.kernelModules = mkBefore [ "kvm-intel" ];
}
```
This causes the `kvm-intel` kernel module to be loaded before any other
@@ -60,7 +62,9 @@ When that happens, it's possible to force one definition take precedence
over the others:
```nix
services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
{
services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
}
```
When using multiple modules, you may need to access configuration values

16
nixos/doc/manual/configuration/network-manager.section.md
View File

@@ -4,7 +4,9 @@ To facilitate network configuration, some desktop environments use
NetworkManager. You can enable NetworkManager by setting:
```nix
networking.networkmanager.enable = true;
{
networking.networkmanager.enable = true;
}
```
some desktop managers (e.g., GNOME) enable NetworkManager automatically
@@ -14,7 +16,9 @@ All users that should have permission to change network settings must
belong to the `networkmanager` group:
```nix
users.users.alice.extraGroups = [ "networkmanager" ];
{
users.users.alice.extraGroups = [ "networkmanager" ];
}
```
NetworkManager is controlled using either `nmcli` or `nmtui`
@@ -32,9 +36,11 @@ can be used together if desired. To do this you need to instruct
NetworkManager to ignore those interfaces like:
```nix
networking.networkmanager.unmanaged = [
"*" "except:type:wwan" "except:type:gsm"
];
{
networking.networkmanager.unmanaged = [
"*" "except:type:wwan" "except:type:gsm"
];
}
```
Refer to the option description for the exact syntax and references to

28
nixos/doc/manual/configuration/overlayfs.section.md
View File

@@ -4,21 +4,23 @@ NixOS offers a convenient abstraction to create both read-only as well writable
overlays.
```nix
fileSystems = {
"/writable-overlay" = {
overlay = {
lowerdir = [ writableOverlayLowerdir ];
upperdir = "/.rw-writable-overlay/upper";
workdir = "/.rw-writable-overlay/work";
{
fileSystems = {
"/writable-overlay" = {
overlay = {
lowerdir = [ writableOverlayLowerdir ];
upperdir = "/.rw-writable-overlay/upper";
workdir = "/.rw-writable-overlay/work";
};
# Mount the writable overlay in the initrd.
neededForBoot = true;
};
# Mount the writable overlay in the initrd.
neededForBoot = true;
"/readonly-overlay".overlay.lowerdir = [
writableOverlayLowerdir
writableOverlayLowerdir2
];
};
"/readonly-overlay".overlay.lowerdir = [
writableOverlayLowerdir
writableOverlayLowerdir2
];
};
}
```
If `upperdir` and `workdir` are not null, they will be created before the

8
nixos/doc/manual/configuration/profiles.chapter.md
View File

@@ -8,9 +8,11 @@ is to say, expected usage is to add them to the imports list of your
`/etc/configuration.nix` as such:
```nix
imports = [
<nixpkgs/nixos/modules/profiles/profile-name.nix>
];
{
imports = [
<nixpkgs/nixos/modules/profiles/profile-name.nix>
];
}
```
Even if some of these profiles seem only useful in the context of

20
nixos/doc/manual/configuration/renaming-interfaces.section.md
View File

@@ -25,10 +25,12 @@ we assign the name `wan` to the interface with MAC address
`52:54:00:12:01:01` using a netword link unit:
```nix
systemd.network.links."10-wan" = {
matchConfig.PermanentMACAddress = "52:54:00:12:01:01";
linkConfig.Name = "wan";
};
{
systemd.network.links."10-wan" = {
matchConfig.PermanentMACAddress = "52:54:00:12:01:01";
linkConfig.Name = "wan";
};
}
```
Note that links are directly read by udev, *not networkd*, and will work
@@ -37,10 +39,12 @@ even if networkd is disabled.
Alternatively, we can use a plain old udev rule:
```nix
boot.initrd.services.udev.rules = ''
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="52:54:00:12:01:01", KERNEL=="eth*", NAME="wan"
'';
{
boot.initrd.services.udev.rules = ''
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="52:54:00:12:01:01", KERNEL=="eth*", NAME="wan"
'';
}
```
::: {.warning}

10
nixos/doc/manual/configuration/ssh.section.md
View File

@@ -3,7 +3,9 @@
Secure shell (SSH) access to your machine can be enabled by setting:
```nix
services.openssh.enable = true;
{
services.openssh.enable = true;
}
```
By default, root logins using a password are disallowed. They can be
@@ -14,6 +16,8 @@ You can declaratively specify authorised RSA/DSA public keys for a user
as follows:
```nix
users.users.alice.openssh.authorizedKeys.keys =
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
{
users.users.alice.openssh.authorizedKeys.keys =
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
}
```

51
nixos/doc/manual/configuration/subversion.chapter.md
View File

@@ -21,9 +21,11 @@ Apache HTTP, setting [](#opt-services.httpd.adminAddr)
appropriately:
```nix
services.httpd.enable = true;
services.httpd.adminAddr = ...;
networking.firewall.allowedTCPPorts = [ 80 443 ];
{
services.httpd.enable = true;
services.httpd.adminAddr = "...";
networking.firewall.allowedTCPPorts = [ 80 443 ];
}
```
For a simple Subversion server with basic authentication, configure the
@@ -34,25 +36,28 @@ the `.authz` file describing access permission, and `AuthUserFile` to
the password file.
```nix
services.httpd.extraModules = [
# note that order is *super* important here
{ name = "dav_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_dav_svn.so"; }
{ name = "authz_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_authz_svn.so"; }
];
services.httpd.virtualHosts = {
"svn" = {
hostName = HOSTNAME;
documentRoot = DOCUMENTROOT;
locations."/svn".extraConfig = ''
DAV svn
SVNParentPath REPO_PARENT
AuthzSVNAccessFile ACCESS_FILE
AuthName "SVN Repositories"
AuthType Basic
AuthUserFile PASSWORD_FILE
Require valid-user
'';
}
{
services.httpd.extraModules = [
# note that order is *super* important here
{ name = "dav_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_dav_svn.so"; }
{ name = "authz_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_authz_svn.so"; }
];
services.httpd.virtualHosts = {
"svn" = {
hostName = HOSTNAME;
documentRoot = DOCUMENTROOT;
locations."/svn".extraConfig = ''
DAV svn
SVNParentPath REPO_PARENT
AuthzSVNAccessFile ACCESS_FILE
AuthName "SVN Repositories"
AuthType Basic
AuthUserFile PASSWORD_FILE
Require valid-user
'';
};
};
}
```
The key `"svn"` is just a symbolic name identifying the virtual host.
@@ -90,7 +95,7 @@ $ htpasswd -s PASSWORD_FILE USER_NAME
The file describing access permissions `ACCESS_FILE` will look something
like the following:
```nix
```
[/]
* = r

28
nixos/doc/manual/configuration/user-mgmt.chapter.md
View File

@@ -6,13 +6,15 @@ management. In the declarative style, users are specified in
account named `alice` shall exist:
```nix
users.users.alice = {
isNormalUser = true;
home = "/home/alice";
description = "Alice Foobar";
extraGroups = [ "wheel" "networkmanager" ];
openssh.authorizedKeys.keys = [ "ssh-dss AAAAB3Nza... alice@foobar" ];
};
{
users.users.alice = {
isNormalUser = true;
home = "/home/alice";
description = "Alice Foobar";
extraGroups = [ "wheel" "networkmanager" ];
openssh.authorizedKeys.keys = [ "ssh-dss AAAAB3Nza... alice@foobar" ];
};
}
```
Note that `alice` is a member of the `wheel` and `networkmanager`
@@ -38,7 +40,9 @@ A user ID (uid) is assigned automatically. You can also specify a uid
manually by adding
```nix
uid = 1000;
{
uid = 1000;
}
```
to the user specification.
@@ -47,7 +51,9 @@ Groups can be specified similarly. The following states that a group
named `students` shall exist:
```nix
users.groups.students.gid = 1000;
{
users.groups.students.gid = 1000;
}
```
As with users, the group ID (gid) is optional and will be assigned
@@ -100,7 +106,9 @@ Instead of using a custom perl script to create users and groups, you can use
systemd-sysusers:
```nix
systemd.sysusers.enable = true;
{
systemd.sysusers.enable = true;
}
```
The primary benefit of this is to remove a dependency on perl.

6
nixos/doc/manual/configuration/wayland.chapter.md
View File

@@ -9,7 +9,9 @@ a Wayland Compositor such as sway without separately enabling a Wayland
server:
```nix
{
programs.sway.enable = true;
}
```
This installs the sway compositor along with some essential utilities.
@@ -19,7 +21,9 @@ If you are using a wlroots-based compositor, like sway, and want to be
able to share your screen, you might want to activate this option:
```nix
xdg.portal.wlr.enable = true;
{
xdg.portal.wlr.enable = true;
}
```
and configure Pipewire using

40
nixos/doc/manual/configuration/wireless.section.md
View File

@@ -7,25 +7,29 @@ skip the rest of this section on wireless networks.
NixOS will start wpa_supplicant for you if you enable this setting:
```nix
networking.wireless.enable = true;
{
networking.wireless.enable = true;
}
```
NixOS lets you specify networks for wpa_supplicant declaratively:
```nix
networking.wireless.networks = {
echelon = { # SSID with no spaces or special characters
psk = "abcdefgh";
{
networking.wireless.networks = {
echelon = { # SSID with no spaces or special characters
psk = "abcdefgh";
};
"echelon's AP" = { # SSID with spaces and/or special characters
psk = "ijklmnop";
};
echelon = { # Hidden SSID
hidden = true;
psk = "qrstuvwx";
};
free.wifi = {}; # Public wireless network
};
"echelon's AP" = { # SSID with spaces and/or special characters
psk = "ijklmnop";
};
echelon = { # Hidden SSID
hidden = true;
psk = "qrstuvwx";
};
free.wifi = {}; # Public wireless network
};
}
```
Be aware that keys will be written to the nix store in plaintext! When
@@ -46,11 +50,13 @@ network={
```
```nix
networking.wireless.networks = {
echelon = {
pskRaw = "dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435";
{
networking.wireless.networks = {
echelon = {
pskRaw = "dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435";
};
};
};
}
```
or you can use it to directly generate the `wpa_supplicant.conf`:

148
nixos/doc/manual/configuration/x-windows.chapter.md
View File

@@ -4,7 +4,9 @@ The X Window System (X11) provides the basis of NixOS' graphical user
interface. It can be enabled as follows:
```nix
services.xserver.enable = true;
{
services.xserver.enable = true;
}
```
The X server will automatically detect and use the appropriate video
@@ -12,7 +14,9 @@ driver from a set of X.org drivers (such as `vesa` and `intel`). You can
also specify a driver manually, e.g.
```nix
services.xserver.videoDrivers = [ "r128" ];
{
services.xserver.videoDrivers = [ "r128" ];
}
```
to enable X.org's `xf86-video-r128` driver.
@@ -22,15 +26,17 @@ Otherwise, you can only log into a plain undecorated `xterm` window.
Thus you should pick one or more of the following lines:
```nix
services.xserver.desktopManager.plasma5.enable = true;
services.xserver.desktopManager.xfce.enable = true;
services.xserver.desktopManager.gnome.enable = true;
services.xserver.desktopManager.mate.enable = true;
services.xserver.windowManager.xmonad.enable = true;
services.xserver.windowManager.twm.enable = true;
services.xserver.windowManager.icewm.enable = true;
services.xserver.windowManager.i3.enable = true;
services.xserver.windowManager.herbstluftwm.enable = true;
{
services.xserver.desktopManager.plasma5.enable = true;
services.xserver.desktopManager.xfce.enable = true;
services.xserver.desktopManager.gnome.enable = true;
services.xserver.desktopManager.mate.enable = true;
services.xserver.windowManager.xmonad.enable = true;
services.xserver.windowManager.twm.enable = true;
services.xserver.windowManager.icewm.enable = true;
services.xserver.windowManager.i3.enable = true;
services.xserver.windowManager.herbstluftwm.enable = true;
}
```
NixOS's default *display manager* (the program that provides a graphical
@@ -38,22 +44,28 @@ login prompt and manages the X server) is LightDM. You can select an
alternative one by picking one of the following lines:
```nix
services.xserver.displayManager.sddm.enable = true;
services.xserver.displayManager.gdm.enable = true;
{
services.xserver.displayManager.sddm.enable = true;
services.xserver.displayManager.gdm.enable = true;
}
```
You can set the keyboard layout (and optionally the layout variant):
```nix
services.xserver.xkb.layout = "de";
services.xserver.xkb.variant = "neo";
{
services.xserver.xkb.layout = "de";
services.xserver.xkb.variant = "neo";
}
```
The X server is started automatically at boot time. If you don't want
this to happen, you can set:
```nix
services.xserver.autorun = false;
{
services.xserver.autorun = false;
}
```
The X server can then be started manually:
@@ -66,7 +78,9 @@ On 64-bit systems, if you want OpenGL for 32-bit programs such as in
Wine, you should also set the following:
```nix
hardware.opengl.driSupport32Bit = true;
{
hardware.opengl.driSupport32Bit = true;
}
```
## Auto-login {#sec-x11-auto-login}
@@ -84,16 +98,20 @@ desktop environment. If you wanted no desktop environment and i3 as your
your window manager, you'd define:
```nix
services.xserver.displayManager.defaultSession = "none+i3";
{
services.xserver.displayManager.defaultSession = "none+i3";
}
```
Every display manager in NixOS supports auto-login, here is an example
using lightdm for a user `alice`:
```nix
services.xserver.displayManager.lightdm.enable = true;
services.xserver.displayManager.autoLogin.enable = true;
services.xserver.displayManager.autoLogin.user = "alice";
{
services.xserver.displayManager.lightdm.enable = true;
services.xserver.displayManager.autoLogin.enable = true;
services.xserver.displayManager.autoLogin.user = "alice";
}
```
## Intel Graphics drivers {#sec-x11--graphics-cards-intel}
@@ -119,18 +137,22 @@ drivers. Use the option
to set one. The recommended configuration for modern systems is:
```nix
services.xserver.videoDrivers = [ "modesetting" ];
{
services.xserver.videoDrivers = [ "modesetting" ];
}
```
If you experience screen tearing no matter what, this configuration was
reported to resolve the issue:
```nix
services.xserver.videoDrivers = [ "intel" ];
services.xserver.deviceSection = ''
Option "DRI" "2"
Option "TearFree" "true"
'';
{
services.xserver.videoDrivers = [ "intel" ];
services.xserver.deviceSection = ''
Option "DRI" "2"
Option "TearFree" "true"
'';
}
```
Note that this will likely downgrade the performance compared to
@@ -143,17 +165,19 @@ better 3D performance than the X.org drivers. It is not enabled by
default because it's not free software. You can enable it as follows:
```nix
services.xserver.videoDrivers = [ "nvidia" ];
{
services.xserver.videoDrivers = [ "nvidia" ];
}
```
Or if you have an older card, you may have to use one of the legacy
drivers:
If you have an older card, you may have to use one of the legacy drivers:
```nix
services.xserver.videoDrivers = [ "nvidiaLegacy470" ];
services.xserver.videoDrivers = [ "nvidiaLegacy390" ];
services.xserver.videoDrivers = [ "nvidiaLegacy340" ];
services.xserver.videoDrivers = [ "nvidiaLegacy304" ];
{
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_470;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_390;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_340;
}
```
You may need to reboot after enabling this driver to prevent a clash
@@ -168,7 +192,9 @@ performance. If you still want to use it anyway, you need to explicitly
set:
```nix
services.xserver.videoDrivers = [ "amdgpu-pro" ];
{
services.xserver.videoDrivers = [ "amdgpu-pro" ];
}
```
You will need to reboot after enabling this driver to prevent a clash
@@ -180,14 +206,18 @@ Support for Synaptics touchpads (found in many laptops such as the Dell
Latitude series) can be enabled as follows:
```nix
services.xserver.libinput.enable = true;
{
services.xserver.libinput.enable = true;
}
```
The driver has many options (see [](#ch-options)).
For instance, the following disables tap-to-click behavior:
```nix
services.xserver.libinput.touchpad.tapping = false;
{
services.xserver.libinput.touchpad.tapping = false;
}
```
Note: the use of `services.xserver.synaptics` is deprecated since NixOS
@@ -200,9 +230,11 @@ GTK themes can be installed either to user profile or system-wide (via
GTK ones, you can use the following configuration:
```nix
qt.enable = true;
qt.platformTheme = "gtk2";
qt.style = "gtk2";
{
qt.enable = true;
qt.platformTheme = "gtk2";
qt.style = "gtk2";
}
```
## Custom XKB layouts {#custom-xkb-layouts}
@@ -219,7 +251,7 @@ Create a file called `us-greek` with the following content (under a
directory called `symbols`; it's an XKB peculiarity that will help with
testing):
```nix
```
xkb_symbols "us-greek"
{
include "us(basic)" // includes the base US keys
@@ -236,11 +268,13 @@ xkb_symbols "us-greek"
A minimal layout specification must include the following:
```nix
services.xserver.xkb.extraLayouts.us-greek = {
description = "US layout with alt-gr greek";
languages = [ "eng" ];
symbolsFile = /yourpath/symbols/us-greek;
};
{
services.xserver.xkb.extraLayouts.us-greek = {
description = "US layout with alt-gr greek";
languages = [ "eng" ];
symbolsFile = /yourpath/symbols/us-greek;
};
}
```
::: {.note}
@@ -277,7 +311,7 @@ Use the *xev* utility from `pkgs.xorg.xev` to find the codes of the keys
of interest, then create a `media-key` file to hold the keycodes
definitions
```nix
```
xkb_keycodes "media"
{
<volUp> = 123;
@@ -287,7 +321,7 @@ xkb_keycodes "media"
Now use the newly define keycodes in `media-sym`:
```nix
```
xkb_symbols "media"
{
key.type = "ONE_LEVEL";
@@ -299,12 +333,14 @@ xkb_symbols "media"
As before, to install the layout do
```nix
services.xserver.xkb.extraLayouts.media = {
description = "Multimedia keys remapping";
languages = [ "eng" ];
symbolsFile = /path/to/media-key;
keycodesFile = /path/to/media-sym;
};
{
services.xserver.xkb.extraLayouts.media = {
description = "Multimedia keys remapping";
languages = [ "eng" ];
symbolsFile = /path/to/media-key;
keycodesFile = /path/to/media-sym;
};
}
```
::: {.note}
@@ -320,7 +356,9 @@ workaround, you can set the keymap using `setxkbmap` at the start of the
session with:
```nix
services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
{
services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
}
```
If you are manually starting the X server, you should set the argument

22
nixos/doc/manual/configuration/xfce.chapter.md
View File

@@ -3,21 +3,25 @@
To enable the Xfce Desktop Environment, set
```nix
services.xserver.desktopManager.xfce.enable = true;
services.xserver.displayManager.defaultSession = "xfce";
{
services.xserver.desktopManager.xfce.enable = true;
services.xserver.displayManager.defaultSession = "xfce";
}
```
Optionally, *picom* can be enabled for nice graphical effects, some
example settings:
```nix
services.picom = {
enable = true;
fade = true;
inactiveOpacity = 0.9;
shadow = true;
fadeDelta = 4;
};
{
services.picom = {
enable = true;
fade = true;
inactiveOpacity = 0.9;
shadow = true;
fadeDelta = 4;
};
}
```
Some Xfce programs are not installed automatically. To install them

Some files were not shown because too many files have changed in this diff Show More