doc: update Nix code snippets format

Command: `mdcr --config doc/tests/mdcr-config.toml doc/`

doc/build-helpers/dev-shell-tools.chapter.md

@@ -42,9 +42,15 @@ This function does not support `__structuredAttrs`, but does support `passAsFile
 devShellTools.unstructuredDerivationInputEnv {
   drvAttrs = {
     name = "foo";
-    buildInputs = [ hello figlet ];
+    buildInputs = [
+      hello
+      figlet
+    ];
     builder = bash;
-    args = [ "-c" "${./builder.sh}" ];
+    args = [
+      "-c"
+      "${./builder.sh}"
+    ];
   };
 }
 # => {
@@ -69,7 +75,10 @@ Takes the relevant parts of a derivation and returns a set of environment variab
 let
   pkg = hello;
 in
-devShellTools.derivationOutputEnv { outputList = pkg.outputs; outputMap = pkg; }
+devShellTools.derivationOutputEnv {
+  outputList = pkg.outputs;
+  outputMap = pkg;
+}
 ```
 
 :::

doc/build-helpers/fetchers.chapter.md

@@ -491,7 +491,11 @@ It might be useful to manipulate the content downloaded by `fetchurl` directly i
 In this example, we'll adapt [](#ex-fetchers-fetchurl-nixpkgs-version) to append the result of running the `hello` package to the contents we download, purely to illustrate how to manipulate the content.
 
 ```nix
-{ fetchurl, hello, lib }:
+{
+  fetchurl,
+  hello,
+  lib,
+}:
 fetchurl {
   url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
 
@@ -714,9 +718,10 @@ A wrapper around `fetchpatch`, which takes:
 Here is an example of `fetchDebianPatch` in action:
 
 ```nix
-{ lib
+{
-, fetchDebianPatch
+  lib,
-, buildPythonPackage
+  fetchDebianPatch,
+  buildPythonPackage,
 }:
 
 buildPythonPackage rec {
@@ -914,7 +919,9 @@ It produces packages that cannot be built automatically.
 { fetchtorrent }:
 
 fetchtorrent {
-  config = { peer-limit-global = 100; };
+  config = {
+    peer-limit-global = 100;
+  };
   url = "magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c";
   hash = "";
 }

doc/build-helpers/images/appimagetools.section.md

@@ -66,7 +66,8 @@ let
     url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
     hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
   };
-in appimageTools.wrapType2 {
+in
+appimageTools.wrapType2 {
   inherit pname version src;
   extraPkgs = pkgs: [ pkgs.at-spi2-core ];
 }
@@ -106,7 +107,8 @@ let
   appimageContents = appimageTools.extract {
     inherit pname version src;
   };
-in appimageTools.wrapType2 {
+in
+appimageTools.wrapType2 {
   inherit pname version src;
 
   extraPkgs = pkgs: [ pkgs.at-spi2-core ];
@@ -150,7 +152,8 @@ let
       substituteInPlace $out/irccloud.desktop --replace-fail 'Exec=AppRun' 'Exec=${pname}'
     '';
   };
-in appimageTools.wrapType2 {
+in
+appimageTools.wrapType2 {
   inherit pname version src;
 
   extraPkgs = pkgs: [ pkgs.at-spi2-core ];

doc/build-helpers/images/dockertools.section.md

@@ -235,7 +235,11 @@ The following package builds a Docker image that runs the `redis-server` executa
 The Docker image will have name `redis` and tag `latest`.
 
 ```nix
-{ dockerTools, buildEnv, redis }:
+{
+  dockerTools,
+  buildEnv,
+  redis,
+}:
 dockerTools.buildImage {
   name = "redis";
   tag = "latest";
@@ -253,7 +257,9 @@ dockerTools.buildImage {
   config = {
     Cmd = [ "/bin/redis-server" ];
     WorkingDir = "/data";
-    Volumes = { "/data" = { }; };
+    Volumes = {
+      "/data" = { };
+    };
   };
 }
 ```
@@ -286,7 +292,11 @@ It uses `runAsRoot` to create a directory and a file inside the image.
 This works the same as [](#ex-dockerTools-buildImage-extraCommands), but uses `runAsRoot` instead of `extraCommands`.
 
 ```nix
-{ dockerTools, buildEnv, hello }:
+{
+  dockerTools,
+  buildEnv,
+  hello,
+}:
 dockerTools.buildImage {
   name = "hello";
   tag = "latest";
@@ -320,7 +330,11 @@ This works the same as [](#ex-dockerTools-buildImage-runAsRoot), but uses `extra
 Note that with `extraCommands`, we can't directly reference `/` and must create files and directories as if we were already on `/`.
 
 ```nix
-{ dockerTools, buildEnv, hello }:
+{
+  dockerTools,
+  buildEnv,
+  hello,
+}:
 dockerTools.buildImage {
   name = "hello";
   tag = "latest";
@@ -350,7 +364,11 @@ dockerTools.buildImage {
 Note that using a value of `"now"` in the `created` attribute will break reproducibility.
 
 ```nix
-{ dockerTools, buildEnv, hello }:
+{
+  dockerTools,
+  buildEnv,
+  hello,
+}:
 dockerTools.buildImage {
   name = "hello";
   tag = "latest";
@@ -766,7 +784,11 @@ The closure of `config` is automatically included in the generated image.
 The following package shows a more compact way to create the same output generated in [](#ex-dockerTools-streamLayeredImage-hello).
 
 ```nix
-{ dockerTools, hello, lib }:
+{
+  dockerTools,
+  hello,
+  lib,
+}:
 dockerTools.streamLayeredImage {
   name = "hello";
   tag = "latest";
@@ -1547,7 +1569,11 @@ The Docker image generated will have a name like `hello-<version>-env` and tag `
 This example uses [](#ex-dockerTools-streamNixShellImage-hello) as a starting point.
 
 ```nix
-{ dockerTools, cowsay, hello }:
+{
+  dockerTools,
+  cowsay,
+  hello,
+}:
 dockerTools.streamNixShellImage {
   tag = "latest";
   drv = hello.overrideAttrs (old: {

doc/build-helpers/images/makediskimage.section.md

@@ -85,14 +85,21 @@ let
 in
 make-disk-image {
   inherit pkgs lib;
-    inherit (evalConfig {
+  inherit
+    (evalConfig {
       modules = [
         {
-          fileSystems."/" = { device = "/dev/vda"; fsType = "ext4"; autoFormat = true; };
+          fileSystems."/" = {
+            device = "/dev/vda";
+            fsType = "ext4";
+            autoFormat = true;
+          };
           boot.grub.device = "/dev/vda";
         }
       ];
-    }) config;
+    })
+    config
+    ;
   format = "qcow2";
   onlyNixStore = false;
   partitionTableType = "legacy+gpt";

doc/build-helpers/images/ocitools.section.md

@@ -76,7 +76,11 @@ Note that no user namespace is created, which means that you won't be able to ru
 This example uses `ociTools.buildContainer` to create a simple container that runs `bash`.
 
 ```nix
-{ ociTools, lib, bash }:
+{
+  ociTools,
+  lib,
+  bash,
+}:
 ociTools.buildContainer {
   args = [
     (lib.getExe bash)

doc/build-helpers/images/portableservice.section.md

@@ -91,7 +91,12 @@ See [](#ex-portableService-hello) to understand how to use the output of `portab
 The following example builds a Portable Service image with the `hello` package, along with a service unit that runs it.
 
 ```nix
-{ lib, writeText, portableService, hello }:
+{
+  lib,
+  writeText,
+  portableService,
+  hello,
+}:
 let
   hello-service = writeText "hello.service" ''
     [Unit]
@@ -151,7 +156,13 @@ To make things available globally, you must specify the `symlinks` attribute whe
 The following package builds on the package from [](#ex-portableService-hello) to make `/etc/ssl` available globally (this is only for illustrative purposes, because `hello` doesn't use `/etc/ssl`).
 
 ```nix
-{ lib, writeText, portableService, hello, cacert }:
+{
+  lib,
+  writeText,
+  portableService,
+  hello,
+  cacert,
+}:
 let
   hello-service = writeText "hello.service" ''
     [Unit]
@@ -167,7 +178,10 @@ portableService {
   inherit (hello) version;
   units = [ hello-service ];
   symlinks = [
-    { object = "${cacert}/etc/ssl"; symlink = "/etc/ssl"; }
+    {
+      object = "${cacert}/etc/ssl";
+      symlink = "/etc/ssl";
+    }
   ];
 }
 ```

doc/build-helpers/special/checkpoint-build.section.md

@@ -26,7 +26,9 @@ To change a normal derivation to a checkpoint based build, these steps must be t
 
 ## Example {#sec-checkpoint-build-example}
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 let
   inherit (pkgs.checkpointBuildTools)
     prepareCheckpointBuild
@@ -39,5 +41,6 @@ let
       sed -i 's/Hello, world!/Hello, Nix!/g' src/hello.c
     '';
   });
-in mkCheckpointBuild changedHello helloCheckpoint
+in
+mkCheckpointBuild changedHello helloCheckpoint
 ```

doc/build-helpers/special/fakenss.section.md

@@ -48,12 +48,19 @@ It is useful with functions in `dockerTools` to allow building Docker images tha
 This example includes the `hello` binary in the image so it can do something besides just have the extra files.
 
 ```nix
-{ dockerTools, fakeNss, hello }:
+{
+  dockerTools,
+  fakeNss,
+  hello,
+}:
 dockerTools.buildImage {
   name = "image-with-passwd";
   tag = "latest";
 
-  copyToRoot = [ fakeNss hello ];
+  copyToRoot = [
+    fakeNss
+    hello
+  ];
 
   config = {
     Cmd = [ "/bin/hello" ];

doc/build-helpers/special/fhs-environments.section.md

@@ -36,19 +36,26 @@ Accepted arguments are:
 You can create a simple environment using a `shell.nix` like this:
 
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 (pkgs.buildFHSEnv {
   name = "simple-x11-env";
-  targetPkgs = pkgs: (with pkgs; [
+  targetPkgs =
+    pkgs:
+    (with pkgs; [
       udev
       alsa-lib
-  ]) ++ (with pkgs.xorg; [
+    ])
+    ++ (with pkgs.xorg; [
       libX11
       libXcursor
       libXrandr
     ]);
-  multiPkgs = pkgs: (with pkgs; [
+  multiPkgs =
+    pkgs:
+    (with pkgs; [
       udev
       alsa-lib
     ]);

doc/build-helpers/special/mkshell.section.md

@@ -8,11 +8,16 @@ repetition when using it with `nix-shell` (or `nix develop`).
 Here is a common usage example:
 
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 pkgs.mkShell {
   packages = [ pkgs.gnumake ];
 
-  inputsFrom = [ pkgs.hello pkgs.gnutar ];
+  inputsFrom = [
+    pkgs.hello
+    pkgs.gnutar
+  ];
 
   shellHook = ''
     export DEBUG=1

doc/build-helpers/special/vm-tools.section.md

@@ -31,25 +31,34 @@ If the build fails and Nix is run with the `-K/--keep-failed` option, a script `
 
 Build the derivation hello inside a VM:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }: with pkgs; with vmTools; runInLinuxVM hello
-runInLinuxVM hello
 ```
 
 Build inside a VM with extra memory:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }:
-runInLinuxVM (hello.overrideAttrs (_: { memSize = 1024; }))
+with pkgs;
+with vmTools;
+runInLinuxVM (
+  hello.overrideAttrs (_: {
+    memSize = 1024;
+  })
+)
 ```
 
 Use VM with a disk image (implicitly sets `diskImage`, see [`vmTools.createEmptyImage`](#vm-tools-createEmptyImage)):
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }:
-runInLinuxVM (hello.overrideAttrs (_: {
+with pkgs;
+with vmTools;
+runInLinuxVM (
+  hello.overrideAttrs (_: {
     preVM = createEmptyImage {
       size = 1024;
       fullName = "vm-image";
     };
-}))
+  })
+)
 ```
 
 ## `vmTools.extractFs` {#vm-tools-extractFs}
@@ -66,8 +75,7 @@ Takes a file, such as an ISO, and extracts its contents into the store.
 
 Extract the contents of an ISO file:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }: with pkgs; with vmTools; extractFs { file = ./image.iso; }
-extractFs { file = ./image.iso; }
 ```
 
 ## `vmTools.extractMTDfs` {#vm-tools-extractMTDfs}
@@ -86,14 +94,12 @@ Generate a script that can be used to run an interactive session in the given im
 
 Create a script for running a Fedora 27 VM:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }: with pkgs; with vmTools; makeImageTestScript diskImages.fedora27x86_64
-makeImageTestScript diskImages.fedora27x86_64
 ```
 
 Create a script for running an Ubuntu 20.04 VM:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }: with pkgs; with vmTools; makeImageTestScript diskImages.ubuntu2004x86_64
-makeImageTestScript diskImages.ubuntu2004x86_64
 ```
 
 ## `vmTools.diskImageFuns` {#vm-tools-diskImageFuns}
@@ -137,8 +143,13 @@ A set of functions that build a predefined set of minimal Linux distributions im
 
 8GiB image containing Firefox in addition to the default packages:
 ```nix
-{ pkgs }: with pkgs; with vmTools;
+{ pkgs }:
-diskImageFuns.ubuntu2004x86_64 { extraPackages = [ "firefox" ]; size = 8192; }
+with pkgs;
+with vmTools;
+diskImageFuns.ubuntu2004x86_64 {
+  extraPackages = [ "firefox" ];
+  size = 8192;
+}
 ```
 
 ## `vmTools.diskImageExtraFuns` {#vm-tools-diskImageExtraFuns}

doc/build-helpers/testers.chapter.md

@@ -98,7 +98,8 @@ It has two modes:
   ```nix
   {
     "https://nix\\.dev/manual/nix/[a-z0-9.-]*" = "${nix.doc}/share/doc/nix/manual";
-    "https://nixos\\.org/manual/nix/(un)?stable" = "${emptyDirectory}/placeholder-to-disallow-old-nix-docs-urls";
+    "https://nixos\\.org/manual/nix/(un)?stable" =
+      "${emptyDirectory}/placeholder-to-disallow-old-nix-docs-urls";
   }
   ```
 
@@ -302,13 +303,17 @@ While `testBuildFailure` is designed to keep changes to the original builder's e
 # Check that a build fails, and verify the changes made during build
 
 ```nix
-runCommand "example" {
+runCommand "example"
-  failed = testers.testBuildFailure (runCommand "fail" {} ''
+  {
+    failed = testers.testBuildFailure (
+      runCommand "fail" { } ''
         echo ok-ish >$out
         echo failing though
         exit 3
-  '');
+      ''
-} ''
+    );
+  }
+  ''
     grep -F 'ok-ish' $failed/result
     grep -F 'failing though' $failed/testBuildFailure.log
     [[ 3 = $(cat $failed/testBuildFailure.exit) ]]
@@ -396,13 +401,16 @@ testers.testEqualContents {
   expected = writeText "expected" ''
     foo baz baz
   '';
-  actual = runCommand "actual" {
+  actual =
+    runCommand "actual"
+      {
         # not really necessary for a package that's in stdenv
         nativeBuildInputs = [ gnused ];
         base = writeText "base" ''
           foo bar baz
         '';
-  } ''
+      }
+      ''
         sed -e 's/bar/baz/g' $base >$out
       '';
 }
@@ -515,10 +523,11 @@ Otherwise, the build log explains the difference via `nix-diff`.
 # Check that two packages produce the same derivation
 
 ```nix
-testers.testEqualDerivation
+testers.testEqualDerivation "The hello package must stay the same when enabling checks." hello (
-  "The hello package must stay the same when enabling checks."
+  hello.overrideAttrs (o: {
-  hello
+    doCheck = true;
-  (hello.overrideAttrs(o: { doCheck = true; }))
+  })
+)
 ```
 
 :::
@@ -586,7 +595,10 @@ testers.runCommand {
     curl -o /dev/null https://example.com
     touch $out
   '';
-  nativeBuildInputs = with pkgs; [ cacert curl ];
+  nativeBuildInputs = with pkgs; [
+    cacert
+    curl
+  ];
 }
 ```
 
@@ -603,15 +615,20 @@ If your test is part of the Nixpkgs repository, or if you need a more general en
 # Run a NixOS test using `runNixOSTest`
 
 ```nix
-pkgs.testers.runNixOSTest ({ lib, ... }: {
+pkgs.testers.runNixOSTest (
+  { lib, ... }:
+  {
     name = "hello";
-  nodes.machine = { pkgs, ... }: {
+    nodes.machine =
+      { pkgs, ... }:
+      {
         environment.systemPackages = [ pkgs.hello ];
       };
     testScript = ''
       machine.succeed("hello")
     '';
-})
+  }
+)
 ```
 
 :::
@@ -634,7 +651,14 @@ A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-te
 {
   name = "my-test";
   nodes = {
-    machine1 = { lib, pkgs, nodes, ... }: {
+    machine1 =
+      {
+        lib,
+        pkgs,
+        nodes,
+        ...
+      }:
+      {
         environment.systemPackages = [ pkgs.hello ];
         services.foo.enable = true;
       };

doc/build-helpers/trivial-build-helpers.chapter.md

@@ -66,10 +66,12 @@ runCommandWith :: {
 # Invocation of `runCommandWith`
 
 ```nix
-runCommandWith {
+runCommandWith
+  {
     name = "example";
     derivationArgs.nativeBuildInputs = [ cowsay ];
-} ''
+  }
+  ''
     cowsay > $out <<EOMOO
     'runCommandWith' is a bit cumbersome,
     so we have more ergonomic wrappers.
@@ -260,7 +262,10 @@ makeDesktopItem {
   mimeTypes = [ "video/mp4" ];
   categories = [ "Utility" ];
   implements = [ "org.my-program" ];
-  keywords = [ "Video" "Player" ];
+  keywords = [
+    "Video"
+    "Player"
+  ];
   startupNotify = false;
   startupWMClass = "MyProgram";
   prefersNonDefaultGPU = false;
@@ -276,18 +281,22 @@ makeDesktopItem {
 Override the `hello` package to add a desktop item.
 
 ```nix
-{ copyDesktopItems
+{
-, hello
+  copyDesktopItems,
-, makeDesktopItem }:
+  hello,
+  makeDesktopItem,
+}:
 
 hello.overrideAttrs {
   nativeBuildInputs = [ copyDesktopItems ];
 
-  desktopItems = [(makeDesktopItem {
+  desktopItems = [
+    (makeDesktopItem {
       name = "hello";
       desktopName = "Hello";
       exec = "hello";
-  })];
+    })
+  ];
 }
 ```
 
@@ -446,8 +455,7 @@ The store path will include the name, and it will be a file.
 Write the string `Contents of File` to `/nix/store/<store path>`:
 
 ```nix
-writeText "my-file"
+writeText "my-file" ''
-  ''
   Contents of File
 ''
 ```
@@ -486,8 +494,7 @@ The store path will be a directory.
 Write the string `Contents of File` to `/nix/store/<store path>/share/my-file`:
 
 ```nix
-writeTextDir "share/my-file"
+writeTextDir "share/my-file" ''
-  ''
   Contents of File
 ''
 ```
@@ -528,8 +535,7 @@ The store path will include the name, and it will be a file.
 Write the string `Contents of File` to `/nix/store/<store path>` and make the file executable.
 
 ```nix
-writeScript "my-file"
+writeScript "my-file" ''
-  ''
   Contents of File
 ''
 ```
@@ -570,8 +576,7 @@ The store path will include the name, and it will be a directory.
 # Usage of `writeScriptBin`
 
 ```nix
-writeScriptBin "my-script"
+writeScriptBin "my-script" ''
-  ''
   echo "hi"
 ''
 ```
@@ -614,8 +619,7 @@ This function is almost exactly like [](#trivial-builder-writeScript), except th
 # Usage of `writeShellScript`
 
 ```nix
-writeShellScript "my-script"
+writeShellScript "my-script" ''
-  ''
   echo "hi"
 ''
 ```
@@ -657,8 +661,7 @@ This function is a combination of [](#trivial-builder-writeShellScript) and [](#
 # Usage of `writeShellScriptBin`
 
 ```nix
-writeShellScriptBin "my-script"
+writeShellScriptBin "my-script" ''
-  ''
   echo "hi"
 ''
 ```
@@ -685,26 +688,40 @@ These functions concatenate `files` to the Nix store in a single file. This is u
 
 Here are a few examples:
 ```nix
-
 # Writes my-file to /nix/store/<store path>
-concatTextFile {
+concatTextFile
+  {
     name = "my-file";
-  files = [ drv1 "${drv2}/path/to/file" ];
+    files = [
+      drv1
+      "${drv2}/path/to/file"
+    ];
   }
   # See also the `concatText` helper function below.
 
   # Writes executable my-file to /nix/store/<store path>/bin/my-file
-concatTextFile {
+  concatTextFile
+  {
     name = "my-file";
-  files = [ drv1 "${drv2}/path/to/file" ];
+    files = [
+      drv1
+      "${drv2}/path/to/file"
+    ];
     executable = true;
     destination = "/bin/my-file";
   }
   # Writes contents of files to /nix/store/<store path>
-concatText "my-file" [ file1 file2 ]
+  concatText
+  "my-file"
+  [ file1 file2 ]
 
   # Writes contents of files to /nix/store/<store path>
-concatScript "my-file" [ file1 file2 ]
+  concatScript
+  "my-file"
+  [
+    file1
+    file2
+  ]
 ```
 
 ## `writeShellApplication` {#trivial-builder-writeShellApplication}
@@ -722,7 +739,10 @@ For example, the following shell application can refer to `curl` directly, rathe
 writeShellApplication {
   name = "show-nixos-org";
 
-  runtimeInputs = [ curl w3m ];
+  runtimeInputs = [
+    curl
+    w3m
+  ];
 
   text = ''
     curl -s 'https://nixos.org' | w3m -dump -T text/html
@@ -736,7 +756,14 @@ This can be used to put many derivations into the same directory structure. It w
 Here is an example:
 ```nix
 # adds symlinks of hello and stack to current build and prints "links added"
-symlinkJoin { name = "myexample"; paths = [ pkgs.hello pkgs.stack ]; postBuild = "echo links added"; }
+symlinkJoin {
+  name = "myexample";
+  paths = [
+    pkgs.hello
+    pkgs.stack
+  ];
+  postBuild = "echo links added";
+}
 ```
 This creates a derivation with a directory structure like the following:
 ```

doc/functions/generators.section.md

@@ -13,17 +13,23 @@ let
     # specifies how to format a key/value pair
     mkKeyValue = generators.mkKeyValueDefault {
       # specifies the generated string for a subset of nix values
-      mkValueString = v:
+      mkValueString =
-             if v == true then ''"yes"''
+        v:
-        else if v == false then ''"no"''
+        if v == true then
-        else if isString v then ''"${v}"''
+          ''"yes"''
+        else if v == false then
+          ''"no"''
+        else if isString v then
+          ''"${v}"''
         # and delegates all other values to the default generator
-        else generators.mkValueStringDefault {} v;
+        else
+          generators.mkValueStringDefault { } v;
     } ":";
   };
 
   # the INI file can now be given as plain old nix values
-in customToINI {
+in
+customToINI {
   main = {
     pushinfo = true;
     autopush = false;

doc/functions/nix-gitignore.section.md

@@ -7,7 +7,10 @@
 `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> { },
+}:
+{
 
   src = nix-gitignore.gitignoreSource [ ] ./source;
   # Simplest version

doc/functions/prefer-remote-fetch.section.md

@@ -3,8 +3,7 @@
 `prefer-remote-fetch` is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
 
 ```nix
-self: super:
+self: super: (super.prefer-remote-fetch self super)
-  (super.prefer-remote-fetch self super)
 ```
 
 A full configuration example for that sets the overlay up for your own account, could look like this

doc/hooks/patch-rc-path-hooks.section.md

@@ -29,7 +29,11 @@ Given a package `foo` containing an init script `this-foo.fish` that depends on
 patch the init script for users to source without having the above dependencies in their `PATH`:
 
 ```nix
-{ lib, stdenv, patchRcPathFish}:
+{
+  lib,
+  stdenv,
+  patchRcPathFish,
+}:
 stdenv.mkDerivation {
 
   # ...
@@ -39,7 +43,13 @@ stdenv.mkDerivation {
   ];
 
   postFixup = ''
-    patchRcPathFish $out/bin/this-foo.fish ${lib.makeBinPath [ coreutils man which ]}
+    patchRcPathFish $out/bin/this-foo.fish ${
+      lib.makeBinPath [
+        coreutils
+        man
+        which
+      ]
+    }
   '';
 }
 ```

doc/hooks/postgresql-test-hook.section.md

@@ -4,7 +4,11 @@
 This hook starts a PostgreSQL server during the `checkPhase`. Example:
 
 ```nix
-{ stdenv, postgresql, postgresqlTestHook }:
+{
+  stdenv,
+  postgresql,
+  postgresqlTestHook,
+}:
 stdenv.mkDerivation {
 
   # ...

doc/hooks/redis-test-hook.section.md

@@ -7,7 +7,7 @@ This hook starts a Redis server during `checkPhase`. Example:
 {
   stdenv,
   redis,
-  redisTestHook
+  redisTestHook,
 }:
 stdenv.mkDerivation {
 
@@ -47,7 +47,11 @@ Bash-only variables:
 Example usage:
 
 ```nix
-{ stdenv, redis, redisTestHook }:
+{
+  stdenv,
+  redis,
+  redisTestHook,
+}:
 stdenv.mkDerivation {
 
   # ...
@@ -60,3 +64,4 @@ stdenv.mkDerivation {
     redisTestPort=6390;
   '';
 }
+```

doc/hooks/zig.section.md

@@ -7,9 +7,10 @@ In Nixpkgs, `zig.hook` overrides the default build, check and install phases.
 ## Example code snippet {#zig-hook-example-code-snippet}
 
 ```nix
-{ lib
+{
-, stdenv
+  lib,
-, zig
+  stdenv,
+  zig,
 }:
 
 stdenv.mkDerivation {

doc/interoperability/cyclonedx.md

@@ -63,17 +63,27 @@ For example, the `fetchFromGitHub` is commonly used within Nixpkgs but should be
 `nix:fod` properties may be extracted and evaluated to a derivation using code similar to the following, assuming a fictitious function `filterPropertiesToAttrs`:
 
 ```nix
-{ pkgs, filterPropertiesToAttrs, properties }:
+{
+  pkgs,
+  filterPropertiesToAttrs,
+  properties,
+}:
 let
   fodProps = filterPropertiesToAttrs "nix:fod:" properties;
 
   methods = {
     fetchzip =
-      { name, url, sha256, ... }:
+      {
+        name,
+        url,
+        sha256,
+        ...
+      }:
       pkgs.fetchzip {
         inherit name url sha256;
       };
   };
 
-in methods.${fodProps.method} fodProps
+in
+methods.${fodProps.method} fodProps
 ```

doc/languages-frameworks/agda.section.md

@@ -114,7 +114,9 @@ This can be overridden by a different version of `ghc` as follows:
 
 ```nix
 agda.withPackages {
-  pkgs = [ /* ... */ ];
+  pkgs = [
+    # ...
+  ];
   ghc = haskell.compiler.ghcHEAD;
 }
 ```
@@ -132,7 +134,9 @@ A derivation can then be written using `agdaPackages.mkDerivation`. This has sim
 Here is an example `default.nix`
 
 ```nix
-{ nixpkgs ?  <nixpkgs> }:
+{
+  nixpkgs ? <nixpkgs>,
+}:
 with (import nixpkgs { });
 agdaPackages.mkDerivation {
   version = "1.0";
@@ -179,7 +183,11 @@ the Agda package set is small and can (still) be maintained by hand.
 To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
 
 ```nix
-{ mkDerivation, standard-library, fetchFromGitHub }:
+{
+  mkDerivation,
+  standard-library,
+  fetchFromGitHub,
+}:
 { }
 ```
 

doc/languages-frameworks/android.section.md

@@ -26,9 +26,11 @@ Alternatively, you can pass composeAndroidPackages to the `withSdk` passthru:
 ```nix
 {
   buildInputs = [
-  (android-studio.withSdk (androidenv.composeAndroidPackages {
+    (android-studio.withSdk
+      (androidenv.composeAndroidPackages {
         includeNDK = true;
-  }).androidsdk)
+      }).androidsdk
+    )
   ];
 }
 ```
@@ -45,9 +47,15 @@ with import <nixpkgs> {};
 
 let
   androidComposition = androidenv.composeAndroidPackages {
-    platformVersions = [ "34" "35" ];
+    platformVersions = [
+      "34"
+      "35"
+    ];
     systemImageTypes = [ "google_apis_playstore" ];
-    abiVersions = [ "armeabi-v7a" "arm64-v8a" ];
+    abiVersions = [
+      "armeabi-v7a"
+      "arm64-v8a"
+    ];
     includeNDK = true;
     includeExtras = [
       "extras;google;auto"

doc/languages-frameworks/beam.section.md

@@ -60,7 +60,10 @@ $ nix-shell -p beamPackages.rebar3
 
 ```nix
 let
-  pkgs = import <nixpkgs> { config = {}; overlays = []; };
+  pkgs = import <nixpkgs> {
+    config = { };
+    overlays = [ ];
+  };
 in
 pkgs.mkShell {
   packages = [ pkgs.beamPackages.rebar3 ];
@@ -120,7 +123,8 @@ If there are git dependencies.
 {
   mixNixDeps = import ./mix.nix {
     inherit beamPackages lib;
-    overrides = (final: prev: {
+    overrides = (
+      final: prev: {
         # mix2nix does not support git dependencies yet,
         # so we need to add them manually
         prometheus_ex = beamPackages.buildMix rec {
@@ -139,7 +143,8 @@ If there are git dependencies.
           # you can re-use the same beamDeps argument as generated
           beamDeps = with final; [ prometheus ];
         };
-    });
+      }
+    );
   };
 }
 ```
@@ -200,8 +205,14 @@ let
 
   nodeDependencies = (pkgs.callPackage ./assets/default.nix { }).shell.nodeDependencies;
 
-in packages.mixRelease {
+in
-  inherit src pname version mixFodDeps;
+packages.mixRelease {
+  inherit
+    src
+    pname
+    version
+    mixFodDeps
+    ;
   # if you have build time environment variables add them here
   MY_ENV_VAR = "my_value";
 
@@ -231,7 +242,12 @@ In order to create a service with your release, you could add a `service.nix`
 in your project with the following
 
 ```nix
-{config, pkgs, lib, ...}:
+{
+  config,
+  pkgs,
+  lib,
+  ...
+}:
 
 let
   release = pkgs.callPackage ./default.nix;
@@ -241,10 +257,16 @@ in
 {
   systemd.services.${release_name} = {
     wantedBy = [ "multi-user.target" ];
-    after = [ "network.target" "postgresql.service" ];
+    after = [
+      "network.target"
+      "postgresql.service"
+    ];
     # note that if you are connecting to a postgres instance on a different host
     # postgresql.service should not be included in the requires.
-    requires = [ "network-online.target" "postgresql.service" ];
+    requires = [
+      "network-online.target"
+      "postgresql.service"
+    ];
     description = "my app";
     environment = {
       # RELEASE_TMP is used to write the state of the
@@ -292,7 +314,9 @@ in
 Usually, we need to create a `shell.nix` file and do our development inside of the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example with Elixir:
 
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 with pkgs;
 let
@@ -311,12 +335,14 @@ If you need to use an overlay to change some attributes of a derivation, e.g. if
 
 ```nix
 let
-  elixir_1_18_1_overlay = (self: super: {
+  elixir_1_18_1_overlay = (
+    self: super: {
       elixir_1_18 = super.elixir_1_18.override {
         version = "1.18.1";
         sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
       };
-    });
+    }
+  );
   pkgs = import <nixpkgs> { overlays = [ elixir_1_18_1_overlay ]; };
 in
 with pkgs;
@@ -349,9 +375,16 @@ let
     nodePackages.prettier
   ];
 
-  inputs = basePackages ++ lib.optionals stdenv.hostPlatform.isLinux [ inotify-tools ]
+  inputs =
-    ++ lib.optionals stdenv.hostPlatform.isDarwin
+    basePackages
-    (with darwin.apple_sdk.frameworks; [ CoreFoundation CoreServices ]);
+    ++ lib.optionals stdenv.hostPlatform.isLinux [ inotify-tools ]
+    ++ lib.optionals stdenv.hostPlatform.isDarwin (
+      with darwin.apple_sdk.frameworks;
+      [
+        CoreFoundation
+        CoreServices
+      ]
+    );
 
   # define shell startup command
   hooks = ''
@@ -380,7 +413,8 @@ let
     export ENV_VAR="your_env_var"
   '';
 
-in mkShell {
+in
+mkShell {
   buildInputs = inputs;
   shellHook = hooks;
 }

doc/languages-frameworks/bower.section.md

@@ -24,11 +24,15 @@ Running `bower2nix` will produce something like the following output:
 
 ```nix
 { fetchbower, buildEnv }:
-buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
+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.
@@ -80,8 +84,12 @@ gulp.task('build', [], function () {
 ### Example Full example — default.nix {#ex-buildBowerComponentsDefaultNix}
 
 ```nix
-{ myWebApp ? { outPath = ./.; name = "myWebApp"; }
+{
-, pkgs ? import <nixpkgs> {}
+  myWebApp ? {
+    outPath = ./.;
+    name = "myWebApp";
+  },
+  pkgs ? import <nixpkgs> { },
 }:
 
 pkgs.stdenv.mkDerivation {
@@ -90,7 +98,8 @@ pkgs.stdenv.mkDerivation {
 
   buildInputs = [ pkgs.nodePackages.gulp ];
 
-  bowerComponents = pkgs.buildBowerComponents { # note 1
+  bowerComponents = pkgs.buildBowerComponents {
+    # note 1
     name = "my-web-app";
     generated = ./bower-packages.nix;
     src = myWebApp;

doc/languages-frameworks/chicken.section.md

@@ -60,19 +60,23 @@ all the other eggs:
 
 ```nix
 let
-  myChickenPackages = pkgs.chickenPackages.overrideScope (self: super: {
+  myChickenPackages = pkgs.chickenPackages.overrideScope (
+    self: super: {
       # The chicken package itself can be overridden to effect the whole ecosystem.
       # chicken = super.chicken.overrideAttrs {
       #   src = ...
       # };
 
-      chickenEggs = super.chickenEggs.overrideScope (eggself: eggsuper: {
+      chickenEggs = super.chickenEggs.overrideScope (
+        eggself: eggsuper: {
           srfi-180 = eggsuper.srfi-180.overrideAttrs {
             # path to a local copy of srfi-180
             src = <...>;
           };
-      });
+        }
-  });
+      );
+    }
+  );
 in
 # Here, `myChickenPackages.chickenEggs.json-rpc`, which depends on `srfi-180` will use
 # the local copy of `srfi-180`.

doc/languages-frameworks/coq.section.md

@@ -54,21 +54,60 @@ It also takes other standard `mkDerivation` attributes, they are added as such,
 Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes some `mathcomp` derivations as `extraBuildInputs`.
 
 ```nix
-{ lib, mkCoqDerivation, version ? null
+{
-, coq, mathcomp, mathcomp-finmap, mathcomp-bigenough }:
+  lib,
+  mkCoqDerivation,
+  version ? null,
+  coq,
+  mathcomp,
+  mathcomp-finmap,
+  mathcomp-bigenough,
+}:
 
 mkCoqDerivation {
-  /* namePrefix leads to e.g. `name = coq8.11-mathcomp1.11-multinomials-1.5.2` */
+  # namePrefix leads to e.g. `name = coq8.11-mathcomp1.11-multinomials-1.5.2`
-  namePrefix = [ "coq" "mathcomp" ];
+  namePrefix = [
+    "coq"
+    "mathcomp"
+  ];
   pname = "multinomials";
   owner = "math-comp";
   inherit version;
-  defaultVersion = with lib.versions; lib.switch [ coq.version mathcomp.version ] [
+  defaultVersion =
-      { cases = [ (range "8.7" "8.12") (isEq "1.11") ];        out = "1.5.2"; }
+    with lib.versions;
-      { cases = [ (range "8.7" "8.11") (range "1.8" "1.10") ]; out = "1.5.0"; }
+    lib.switch
-      { cases = [ (range "8.7" "8.10") (range "1.8" "1.10") ]; out = "1.4"; }
+      [ coq.version mathcomp.version ]
-      { cases = [ (isEq "8.6")         (range "1.6" "1.7") ];  out = "1.1"; }
+      [
-    ] null;
+        {
+          cases = [
+            (range "8.7" "8.12")
+            (isEq "1.11")
+          ];
+          out = "1.5.2";
+        }
+        {
+          cases = [
+            (range "8.7" "8.11")
+            (range "1.8" "1.10")
+          ];
+          out = "1.5.0";
+        }
+        {
+          cases = [
+            (range "8.7" "8.10")
+            (range "1.8" "1.10")
+          ];
+          out = "1.4";
+        }
+        {
+          cases = [
+            (isEq "8.6")
+            (range "1.6" "1.7")
+          ];
+          out = "1.1";
+        }
+      ]
+      null;
   release = {
     "1.5.2".hash = "sha256-mjCx9XKa38Nz9E6wNK7YSqHdJ7YTua5fD3d6J4e7WpU=";
     "1.5.1".hash = "sha256-Q8tm0y2FQAt2V1kZYkDlHWRia/lTvXAMVjdmzEV11I4=";
@@ -81,8 +120,12 @@ mkCoqDerivation {
     "1.0".hash = "sha256-tZTOltEBBKWciDxDMs/Ye4Jnq/33CANrHJ4FBMPtq+I=";
   };
 
-  propagatedBuildInputs =
+  propagatedBuildInputs = [
-    [ mathcomp.ssreflect mathcomp.algebra mathcomp-finmap mathcomp-bigenough ];
+    mathcomp.ssreflect
+    mathcomp.algebra
+    mathcomp-finmap
+    mathcomp-bigenough
+  ];
 
   meta = {
     description = "Coq/SSReflect Library for Monoidal Rings and Multinomials";
@@ -124,12 +167,10 @@ The `overrideCoqDerivation` function lets you easily change arguments to `mkCoqD
 For example, here is how you could locally add a new release of the `multinomials` library, and set the `defaultVersion` to use this release:
 
 ```nix
-coqPackages.lib.overrideCoqDerivation
+coqPackages.lib.overrideCoqDerivation {
-  {
   defaultVersion = "2.0";
   release."2.0".hash = "sha256-czoP11rtrIM7+OLdMisv2EF7n/IbGuwFxHiPtg3qCNM=";
-  }
+} coqPackages.multinomials
-  coqPackages.multinomials
 ```
 
 ### `.overrideAttrs` {#coq-overrideAttrs}
@@ -140,7 +181,9 @@ For instance, here is how you could add some code to be performed in the derivat
 
 ```nix
 coqPackages.multinomials.overrideAttrs (oldAttrs: {
-  postInstall = oldAttrs.postInstall or "" + ''
+  postInstall =
+    oldAttrs.postInstall or ""
+    + ''
       echo "you can do anything you want here"
     '';
 })

doc/languages-frameworks/crystal.section.md

@@ -51,7 +51,10 @@ Additionally you can override the default `crystal build` options (which are cur
 
 ```nix
 {
-  crystalBinaries.mint.options = [ "--release" "--verbose" ];
+  crystalBinaries.mint.options = [
+    "--release"
+    "--verbose"
+  ];
 }
 ```
 

doc/languages-frameworks/cuda.section.md

@@ -12,11 +12,13 @@ compatible are available as well. For example, there can be a
 
 To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional
 ```nix
-{ config
+{
-, cudaSupport ? config.cudaSupport
+  config,
-, cudaPackages ? { }
+  cudaSupport ? config.cudaSupport,
-, ...
+  cudaPackages ? { },
-}: {}
+  ...
+}:
+{ }
 ```
 
 When using `callPackage`, you can choose to pass in a different variant, e.g.
@@ -32,11 +34,15 @@ package set to make it the default. This guarantees you get a consistent package
 set.
 ```nix
 {
-  mypkg = let
+  mypkg =
-    cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
+    let
+      cudaPackages = cudaPackages_11_5.overrideScope (
+        final: prev: {
           cudnn = prev.cudnn_8_3;
-    });
+        }
-  in callPackage { inherit cudaPackages; };
+      );
+    in
+    callPackage { inherit cudaPackages; };
 }
 ```
 

doc/languages-frameworks/cuelang.section.md

@@ -27,13 +27,11 @@ Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validatio
 
 Here is an example:
 ```nix
-pkgs.writeCueValidator
+pkgs.writeCueValidator (pkgs.writeText "schema.cue" ''
-  (pkgs.writeText "schema.cue" ''
   #Def1: {
     field1: string
   }
-  '')
+'') { document = "#Def1"; }
-  { document = "#Def1"; }
 ```
 
 - The first parameter is the Cue schema file.
@@ -43,19 +41,19 @@ pkgs.writeCueValidator
 
 Another example, given the following `validator.nix` :
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 let
-  genericValidator = version:
+  genericValidator =
-  pkgs.writeCueValidator
+    version:
-    (pkgs.writeText "schema.cue" ''
+    pkgs.writeCueValidator (pkgs.writeText "schema.cue" ''
       #Version1: {
         field1: string
       }
       #Version2: #Version1 & {
         field1: "unused"
-      }''
+      }'') { document = "#Version${toString version}"; };
-    )
-    { document = "#Version${toString version}"; };
 in
 {
   validateV1 = genericValidator 1;

doc/languages-frameworks/dart.section.md

@@ -30,7 +30,11 @@ The `dart` commands run can be overridden through `pubGetScript` and `dartCompil
 Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.
 
 ```nix
-{ lib, buildDartApplication, fetchFromGitHub }:
+{
+  lib,
+  buildDartApplication,
+  fetchFromGitHub,
+}:
 
 buildDartApplication rec {
   pname = "dart-sass";

doc/languages-frameworks/dhall.section.md

@@ -100,12 +100,14 @@ let
 
   overlay = self: super: {
     dhallPackages = super.dhallPackages.override (old: {
-      overrides =
+      overrides = self.lib.composeExtensions (old.overrides or (_: _: { })) dhallOverlay;
-        self.lib.composeExtensions (old.overrides or (_: _: {})) dhallOverlay;
     });
   };
 
-  pkgs = import nixpkgs { config = {}; overlays = [ overlay ]; };
+  pkgs = import nixpkgs {
+    config = { };
+    overlays = [ overlay ];
+  };
 
 in
 pkgs
@@ -190,8 +192,7 @@ Dhall overlay like this:
 {
   dhallOverrides = self: super: {
     # Enable source for all Dhall packages
-    buildDhallPackage =
+    buildDhallPackage = args: super.buildDhallPackage (args // { source = true; });
-      args: super.buildDhallPackage (args // { source = true; });
 
     true = self.callPackage ./true.nix { };
   };

doc/languages-frameworks/dotnet.section.md

@@ -26,10 +26,13 @@ with import <nixpkgs> {};
 mkShell {
   name = "dotnet-env";
   packages = [
-    (with dotnetCorePackages; combinePackages [
+    (
+      with dotnetCorePackages;
+      combinePackages [
         sdk_8_0
         sdk_9_0
-    ])
+      ]
+    )
   ];
 }
 ```
@@ -137,11 +140,19 @@ When packaging a new application, you need to fetch its dependencies. Create an
 
 Here is an example `default.nix`, using some of the previously discussed arguments:
 ```nix
-{ lib, buildDotnetModule, dotnetCorePackages, ffmpeg }:
+{
+  lib,
+  buildDotnetModule,
+  dotnetCorePackages,
+  ffmpeg,
+}:
 
 let
-  referencedProject = import ../../bar { /* ... */ };
+  referencedProject = import ../../bar {
-in buildDotnetModule rec {
+    # ...
+  };
+in
+buildDotnetModule rec {
   pname = "someDotnetApplication";
   version = "0.1";
 

doc/languages-frameworks/emscripten.section.md

@@ -44,7 +44,9 @@ One advantage is that when `pkgs.zlib` is updated, it will automatically update
   (old: rec {
     buildInputs = old.buildInputs ++ [ pkg-config ];
     # we need to reset this setting!
-  env = (old.env or { }) // { NIX_CFLAGS_COMPILE = ""; };
+    env = (old.env or { }) // {
+      NIX_CFLAGS_COMPILE = "";
+    };
     configurePhase = ''
       # FIXME: Some tests require writing at $HOME
       HOME=$TMPDIR
@@ -103,8 +105,21 @@ This `xmlmirror` example features an Emscripten package that is defined complete
 pkgs.buildEmscriptenPackage rec {
   name = "xmlmirror";
 
-  buildInputs = [ pkg-config autoconf automake libtool gnumake libxml2 nodejs openjdk json_c ];
+  buildInputs = [
-  nativeBuildInputs = [ pkg-config zlib ];
+    pkg-config
+    autoconf
+    automake
+    libtool
+    gnumake
+    libxml2
+    nodejs
+    openjdk
+    json_c
+  ];
+  nativeBuildInputs = [
+    pkg-config
+    zlib
+  ];
 
   src = pkgs.fetchgit {
     url = "https://gitlab.com/odfplugfest/xmlmirror.git";
@@ -129,7 +144,10 @@ pkgs.buildEmscriptenPackage rec {
     make -f Makefile.emEnv
   '';
 
-  outputs = [ "out" "doc" ];
+  outputs = [
+    "out"
+    "doc"
+  ];
 
   installPhase = ''
     mkdir -p $out/share

doc/languages-frameworks/gnome.section.md

@@ -96,7 +96,12 @@ Given the requirements above, the package expression would become messy quickly:
         --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 ]}"
+        --prefix GI_TYPELIB_PATH : "${
+          lib.makeSearchPath "lib/girepository-1.0" [
+            pango
+            json-glib
+          ]
+        }"
     done
   '';
 }

doc/languages-frameworks/gradle.section.md

@@ -21,7 +21,10 @@ stdenv.mkDerivation (finalAttrs: {
     hash = "sha256-ciKotTHSEcITfQYKFZ6sY2LZnXGChBJy0+eno8B3YHY=";
   };
 
-  nativeBuildInputs = [ gradle makeWrapper ];
+  nativeBuildInputs = [
+    gradle
+    makeWrapper
+  ];
 
   # if the package has dependencies, mitmCache must be set
   mitmCache = gradle.fetchDeps {
@@ -72,11 +75,12 @@ The first is to add the derivation arguments required for getting the
 package. Using the pdftk example above:
 
 ```nix
-{ lib
+{
-, stdenv
+  lib,
-, gradle
+  stdenv,
+  gradle,
   # ...
-, pdftk
+  pdftk,
 }:
 
 stdenv.mkDerivation (finalAttrs: {

doc/languages-frameworks/hare.section.md

@@ -25,7 +25,8 @@ The following attributes are accepted by `hareHook`:
   hareHook,
   lib,
   stdenv,
-}: stdenv.mkDerivation {
+}:
+stdenv.mkDerivation {
   pname = "<name>";
   version = "<version>";
   src = "<src>";

doc/languages-frameworks/haskell.section.md

@@ -590,7 +590,9 @@ that:
 
 ```nix
 # Retrieve nixpkgs impurely from NIX_PATH for now, you can pin it instead, of course.
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 # use the nixpkgs default haskell package set
 pkgs.haskellPackages.callPackage ./my-project.nix { }
@@ -654,7 +656,9 @@ Say our example above depends on `distribution-nixpkgs` and we have a project
 file set up for both, we can add the following `shell.nix` expression:
 
 ```nix
-{ pkgs ? import <nixpkgs> {} }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 pkgs.haskellPackages.shellFor {
   packages = hpkgs: [
@@ -703,7 +707,12 @@ linked to work reliably. You can override the list of supported GHC versions
 with e.g.
 
 ```nix
-pkgs.haskell-language-server.override { supportedGhcVersions = [ "90" "94" ]; }
+pkgs.haskell-language-server.override {
+  supportedGhcVersions = [
+    "90"
+    "94"
+  ];
+}
 ```
 Where all strings `version` are allowed such that
 `haskell.packages.ghc${version}` is an existing package set.
@@ -886,9 +895,7 @@ for this to work.
   derivation:
 
   ```nix
-  pkgs.haskell.lib.overrideCabal
+  pkgs.haskell.lib.overrideCabal (pkgs.haskell.lib.justStaticExecutables my-haskell-package) (drv: {
-    (pkgs.haskell.lib.justStaticExecutables my-haskell-package)
-    (drv: {
     disallowGhcReference = false;
   })
   ```
@@ -906,9 +913,7 @@ for this to work.
   Finally, use `remove-references-to` to delete those store paths from the produced output:
 
   ```nix
-  pkgs.haskell.lib.overrideCabal
+  pkgs.haskell.lib.overrideCabal (pkgs.haskell.lib.justStaticExecutables my-haskell-package) (drv: {
-    (pkgs.haskell.lib.justStaticExecutables my-haskell-package)
-    (drv: {
     postInstall = ''
       ${drv.postInstall or ""}
       remove-references-to -t ${pkgs.haskellPackages.hs-opentelemetry-sdk}
@@ -1122,12 +1127,20 @@ Haskell packages using [import from derivation][import-from-derivation].
 
 ```nix
 # cabal get mtl-2.2.1 && cd mtl-2.2.1 && cabal2nix .
-{ mkDerivation, base, lib, transformers }:
+{
+  mkDerivation,
+  base,
+  lib,
+  transformers,
+}:
 mkDerivation {
   pname = "mtl";
   version = "2.2.1";
   src = ./.;
-  libraryHaskellDepends = [ base transformers ];
+  libraryHaskellDepends = [
+    base
+    transformers
+  ];
   homepage = "http://github.com/ekmett/mtl";
   description = "Monad classes, using functional dependencies";
   license = lib.licenses.bsd3;
@@ -1274,7 +1287,8 @@ in
   # recommended to only use such an overlay if you are enabling profiling on a
   # platform that doesn't by default, because compiling GHC from scratch is
   # quite expensive.
-  (final: prev:
+  (
+    final: prev:
     let
       inherit (final) lib;
     in
@@ -1288,9 +1302,11 @@ in
           };
         };
       };
-  })
+    }
+  )
 
-  (final: prev:
+  (
+    final: prev:
     let
       inherit (final) lib;
       haskellLib = final.haskell.lib.compose;
@@ -1301,7 +1317,11 @@ in
         packages = prev.haskell.packages // {
           ${ghcName} = prev.haskell.packages.${ghcName}.override {
             overrides = hfinal: hprev: {
-            mkDerivation = args: hprev.mkDerivation (args // {
+              mkDerivation =
+                args:
+                hprev.mkDerivation (
+                  args
+                  // {
                     # Since we are forcing our ideas upon mkDerivation, this change will
                     # affect every package in the package set.
                     enableLibraryProfiling = enableProfiling;
@@ -1310,7 +1330,8 @@ in
                     # needs to be enabled for the executable you want to profile. You
                     # can either do this globally or…
                     enableExecutableProfiling = enableProfiling;
-            });
+                  }
+                );
 
               # …only for the package that contains an executable you want to profile.
               # That saves on unnecessary rebuilds for packages that you only depend
@@ -1327,7 +1348,8 @@ in
           };
         };
       };
-  })
+    }
+  )
 ]
 ```
 

doc/languages-frameworks/hy.section.md

@@ -22,10 +22,16 @@ $ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])"
 
 Or if you want to extend your `configuration.nix`:
 ```nix
-{ # ...
+{
+  # ...
 
   environment.systemPackages = with pkgs; [
-    (hy.withPackages (py-packages: with py-packages; [ numpy matplotlib ]))
+    (hy.withPackages (
+      py-packages: with py-packages; [
+        numpy
+        matplotlib
+      ]
+    ))
   ];
 }
 ```

doc/languages-frameworks/idris.section.md

@@ -12,7 +12,12 @@ This however only provides the `prelude` and `base` libraries. To install idris
 
 ```nix
 self: super: {
-  myIdris = with self.idrisPackages; with-packages [ contrib pruviloj ];
+  myIdris =
+    with self.idrisPackages;
+    with-packages [
+      contrib
+      pruviloj
+    ];
 }
 ```
 
@@ -68,11 +73,12 @@ prelude
 As an example of how a Nix expression for an Idris package can be created, here is the one for `idrisPackages.yaml`:
 
 ```nix
-{ lib
+{
-, build-idris-package
+  lib,
-, fetchFromGitHub
+  build-idris-package,
-, contrib
+  fetchFromGitHub,
-, lightyear
+  contrib,
+  lightyear,
 }:
 build-idris-package {
   name = "yaml";
@@ -84,7 +90,10 @@ build-idris-package  {
   # different from its package name here.
   ipkgName = "Yaml";
   # Idris dependencies to provide for the build
-  idrisDeps = [ contrib lightyear ];
+  idrisDeps = [
+    contrib
+    lightyear
+  ];
 
   src = fetchFromGitHub {
     owner = "Heather";
@@ -134,7 +143,11 @@ For example you could set
 
 ```nix
 build-idris-package {
-  idrisBuildOptions = [ "--log" "1" "--verbose" ];
+  idrisBuildOptions = [
+    "--log"
+    "1"
+    "--verbose"
+  ];
 
   # ...
 }

doc/languages-frameworks/idris2.section.md

@@ -9,7 +9,8 @@ Importantly, `buildIdris` does not create a single derivation but rather an attr
 A simple example of a fully packaged library would be the [`LSP-lib`](https://github.com/idris-community/LSP-lib) found in the `idris-community` GitHub organization.
 ```nix
 { fetchFromGitHub, idris2Packages }:
-let lspLibPkg = idris2Packages.buildIdris {
+let
+  lspLibPkg = idris2Packages.buildIdris {
     ipkgName = "lsp-lib";
     src = fetchFromGitHub {
       owner = "idris-community";
@@ -19,17 +20,23 @@ let lspLibPkg = idris2Packages.buildIdris {
     };
     idrisLibraries = [ ];
   };
-in lspLibPkg.library { withSource = true; }
+in
+lspLibPkg.library { withSource = true; }
 ```
 
 The above results in a derivation with the installed library results (with sourcecode).
 
 A slightly more involved example of a fully packaged executable would be the [`idris2-lsp`](https://github.com/idris-community/idris2-lsp) which is an Idris2 language server that uses the `LSP-lib` found above.
 ```nix
-{ callPackage, fetchFromGitHub, idris2Packages }:
+{
+  callPackage,
+  fetchFromGitHub,
+  idris2Packages,
+}:
 
 # Assuming the previous example lives in `lsp-lib.nix`:
-let lspLib = callPackage ./lsp-lib.nix { };
+let
+  lspLib = callPackage ./lsp-lib.nix { };
   inherit (idris2Packages) idris2Api;
   lspPkg = idris2Packages.buildIdris {
     ipkgName = "idris2-lsp";
@@ -39,9 +46,13 @@ let lspLib = callPackage ./lsp-lib.nix { };
       rev = "main";
       hash = "sha256-vQTzEltkx7uelDtXOHc6QRWZ4cSlhhm5ziOqWA+aujk=";
     };
-      idrisLibraries = [idris2Api lspLib];
+    idrisLibraries = [
+      idris2Api
+      lspLib
+    ];
   };
-in lspPkg.executable
+in
+lspPkg.executable
 ```
 
 The above uses the default value of `withSource = false` for the `idris2Api` but could be modified to include that library's source by passing `(idris2Api { withSource = true; })` to `idrisLibraries` instead. `idris2Api` in the above derivation comes built in with `idris2Packages`. This library exposes many of the otherwise internal APIs of the Idris2 compiler.

doc/languages-frameworks/java.section.md

@@ -7,7 +7,9 @@ stdenv.mkDerivation {
   pname = "...";
   version = "...";
 
-  src = fetchurl { /* ... */ };
+  src = fetchurl {
+    # ...
+  };
 
   nativeBuildInputs = [
     ant
@@ -122,7 +124,10 @@ OpenJDK. For instance, to use the GNU Java Compiler:
 
 ```nix
 {
-  nativeBuildInputs = [ gcj ant ];
+  nativeBuildInputs = [
+    gcj
+    ant
+  ];
 }
 ```
 

doc/languages-frameworks/javascript.section.md

@@ -119,8 +119,15 @@ For example, `dat` requires `node-gyp-build`, so we override its expression in [
 ```nix
 {
   dat = prev.dat.override (oldAttrs: {
-      buildInputs = [ final.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
+    buildInputs = [
-      meta = oldAttrs.meta // { broken = since "12"; };
+      final.node-gyp-build
+      pkgs.libtool
+      pkgs.autoconf
+      pkgs.automake
+    ];
+    meta = oldAttrs.meta // {
+      broken = since "12";
+    };
   });
 }
 ```
@@ -185,7 +192,11 @@ It works by utilizing npm's cache functionality -- creating a reproducible cache
 Here's an example:
 
 ```nix
-{ lib, buildNpmPackage, fetchFromGitHub }:
+{
+  lib,
+  buildNpmPackage,
+  fetchFromGitHub,
+}:
 
 buildNpmPackage rec {
   pname = "flood";
@@ -323,7 +334,9 @@ buildNpmPackage {
     npmRoot = ./.;
     fetcherOpts = {
       # Pass 'curlOptsList' to 'pkgs.fetchurl' while fetching 'axios'
-      "node_modules/axios" = { curlOptsList = [ "--verbose" ]; };
+      "node_modules/axios" = {
+        curlOptsList = [ "--verbose" ];
+      };
     };
   };
 
@@ -403,7 +416,7 @@ When packaging an application that includes a `pnpm-lock.yaml`, you need to fetc
   stdenv,
   nodejs,
   # This is pinned as { pnpm = pnpm_9; }
-  pnpm
+  pnpm,
 }:
 
 stdenv.mkDerivation (finalAttrs: {
@@ -690,7 +703,11 @@ To fix this we will specify different versions of build inputs to use, as well a
 mkYarnPackage rec {
   pkgConfig = {
     node-sass = {
-      buildInputs = with final;[ python libsass pkg-config ];
+      buildInputs = with final; [
+        python
+        libsass
+        pkg-config
+      ];
       postInstall = ''
         LIBSASS_EXT=auto yarn --offline run build
         rm build/config.gypi

doc/languages-frameworks/julia.section.md

@@ -28,7 +28,8 @@ For example:
 ```nix
 (julia.withPackages.override {
   precompile = false; # Turn off precompilation
-}) ["Plots"]
+})
+  [ "Plots" ]
 ```
 
 Here's a nice way to run a Julia environment with a shell one-liner:

doc/languages-frameworks/lisp.section.md

@@ -48,7 +48,8 @@ Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
 ```nix
 let
   sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
-in mkShell {
+in
+mkShell {
   packages = [ sbcl' ];
 }
 ```
@@ -188,10 +189,13 @@ let
       hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
     };
   };
-  sbcl' = sbcl.withOverrides (self: super: {
+  sbcl' = sbcl.withOverrides (
+    self: super: {
       inherit alexandria;
-  });
+    }
-in sbcl'.pkgs.alexandria
+  );
+in
+sbcl'.pkgs.alexandria
 ```
 
 ## Overriding package attributes {#lisp-overriding-package-attributes}
@@ -296,6 +300,9 @@ This example wraps CLISP:
 wrapLisp {
   pkg = clisp;
   faslExt = "fas";
-  flags = ["-E" "UTF8"];
+  flags = [
+    "-E"
+    "UTF8"
+  ];
 }
 ```

doc/languages-frameworks/lua.section.md

@@ -29,7 +29,12 @@ Create a file, e.g. `build.nix`, with the following expression
 ```nix
 with import <nixpkgs> { };
 
-lua5_2.withPackages (ps: with ps; [ busted luafilesystem ])
+lua5_2.withPackages (
+  ps: with ps; [
+    busted
+    luafilesystem
+  ]
+)
 ```
 
 and install it in your profile with
@@ -46,10 +51,17 @@ If you prefer to, you could also add the environment as a package override to th
 using `config.nix`,
 
 ```nix
-{ # ...
+{
+  # ...
 
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
-    myLuaEnv = lua5_2.withPackages (ps: with ps; [ busted luafilesystem ]);
+    pkgs: with pkgs; {
+      myLuaEnv = lua5_2.withPackages (
+        ps: with ps; [
+          busted
+          luafilesystem
+        ]
+      );
     };
 }
 ```
@@ -67,10 +79,16 @@ the `nixpkgs` channel was used.
 For the sake of completeness, here's another example how to install the environment system-wide.
 
 ```nix
-{ # ...
+{
+  # ...
 
   environment.systemPackages = with pkgs; [
-    (lua.withPackages(ps: with ps; [ busted luafilesystem ]))
+    (lua.withPackages (
+      ps: with ps; [
+        busted
+        luafilesystem
+      ]
+    ))
   ];
 }
 ```
@@ -80,8 +98,7 @@ For the sake of completeness, here's another example how to install the environm
 Use the following overlay template:
 
 ```nix
-final: prev:
+final: prev: {
-{
 
   lua = prev.lua.override {
     packageOverrides = luaself: luaprev: {
@@ -159,7 +176,11 @@ within a `toLuaModule` call, for instance
 
 ```nix
 {
-  mynewlib = toLuaModule ( stdenv.mkDerivation { /* ... */ });
+  mynewlib = toLuaModule (
+    stdenv.mkDerivation {
+      # ...
+    }
+  );
 }
 ```
 
@@ -198,12 +219,19 @@ The following is an example:
       hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
     };
     disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
-    propagatedBuildInputs = [ bit32 lua std_normalize ];
+    propagatedBuildInputs = [
+      bit32
+      lua
+      std_normalize
+    ];
 
     meta = {
       homepage = "https://github.com/luaposix/luaposix/";
       description = "Lua bindings for POSIX";
-      maintainers = with lib.maintainers; [ vyp lblasc ];
+      maintainers = with lib.maintainers; [
+        vyp
+        lblasc
+      ];
       license.fullName = "MIT/X11";
     };
   };

doc/languages-frameworks/maven.section.md

@@ -9,7 +9,13 @@ The following provides a list of common patterns with how to package a Maven pro
 Consider the following package:
 
 ```nix
-{ lib, fetchFromGitHub, jre, makeWrapper, maven }:
+{
+  lib,
+  fetchFromGitHub,
+  jre,
+  makeWrapper,
+  maven,
+}:
 
 maven.buildMavenPackage rec {
   pname = "jd-cli";
@@ -246,7 +252,9 @@ This file is then given to the `buildMaven` function, and it returns 2 attribute
 Here is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/build-maven-repository.nix) of building the Maven repository
 
 ```nix
-{ pkgs ? import <nixpkgs> { } }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 with pkgs;
 (buildMaven ./project-info.json).repo
 ```
@@ -283,7 +291,11 @@ Traditionally the Maven repository is at `~/.m2/repository`. We will override th
 :::
 
 ```nix
-{ lib, stdenv, maven }:
+{
+  lib,
+  stdenv,
+  maven,
+}:
 stdenv.mkDerivation {
   name = "maven-repository";
   buildInputs = [ maven ];
@@ -337,10 +349,16 @@ If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a str
 Regardless of which strategy is chosen above, the step to build the derivation is the same.
 
 ```nix
-{ stdenv, maven, callPackage }:
+{
+  stdenv,
+  maven,
+  callPackage,
+}:
 # pick a repository derivation, here we will use buildMaven
-let repository = callPackage ./build-maven-repository.nix { };
+let
-in stdenv.mkDerivation rec {
+  repository = callPackage ./build-maven-repository.nix { };
+in
+stdenv.mkDerivation rec {
   pname = "maven-demo";
   version = "1.0";
 
@@ -393,15 +411,21 @@ We will read the Maven repository and flatten it to a single list. This list wil
 We make sure to provide this classpath to the `makeWrapper`.
 
 ```nix
-{ stdenv, maven, callPackage, makeWrapper, jre }:
+{
+  stdenv,
+  maven,
+  callPackage,
+  makeWrapper,
+  jre,
+}:
 let
   repository = callPackage ./build-maven-repository.nix { };
-in stdenv.mkDerivation rec {
+in
+stdenv.mkDerivation rec {
   pname = "maven-demo";
   version = "1.0";
 
-  src = builtins.fetchTarball
+  src = builtins.fetchTarball "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
-    "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
   nativeBuildInputs = [ makeWrapper ];
   buildInputs = [ maven ];
 
@@ -471,15 +495,22 @@ Main-Class: Main
 We will modify the derivation above to add a symlink to our repository so that it's accessible to our JAR during the `installPhase`.
 
 ```nix
-{ stdenv, maven, callPackage, makeWrapper, jre }:
+{
+  stdenv,
+  maven,
+  callPackage,
+  makeWrapper,
+  jre,
+}:
 # pick a repository derivation, here we will use buildMaven
-let repository = callPackage ./build-maven-repository.nix { };
+let
-in stdenv.mkDerivation rec {
+  repository = callPackage ./build-maven-repository.nix { };
+in
+stdenv.mkDerivation rec {
   pname = "maven-demo";
   version = "1.0";
 
-  src = builtins.fetchTarball
+  src = builtins.fetchTarball "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
-    "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
   nativeBuildInputs = [ makeWrapper ];
   buildInputs = [ maven ];
 

doc/languages-frameworks/nim.section.md

@@ -7,7 +7,11 @@ Nim programs are built using a lockfile and either `buildNimPackage` or `buildNi
 
 The following example shows a Nim program that depends only on Nim libraries:
 ```nix
-{ lib, buildNimPackage, fetchFromGitHub }:
+{
+  lib,
+  buildNimPackage,
+  fetchFromGitHub,
+}:
 
 buildNimPackage (finalAttrs: {
   pname = "ttop";
@@ -91,7 +95,9 @@ The `buildNimPackage` and `buildNimSbom` functions generate flags and additional
 ```nix
 pkgs.nitter.overrideNimAttrs {
   # using a different source which has different dependencies from the standard package
-  src = pkgs.fetchFromGithub { /* … */ };
+  src = pkgs.fetchFromGithub {
+    # …
+  };
   # new lock file generated from the source
   lockFile = ./custom-lock.json;
 }
@@ -104,21 +110,25 @@ The default overrides are maintained as the top-level `nimOverrides` attrset at
 
 For example, to propagate a dependency on SDL2 for lockfiles that select the Nim `sdl2` library, an overlay is added to the set in the `nim-overrides.nix` file:
 ```nix
-{ lib
+{
-/* … */
+  lib,
-, SDL2
+  # …
-/* … */
+  SDL2,
+# …
 }:
 
 {
-  /* … */
+  # …
   sdl2 =
     lockAttrs:
-    { buildInputs ? [ ], ... }:
+    {
+      buildInputs ? [ ],
+      ...
+    }:
     {
       buildInputs = buildInputs ++ [ SDL2 ];
     };
-  /* … */
+  # …
 }
 ```
 
@@ -132,22 +142,28 @@ The `nimOverrides` attrset makes it possible to modify overrides in a few differ
 
 Override a package internal to its definition:
 ```nix
-{ lib, buildNimPackage, nimOverrides, libressl }:
+{
+  lib,
+  buildNimPackage,
+  nimOverrides,
+  libressl,
+}:
 
 let
   buildNimPackage' = buildNimPackage.override {
     nimOverrides = nimOverrides.override { openssl = libressl; };
   };
-in buildNimPackage' (finalAttrs: {
+in
+buildNimPackage' (finalAttrs: {
   pname = "foo";
   # …
 })
-
 ```
 
 Override a package externally:
 ```nix
-{ pkgs }: {
+{ pkgs }:
+{
   foo = pkgs.foo.override {
     buildNimPackage = pkgs.buildNimPackage.override {
       nimOverrides = pkgs.nimOverrides.override { openssl = libressl; };

doc/languages-frameworks/ocaml.section.md

@@ -18,7 +18,12 @@ let
 in
 pkgs.mkShell {
   # build tools
-  nativeBuildInputs = with ocamlPackages; [ ocaml findlib dune_2 ocaml-lsp ];
+  nativeBuildInputs = with ocamlPackages; [
+    ocaml
+    findlib
+    dune_2
+    ocaml-lsp
+  ];
   # dependencies
   buildInputs = with ocamlPackages; [ ocamlgraph ];
 }
@@ -58,7 +63,8 @@ Here is a simple package example.
   generates.
 
 ```nix
-{ lib,
+{
+  lib,
   fetchFromGitHub,
   buildDunePackage,
   ocaml,
@@ -66,7 +72,8 @@ Here is a simple package example.
   alcotest,
   result,
   bigstringaf,
-  ppx_let }:
+  ppx_let,
+}:
 
 buildDunePackage rec {
   pname = "angstrom";
@@ -81,9 +88,15 @@ buildDunePackage rec {
     hash = "sha256-MK8o+iPGANEhrrTc1Kz9LBilx2bDPQt7Pp5P2libucI=";
   };
 
-  checkInputs = [ alcotest ppx_let ];
+  checkInputs = [
+    alcotest
+    ppx_let
+  ];
   buildInputs = [ ocaml-syntax-shims ];
-  propagatedBuildInputs = [ bigstringaf result ];
+  propagatedBuildInputs = [
+    bigstringaf
+    result
+  ];
   doCheck = lib.versionAtLeast ocaml.version "4.05";
 
   meta = {
@@ -98,7 +111,11 @@ buildDunePackage rec {
 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.
 
 ```nix
-{ lib, fetchurl, buildDunePackage }:
+{
+  lib,
+  fetchurl,
+  buildDunePackage,
+}:
 
 buildDunePackage rec {
   pname = "wtf8";

doc/languages-frameworks/octave.section.md

@@ -39,7 +39,9 @@ $ nix-shell -p 'octave.withPackages (ps: with ps; [ symbolic ])'
 This will also work in a `shell.nix` file.
 
 ```nix
-{ pkgs ? import <nixpkgs> { }}:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 pkgs.mkShell {
   nativeBuildInputs = with pkgs; [

doc/languages-frameworks/perl.section.md

@@ -51,7 +51,10 @@ Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL defin
 ```nix
 {
   foo = import ../path/to/foo.nix {
-    inherit stdenv fetchurl /* ... */;
+    inherit
+      stdenv
+      fetchurl # ...
+      ;
     inherit (perlPackages) ClassC3;
   };
 }
@@ -74,7 +77,11 @@ So what does `buildPerlPackage` do? It does the following:
 `buildPerlPackage` is built on top of `stdenv`, so everything can be customised in the usual way. For instance, the `BerkeleyDB` module has a `preConfigure` hook to generate a configuration file used by `Makefile.PL`:
 
 ```nix
-{ buildPerlPackage, fetchurl, db }:
+{
+  buildPerlPackage,
+  fetchurl,
+  db,
+}:
 
 buildPerlPackage rec {
   pname = "BerkeleyDB";
@@ -104,7 +111,10 @@ Dependencies on other Perl packages can be specified in the `buildInputs` and `p
       hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
     };
     propagatedBuildInputs = [
-      ClassC3 ClassInspector TestException MROCompat
+      ClassC3
+      ClassInspector
+      TestException
+      MROCompat
     ];
   };
 }
@@ -113,7 +123,13 @@ Dependencies on other Perl packages can be specified in the `buildInputs` and `p
 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:
 
 ```nix
-{ lib, stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
+{
+  lib,
+  stdenv,
+  buildPerlPackage,
+  fetchurl,
+  shortenPerlShebang,
+}:
 
 {
   ImageExifTool = buildPerlPackage {

doc/languages-frameworks/php.section.md

@@ -45,24 +45,30 @@ extensions. For example, a PHP package with all default extensions and
 ImageMagick enabled:
 
 ```nix
-php.withExtensions ({ enabled, all }:
+php.withExtensions ({ enabled, all }: enabled ++ [ all.imagick ])
-  enabled ++ [ all.imagick ])
 ```
 
 To exclude some, but not all, of the default extensions, you can
 filter the `enabled` list like this:
 
 ```nix
-php.withExtensions ({ enabled, all }:
+php.withExtensions (
-  (lib.filter (e: e != php.extensions.opcache) enabled)
+  { enabled, all }: (lib.filter (e: e != php.extensions.opcache) enabled) ++ [ all.imagick ]
-  ++ [ all.imagick ])
+)
 ```
 
 To build your list of extensions from the ground up, you can
 ignore `enabled`:
 
 ```nix
-php.withExtensions ({ all, ... }: with all; [ imagick opcache ])
+php.withExtensions (
+  { all, ... }:
+  with all;
+  [
+    imagick
+    opcache
+  ]
+)
 ```
 
 `php.withExtensions` provides extensions by wrapping a minimal php
@@ -82,7 +88,13 @@ and ImageMagick extensions enabled, and `memory_limit` set to `256M`:
 
 ```nix
 php.buildEnv {
-  extensions = { all, ... }: with all; [ imagick opcache ];
+  extensions =
+    { all, ... }:
+    with all;
+    [
+      imagick
+      opcache
+    ];
   extraConfig = "memory_limit=256M";
 }
 ```
@@ -94,8 +106,16 @@ follows:
 
 ```nix
 let
-  myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
+  myPhp = php.withExtensions (
-in {
+    { all, ... }:
+    with all;
+    [
+      imagick
+      opcache
+    ]
+  );
+in
+{
   services.phpfpm.pools."foo".phpPackage = myPhp;
 }
 ```
@@ -103,10 +123,17 @@ in {
 ```nix
 let
   myPhp = php.buildEnv {
-    extensions = { all, ... }: with all; [ imagick opcache ];
+    extensions =
+      { all, ... }:
+      with all;
+      [
+        imagick
+        opcache
+      ];
     extraConfig = "memory_limit=256M";
   };
-in {
+in
+{
   services.phpfpm.pools."foo".phpPackage = myPhp;
 }
 ```
@@ -132,9 +159,14 @@ won't work with that project unless those extensions are loaded.
 Example of building `composer` with additional extensions:
 
 ```nix
-(php.withExtensions ({ all, enabled }:
+(php.withExtensions (
-  enabled ++ (with all; [ imagick redis ]))
+  { all, enabled }:
-).packages.composer
+  enabled
+  ++ (with all; [
+    imagick
+    redis
+  ])
+)).packages.composer
 ```
 
 ### Overriding PHP packages {#ssec-php-user-guide-overriding-packages}
@@ -235,9 +267,13 @@ php.buildComposerProject (finalAttrs: {
 
   # PHP version containing the `ast` extension enabled
   php = php.buildEnv {
-    extensions = ({ enabled, all }: enabled ++ (with all; [
+    extensions = (
+      { enabled, all }:
+      enabled
+      ++ (with all; [
         ast
-    ]));
+      ])
+    );
   };
 
   # The composer vendor hash
@@ -259,9 +295,14 @@ Here's a working code example to build a PHP library using `mkDerivation` and
 separate functions and hooks:
 
 ```nix
-{ stdenvNoCC, fetchFromGitHub, php }:
+{
+  stdenvNoCC,
+  fetchFromGitHub,
+  php,
+}:
 
-stdenvNoCC.mkDerivation (finalAttrs:
+stdenvNoCC.mkDerivation (
+  finalAttrs:
   let
     src = fetchFromGitHub {
       owner = "git-owner";
@@ -269,7 +310,8 @@ let
       rev = finalAttrs.version;
       hash = "sha256-VcQRSss2dssfkJ+iUb5qT+FJ10GHiFDzySigcmuVI+8=";
     };
-in {
+  in
+  {
     inherit src;
     pname = "php-app";
     version = "1.0.0";
@@ -292,5 +334,6 @@ in {
       # The composer vendor hash
       vendorHash = "sha256-86s/F+/5cBAwBqZ2yaGRM5rTGLmou5//aLRK5SA0WiQ=";
     };
-})
+  }
+)
 ```

doc/languages-frameworks/pkg-config.section.md

@@ -17,9 +17,12 @@ A good example of all these things is miniz:
 { pkg-config, testers, ... }:
 
 stdenv.mkDerivation (finalAttrs: {
-  /* ... */
+  # ...
 
-  nativeBuildInputs = [ pkg-config validatePkgConfig ];
+  nativeBuildInputs = [
+    pkg-config
+    validatePkgConfig
+  ];
 
   passthru.tests.pkg-config = testers.hasPkgConfigModules {
     package = finalAttrs.finalPackage;
@@ -27,7 +30,7 @@ stdenv.mkDerivation (finalAttrs: {
   };
 
   meta = {
-    /* ... */
+    # ...
     pkgConfigModules = [ "miniz" ];
   };
 })

doc/languages-frameworks/python.section.md

@@ -78,23 +78,24 @@ using setup hooks.
 The following is an example:
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
+  fetchPypi,
 
   # build-system
-, setuptools
+  setuptools,
-, setuptools-scm
+  setuptools-scm,
 
   # dependencies
-, attrs
+  attrs,
-, pluggy
+  pluggy,
-, py
+  py,
-, setuptools
+  setuptools,
-, six
+  six,
 
   # tests
-, hypothesis
+  hypothesis,
 }:
 
 buildPythonPackage rec {
@@ -134,7 +135,12 @@ buildPythonPackage rec {
     description = "Framework for writing tests";
     homepage = "https://github.com/pytest-dev/pytest";
     license = lib.licenses.mit;
-    maintainers = with lib.maintainers; [ domenkozar lovek323 madjar lsix ];
+    maintainers = with lib.maintainers; [
+      domenkozar
+      lovek323
+      madjar
+      lsix
+    ];
   };
 }
 ```
@@ -233,8 +239,10 @@ the overrides for packages in the package set.
 ```nix
 with import <nixpkgs> { };
 
-(let
+(
-  python = let
+  let
+    python =
+      let
         packageOverrides = self: super: {
           pandas = super.pandas.overridePythonAttrs (old: rec {
             version = "0.19.1";
@@ -245,9 +253,15 @@ with import <nixpkgs> {};
             };
           });
         };
-  in pkgs.python3.override {inherit packageOverrides; self = python;};
+      in
+      pkgs.python3.override {
+        inherit packageOverrides;
+        self = python;
+      };
 
-in python.withPackages(ps: [ ps.blaze ])).env
+  in
+  python.withPackages (ps: [ ps.blaze ])
+).env
 ```
 
 The next example shows a non trivial overriding of the `blas` implementation to
@@ -258,12 +272,16 @@ be used through out all of the Python package set:
   python3MyBlas = pkgs.python3.override {
     packageOverrides = self: super: {
       # We need toPythonModule for the package set to evaluate this
-      blas = super.toPythonModule(super.pkgs.blas.override {
+      blas = super.toPythonModule (
+        super.pkgs.blas.override {
           blasProvider = super.pkgs.mkl;
-      });
+        }
-      lapack = super.toPythonModule(super.pkgs.lapack.override {
+      );
+      lapack = super.toPythonModule (
+        super.pkgs.lapack.override {
           lapackProvider = super.pkgs.mkl;
-      });
+        }
+      );
     };
   };
 }
@@ -290,9 +308,10 @@ called with `callPackage` and passed `python3` or `python3Packages` (possibly
 specifying an interpreter version), like this:
 
 ```nix
-{ lib
+{
-, python3Packages
+  lib,
-, fetchPypi
+  python3Packages,
+  fetchPypi,
 }:
 
 python3Packages.buildPythonApplication rec {
@@ -356,10 +375,12 @@ modifications.
 
 ```nix
 {
-  opencv = toPythonModule (pkgs.opencv.override {
+  opencv = toPythonModule (
+    pkgs.opencv.override {
       enablePython = true;
       pythonPackages = self;
-  });
+    }
+  );
 }
 ```
 
@@ -395,7 +416,9 @@ The `build-system`'s provided will instead become runtime dependencies of the ed
 Note that overriding packages deeper in the dependency graph _can_ work, but it's not the primary use case and overriding existing packages can make others break in unexpected ways.
 
 ```nix
-{ pkgs ? import <nixpkgs> { } }:
+{
+  pkgs ? import <nixpkgs> { },
+}:
 
 let
   pyproject = pkgs.lib.importTOML ./pyproject.toml;
@@ -420,7 +443,8 @@ let
 
   pythonEnv = myPython.withPackages (ps: [ ps.my-editable ]);
 
-in pkgs.mkShell {
+in
+pkgs.mkShell {
   packages = [ pythonEnv ];
 }
 ```
@@ -507,10 +531,12 @@ thus be also written like this:
 ```nix
 with import <nixpkgs> { };
 
-(python3.withPackages (ps: with ps; [
+(python3.withPackages (
+  ps: with ps; [
     numpy
     requests
-])).env
+  ]
+)).env
 ```
 
 In contrast to [`python.buildEnv`](#python.buildenv-function), [`python.withPackages`](#python.withpackages-function) does not support the
@@ -759,10 +785,12 @@ in an environment. We can add a `shell.nix` file describing our dependencies:
 
 ```nix
 with import <nixpkgs> { };
-(python312.withPackages (ps: with ps; [
+(python312.withPackages (
+  ps: with ps; [
     numpy
     toolz
-])).env
+  ]
+)).env
 ```
 
 And then at the command line, just typing `nix-shell` produces the same
@@ -791,7 +819,8 @@ let
     ps.numpy
     ps.toolz
   ]);
-in mkShell {
+in
+mkShell {
   packages = [
     pythonEnv
 
@@ -868,10 +897,16 @@ For the sake of completeness, here's how to install the environment system-wide
 on NixOS.
 
 ```nix
-{ # ...
+{
+  # ...
 
   environment.systemPackages = with pkgs; [
-    (python310.withPackages(ps: with ps; [ numpy toolz ]))
+    (python310.withPackages (
+      ps: with ps; [
+        numpy
+        toolz
+      ]
+    ))
   ];
 }
 ```
@@ -891,10 +926,11 @@ building Python libraries is [`buildPythonPackage`](#buildpythonpackage-function
 `toolz` package.
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
-, setuptools
+  fetchPypi,
+  setuptools,
 }:
 
 buildPythonPackage rec {
@@ -954,7 +990,8 @@ and adds it along with a `numpy` package to a Python environment.
 ```nix
 with import <nixpkgs> { };
 
-( let
+(
+  let
     my_toolz = python312.pkgs.buildPythonPackage rec {
       pname = "toolz";
       version = "0.10.0";
@@ -979,10 +1016,13 @@ with import <nixpkgs> {};
       };
     };
 
-  in python312.withPackages (ps: with ps; [
+  in
+  python312.withPackages (
+    ps: with ps; [
       numpy
       my_toolz
-  ])
+    ]
+  )
 ).env
 ```
 
@@ -1014,18 +1054,21 @@ The following example shows which arguments are given to [`buildPythonPackage`](
 order to build [`datashape`](https://github.com/blaze/datashape).
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
+  fetchPypi,
 
   # build dependencies
-, setuptools
+  setuptools,
 
   # dependencies
-, numpy, multipledispatch, python-dateutil
+  numpy,
+  multipledispatch,
+  python-dateutil,
 
   # tests
-, pytestCheckHook
+  pytestCheckHook,
 }:
 
 buildPythonPackage rec {
@@ -1072,12 +1115,13 @@ Python bindings to `libxml2` and `libxslt`. These libraries are only required
 when building the bindings and are therefore added as [`buildInputs`](#var-stdenv-buildInputs).
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
-, setuptools
+  fetchPypi,
-, libxml2
+  setuptools,
-, libxslt
+  libxml2,
+  libxslt,
 }:
 
 buildPythonPackage rec {
@@ -1128,19 +1172,20 @@ The bindings don't expect to find each of them in a different folder, and
 therefore we have to set `LDFLAGS` and `CFLAGS`.
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
+  fetchPypi,
 
   # build dependencies
-, setuptools
+  setuptools,
 
   # dependencies
-, fftw
+  fftw,
-, fftwFloat
+  fftwFloat,
-, fftwLongDouble
+  fftwLongDouble,
-, numpy
+  numpy,
-, scipy
+  scipy,
 }:
 
 buildPythonPackage rec {
@@ -1182,7 +1227,10 @@ buildPythonPackage rec {
     changelog = "https://github.com/pyFFTW/pyFFTW/releases/tag/v${version}";
     description = "Pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
     homepage = "http://hgomersall.github.com/pyFFTW";
-    license = with lib.licenses; [ bsd2 bsd3 ];
+    license = with lib.licenses; [
+      bsd2
+      bsd3
+    ];
   };
 }
 ```
@@ -1360,14 +1408,17 @@ This is especially helpful to select tests or specify flags conditionally:
 
 ```nix
 {
-  disabledTests = [
+  disabledTests =
+    [
       # touches network
       "download"
       "update"
-  ] ++ lib.optionals (pythonAtLeast "3.8") [
+    ]
+    ++ lib.optionals (pythonAtLeast "3.8") [
       # broken due to python3.8 async changes
       "async"
-  ] ++ lib.optionals stdenv.buildPlatform.isDarwin [
+    ]
+    ++ lib.optionals stdenv.buildPlatform.isDarwin [
       # can fail when building with other packages
       "socket"
     ];
@@ -1495,7 +1546,9 @@ automatically add `pythonRelaxDepsHook` if either `pythonRelaxDeps` or
   ];
 
   unittestFlags = [
-    "-s" "tests" "-v"
+    "-s"
+    "tests"
+    "-v"
   ];
 }
 ```
@@ -1576,10 +1629,11 @@ Let's split the package definition from the environment definition.
 We first create a function that builds `toolz` in `~/path/to/toolz/release.nix`
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, fetchPypi
+  buildPythonPackage,
-, setuptools
+  fetchPypi,
+  setuptools,
 }:
 
 buildPythonPackage rec {
@@ -1611,11 +1665,13 @@ It takes an argument [`buildPythonPackage`](#buildpythonpackage-function). We no
 ```nix
 with import <nixpkgs> { };
 
-( let
+(
+  let
     toolz = callPackage /path/to/toolz/release.nix {
       buildPythonPackage = python3Packages.buildPythonPackage;
     };
-  in python3.withPackages (ps: [
+  in
+  python3.withPackages (ps: [
     ps.numpy
     toolz
   ])
@@ -1645,18 +1701,25 @@ example we rename the `pandas` package and build it.
 ```nix
 with import <nixpkgs> { };
 
-(let
+(
-  python = let
+  let
+    python =
+      let
         packageOverrides = self: super: {
-      pandas = super.pandas.overridePythonAttrs(old: {name="foo";});
+          pandas = super.pandas.overridePythonAttrs (old: {
+            name = "foo";
+          });
         };
-  in pkgs.python310.override {
+      in
+      pkgs.python310.override {
         inherit packageOverrides;
       };
 
-in python.withPackages (ps: [
+  in
+  python.withPackages (ps: [
     ps.pandas
-])).env
+  ])
+).env
 ```
 
 Using `nix-build` on this expression will build an environment that contains the
@@ -1672,13 +1735,16 @@ the updated `scipy` version.
 ```nix
 with import <nixpkgs> { };
 
-( let
+(
+  let
     packageOverrides = self: super: {
       scipy = super.scipy_0_17;
     };
-  in (pkgs.python310.override {
+  in
+  (pkgs.python310.override {
     inherit packageOverrides;
-  }).withPackages (ps: [
+  }).withPackages
+    (ps: [
       ps.blaze
     ])
 ).env
@@ -1693,14 +1759,21 @@ If you want the whole of Nixpkgs to use your modifications, then you can use
 ```nix
 let
   pkgs = import <nixpkgs> { };
-  newpkgs = import pkgs.path { overlays = [ (self: super: {
+  newpkgs = import pkgs.path {
-    python310 = let
+    overlays = [
+      (self: super: {
+        python310 =
+          let
             packageOverrides = python-self: python-super: {
               numpy = python-super.numpy_1_18;
             };
-    in super.python310.override {inherit packageOverrides;};
+          in
-  } ) ]; };
+          super.python310.override { inherit packageOverrides; };
-in newpkgs.inkscape
+      })
+    ];
+  };
+in
+newpkgs.inkscape
 ```
 
 ### `python setup.py bdist_wheel` cannot create .whl {#python-setup.py-bdist_wheel-cannot-create-.whl}
@@ -1790,7 +1863,8 @@ with import <nixpkgs> { };
 
 let
   pythonPackages = python3Packages;
-in pkgs.mkShell rec {
+in
+pkgs.mkShell rec {
   name = "impurePythonEnv";
   venvDir = "./.venv";
   buildInputs = [
@@ -1845,7 +1919,8 @@ with import <nixpkgs> { };
 let
   venvDir = "./.venv";
   pythonPackages = python3Packages;
-in pkgs.mkShell rec {
+in
+pkgs.mkShell rec {
   name = "impurePythonEnv";
   buildInputs = [
     pythonPackages.python
@@ -1957,13 +2032,11 @@ The following overlay overrides the call to [`buildPythonPackage`](#buildpythonp
 ```nix
 final: prev: {
   pythonPackagesExtensions = prev.pythonPackagesExtensions ++ [
-    (
+    (python-final: python-prev: {
-      python-final: python-prev: {
       foo = python-prev.foo.overridePythonAttrs (oldAttrs: {
         # ...
       });
-      }
+    })
-    )
   ];
 }
 ```
@@ -1995,7 +2068,8 @@ let
     reproducibleBuild = false;
     self = mypython;
   };
-in mypython
+in
+mypython
 ```
 
 ### How to add optional dependencies? {#python-optional-dependencies}

doc/languages-frameworks/qt.section.md

@@ -64,7 +64,11 @@ and then create wrappers manually in `fixupPhase`, using `wrapQtApp`, which itse
 The `makeWrapper` arguments required for Qt are also exposed in the environment as `$qtWrapperArgs`.
 
 ```nix
-{ stdenv, lib, wrapQtAppsHook }:
+{
+  stdenv,
+  lib,
+  wrapQtAppsHook,
+}:
 
 stdenv.mkDerivation {
   # ...

doc/languages-frameworks/r.section.md

@@ -7,7 +7,11 @@ use by adding the following snippet to your $HOME/.config/nixpkgs/config.nix fil
 
 ```nix
 {
-    packageOverrides = super: let self = super.pkgs; in
+  packageOverrides =
+    super:
+    let
+      self = super.pkgs;
+    in
     {
 
       rEnv = super.rWrapper.override {
@@ -60,7 +64,11 @@ environment, see `rstudioWrapper`, which functions similarly to
 
 ```nix
 {
-    packageOverrides = super: let self = super.pkgs; in
+  packageOverrides =
+    super:
+    let
+      self = super.pkgs;
+    in
     {
 
       rstudioEnv = super.rstudioWrapper.override {
@@ -81,13 +89,17 @@ Alternatively, you can create a self-contained `shell.nix` without the need to
 modify any configuration files:
 
 ```nix
-{ pkgs ? import <nixpkgs> {}
+{
+  pkgs ? import <nixpkgs> { },
 }:
 
 pkgs.rstudioWrapper.override {
-  packages = with pkgs.rPackages; [ dplyr ggplot2 reshape2 ];
+  packages = with pkgs.rPackages; [
+    dplyr
+    ggplot2
+    reshape2
+  ];
 }
-
 ```
 
 Executing `nix-shell` will then drop you into an environment equivalent to the

doc/languages-frameworks/ruby.section.md

@@ -37,7 +37,12 @@ Say we want to have Ruby, `nokogori`, and `pry`. Consider a `shell.nix` file wit
 
 ```nix
 with import <nixpkgs> { };
-ruby.withPackages (ps: with ps; [ nokogiri pry ])
+ruby.withPackages (
+  ps: with ps; [
+    nokogiri
+    pry
+  ]
+)
 ```
 
 What's happening here?
@@ -107,7 +112,13 @@ let
     name = "gems-for-some-project";
     gemdir = ./.;
   };
-in mkShell { packages = [ gems gems.wrappedRuby ]; }
+in
+mkShell {
+  packages = [
+    gems
+    gems.wrappedRuby
+  ];
+}
 ```
 
 With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.
@@ -118,7 +129,12 @@ One common issue that you might have is that you have Ruby, but also `bundler` i
 
 ```nix
 # ...
-mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
+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:
@@ -148,41 +164,54 @@ Two places that allow this modification are the `ruby` derivation, or `bundlerEn
 Here's the `ruby` one:
 
 ```nix
-{ pg_version ? "10", pkgs ? import <nixpkgs> { } }:
+{
+  pg_version ? "10",
+  pkgs ? import <nixpkgs> { },
+}:
 let
   myRuby = pkgs.ruby.override {
     defaultGemConfig = pkgs.defaultGemConfig // {
       pg = attrs: {
-        buildFlags =
+        buildFlags = [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];
-        [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];
       };
     };
   };
-in myRuby.withPackages (ps: with ps; [ pg ])
+in
+myRuby.withPackages (ps: with ps; [ pg ])
 ```
 
 And an example with `bundlerEnv`:
 
 ```nix
-{ pg_version ? "10", pkgs ? import <nixpkgs> { } }:
+{
+  pg_version ? "10",
+  pkgs ? import <nixpkgs> { },
+}:
 let
   gems = pkgs.bundlerEnv {
     name = "gems-for-some-project";
     gemdir = ./.;
     gemConfig = pkgs.defaultGemConfig // {
       pg = attrs: {
-        buildFlags =
+        buildFlags = [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];
-        [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];
       };
     };
   };
-in mkShell { buildInputs = [ gems gems.wrappedRuby ]; }
+in
+mkShell {
+  buildInputs = [
+    gems
+    gems.wrappedRuby
+  ];
+}
 ```
 
 And finally via overlays:
 
 ```nix
-{ pg_version ? "10" }:
+{
+  pg_version ? "10",
+}:
 let
   pkgs = import <nixpkgs> {
     overlays = [
@@ -197,7 +226,8 @@ let
       })
     ];
   };
-in pkgs.ruby.withPackages (ps: with ps; [ pg ])
+in
+pkgs.ruby.withPackages (ps: with ps; [ pg ])
 ```
 
 Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:
@@ -278,7 +308,14 @@ Of course you could also make a custom `gemConfig` if you know exactly how to pa
 Here's another example:
 
 ```nix
-{ lib, bundlerApp, makeWrapper, git, gnutar, gzip }:
+{
+  lib,
+  bundlerApp,
+  makeWrapper,
+  git,
+  gnutar,
+  gzip,
+}:
 
 bundlerApp {
   pname = "r10k";
@@ -288,7 +325,13 @@ bundlerApp {
   nativeBuildInputs = [ makeWrapper ];
 
   postBuild = ''
-    wrapProgram $out/bin/r10k --prefix PATH : ${lib.makeBinPath [ git gnutar gzip ]}
+    wrapProgram $out/bin/r10k --prefix PATH : ${
+      lib.makeBinPath [
+        git
+        gnutar
+        gzip
+      ]
+    }
   '';
 }
 ```

doc/languages-frameworks/rust.section.md

@@ -22,7 +22,11 @@ or use [community maintained Rust toolchains](#using-community-maintained-rust-t
 Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
 
 ```nix
-{ lib, fetchFromGitHub, rustPlatform }:
+{
+  lib,
+  fetchFromGitHub,
+  rustPlatform,
+}:
 
 rustPlatform.buildRustPackage rec {
   pname = "ripgrep";
@@ -151,9 +155,11 @@ rustPlatform.buildRustPackage {
   pname = "myproject";
   version = "1.0.0";
 
-  cargoLock = let
+  cargoLock =
+    let
       fixupLockFile = path: f (builtins.readFile path);
-  in {
+    in
+    {
       lockFileContents = fixupLockFile ./Cargo.lock;
     };
 
@@ -234,7 +240,10 @@ rustPlatform.buildRustPackage rec {
   version = "1.0.0";
 
   buildNoDefaultFeatures = true;
-  buildFeatures = [ "color" "net" ];
+  buildFeatures = [
+    "color"
+    "net"
+  ];
 
   # disable network features in tests
   checkFeatures = [ "color" ];
@@ -283,7 +292,10 @@ where they are known to differ. But there are ways to customize the argument:
    import <nixpkgs> {
      crossSystem = (import <nixpkgs/lib>).systems.examples.armhf-embedded // {
        rust.rustcTarget = "thumb-crazy";
-       rust.platform = { foo = ""; bar = ""; };
+       rust.platform = {
+         foo = "";
+         bar = "";
+       };
      };
    }
    ```
@@ -310,7 +322,7 @@ so:
 
 ```nix
 rustPlatform.buildRustPackage {
-  /* ... */
+  # ...
   checkType = "debug";
 }
 ```
@@ -353,7 +365,7 @@ This can be achieved with `--skip` in `checkFlags`:
 
 ```nix
 rustPlatform.buildRustPackage {
-  /* ... */
+  # ...
   checkFlags = [
     # reason for disabling test
     "--skip=example::tests:example_test"
@@ -370,7 +382,7 @@ adapted to be compatible with cargo-nextest.
 
 ```nix
 rustPlatform.buildRustPackage {
-  /* ... */
+  # ...
   useNextest = true;
 }
 ```
@@ -382,7 +394,7 @@ sometimes it may be necessary to disable this so the tests run consecutively.
 
 ```nix
 rustPlatform.buildRustPackage {
-  /* ... */
+  # ...
   dontUseCargoParallelTests = true;
 }
 ```
@@ -394,7 +406,7 @@ should be built in `debug` mode, it can be configured like so:
 
 ```nix
 rustPlatform.buildRustPackage {
-  /* ... */
+  # ...
   buildType = "debug";
 }
 ```
@@ -548,12 +560,13 @@ directory of the `tokenizers` project's source archive, we use
 `sourceRoot` to point the tooling to this directory:
 
 ```nix
-{ fetchFromGitHub
+{
-, buildPythonPackage
+  fetchFromGitHub,
-, cargo
+  buildPythonPackage,
-, rustPlatform
+  cargo,
-, rustc
+  rustPlatform,
-, setuptools-rust
+  rustc,
+  setuptools-rust,
 }:
 
 buildPythonPackage rec {
@@ -568,7 +581,12 @@ buildPythonPackage rec {
   };
 
   cargoDeps = rustPlatform.fetchCargoVendor {
-    inherit pname version src sourceRoot;
+    inherit
+      pname
+      version
+      src
+      sourceRoot
+      ;
     hash = "sha256-RO1m8wEd5Ic2M9q+zFHeCJWhCr4Sv3CEWd08mkxsBec=";
   };
 
@@ -593,12 +611,12 @@ following example, the crate is in `src/rust`, as specified in the
 path for `fetchCargoVendor`.
 
 ```nix
-
+{
-{ buildPythonPackage
+  buildPythonPackage,
-, fetchPypi
+  fetchPypi,
-, rustPlatform
+  rustPlatform,
-, setuptools-rust
+  setuptools-rust,
-, openssl
+  openssl,
 }:
 
 buildPythonPackage rec {
@@ -632,10 +650,11 @@ builds the `retworkx` Python package. `fetchCargoVendor` and
 `maturinBuildHook` is used to perform the build.
 
 ```nix
-{ lib
+{
-, buildPythonPackage
+  lib,
-, rustPlatform
+  buildPythonPackage,
-, fetchFromGitHub
+  rustPlatform,
+  fetchFromGitHub,
 }:
 
 buildPythonPackage rec {
@@ -655,7 +674,10 @@ buildPythonPackage rec {
     hash = "sha256-QsPCQhNZKYCAogQriQX6pBYQUDAIUsEdRX/63dAqTzg=";
   };
 
-  nativeBuildInputs = with rustPlatform; [ cargoSetupHook maturinBuildHook ];
+  nativeBuildInputs = with rustPlatform; [
+    cargoSetupHook
+    maturinBuildHook
+  ];
 
   # ...
 }
@@ -666,20 +688,21 @@ buildPythonPackage rec {
 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 `fetchCargoVendor` and `cargoSetupHook` and leave the rest to Meson. `rust` and `cargo` are still needed in `nativeBuildInputs` for Meson to use.
 
 ```nix
-{ lib
+{
-, stdenv
+  lib,
-, fetchFromGitLab
+  stdenv,
-, meson
+  fetchFromGitLab,
-, ninja
+  meson,
-, pkg-config
+  ninja,
-, rustPlatform
+  pkg-config,
-, rustc
+  rustPlatform,
-, cargo
+  rustc,
-, wrapGAppsHook4
+  cargo,
-, blueprint-compiler
+  wrapGAppsHook4,
-, libadwaita
+  blueprint-compiler,
-, libsecret
+  libadwaita,
-, tinysparql
+  libsecret,
+  tinysparql,
 }:
 
 stdenv.mkDerivation rec {
@@ -767,7 +790,9 @@ patches the derivation:
 with import <nixpkgs> { };
 ((import ./hello.nix).hello { }).override {
   crateOverrides = defaultCrateOverrides // {
-    hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0")  {
+    hello =
+      attrs:
+      lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0") {
         postPatch = ''
           substituteInPlace lib/zoneinfo.rs \
             --replace-fail "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
@@ -861,7 +886,8 @@ with import <nixpkgs> {};
 stdenv.mkDerivation {
   name = "rust-env";
   nativeBuildInputs = [
-    rustc cargo
+    rustc
+    cargo
 
     # Example Build-time Additional Dependencies
     pkg-config
@@ -917,15 +943,13 @@ Here is a simple `shell.nix` that provides Rust nightly (default profile) using
 ```nix
 with import <nixpkgs> { };
 let
-  fenix = callPackage
+  fenix = callPackage (fetchFromGitHub {
-    (fetchFromGitHub {
     owner = "nix-community";
     repo = "fenix";
     # commit from: 2023-03-03
     rev = "e2ea04982b892263c4d939f1cc3bf60a9c4deaa1";
     hash = "sha256-AsOim1A8KKtMWIxG+lXh5Q4P2bhOZjoUhFWJ1EuZNNk=";
-    })
+  }) { };
-    { };
 in
 mkShell {
   name = "rust-env";
@@ -964,8 +988,7 @@ You can also use Rust nightly to build rust packages using `makeRustPlatform`.
 The below snippet demonstrates invoking `buildRustPackage` with a Rust toolchain from oxalica's overlay:
 
 ```nix
-with import <nixpkgs>
+with import <nixpkgs> {
-{
   overlays = [
     (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
   ];
@@ -996,7 +1019,10 @@ rustPlatform.buildRustPackage rec {
   meta = {
     description = "Fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
-    license = with lib.licenses; [ mit unlicense ];
+    license = with lib.licenses; [
+      mit
+      unlicense
+    ];
     maintainers = with lib.maintainers; [ ];
   };
 }
@@ -1029,18 +1055,27 @@ with the path into which you have `git clone`d the `rustc` git
 repository:
 
 ```nix
- (final: prev: /*lib.optionalAttrs prev.stdenv.targetPlatform.isAarch64*/ {
+(
-   rust_1_72 =
+  final: prev: # lib.optionalAttrs prev.stdenv.targetPlatform.isAarch64
-     lib.updateManyAttrsByPath [{
+  {
-       path = [ "packages" "stable" ];
+    rust_1_72 = lib.updateManyAttrsByPath [
-       update = old: old.overrideScope(final: prev: {
+      {
+        path = [
+          "packages"
+          "stable"
+        ];
+        update =
+          old:
+          old.overrideScope (
+            final: prev: {
               rustc-unwrapped = prev.rustc-unwrapped.overrideAttrs (_: {
                 src = lib.cleanSource /git/scratch/rust;
                 # do *not* put passthru.isReleaseTarball=true here
               });
-       });
+            }
-     }]
+          );
-       prev.rust_1_72;
+      }
+    ] prev.rust_1_72;
   })
 ```
 

doc/languages-frameworks/swift.section.md

@@ -69,7 +69,13 @@ This produces some files in a directory `nix`, which will be part of your Nix
 expression. The next step is to write that expression:
 
 ```nix
-{ stdenv, swift, swiftpm, swiftpm2nix, fetchFromGitHub }:
+{
+  stdenv,
+  swift,
+  swiftpm,
+  swiftpm2nix,
+  fetchFromGitHub,
+}:
 
 let
   # Pass the generated files to the helper.
@@ -90,7 +96,10 @@ stdenv.mkDerivation rec {
   # Including SwiftPM as a nativeBuildInput provides a buildPhase for you.
   # This by default performs a release build using SwiftPM, essentially:
   #   swift build -c release
-  nativeBuildInputs = [ swift swiftpm ];
+  nativeBuildInputs = [
+    swift
+    swiftpm
+  ];
 
   # The helper provides a configure snippet that will prepare all dependencies
   # in the correct place, where SwiftPM expects them.

doc/languages-frameworks/texlive.section.md

@@ -10,7 +10,13 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
 
 - Packages cannot be used directly but must be assembled in an environment. To create or add packages to an environment, use
   ```nix
-  texliveSmall.withPackages (ps: with ps; [ collection-langkorean algorithms cm-super ])
+  texliveSmall.withPackages (
+    ps: with ps; [
+      collection-langkorean
+      algorithms
+      cm-super
+    ]
+  )
   ```
   The function `withPackages` can be called multiple times to add more packages.
 
@@ -18,12 +24,14 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
 
 - `texlive.withPackages` uses the same logic as `buildEnv`. Only parts of a package are installed in an environment: its 'runtime' files (`tex` output), binaries (`out` output), and support files (`tlpkg` output). Moreover, man and info pages are assembled into separate `man` and `info` outputs. To add only the TeX files of a package, or its documentation (`texdoc` output), just specify the outputs:
   ```nix
-  texlive.withPackages (ps: with ps; [
+  texlive.withPackages (
+    ps: with ps; [
       texdoc # recommended package to navigate the documentation
       perlPackages.LaTeXML.tex # tex files of LaTeXML, omit binaries
       cm-super
       cm-super.texdoc # documentation of cm-super
-  ])
+    ]
+  )
   ```
 
 - All packages distributed by TeX Live, which contains most of CTAN, are available and can be found under `texlive.pkgs`:
@@ -50,7 +58,12 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
 
   ```nix
   texlive.combine {
-    inherit (texlive) scheme-small collection-langkorean algorithms cm-super;
+    inherit (texlive)
+      scheme-small
+      collection-langkorean
+      algorithms
+      cm-super
+      ;
   }
   ```
 
@@ -61,8 +74,8 @@ Release 23.11 ships with a new interface that will eventually replace `texlive.c
   ```nix
   texlive.combine {
     # inherit (texlive) whatever-you-want;
-    pkgFilter = pkg:
+    pkgFilter =
-      pkg.tlType == "run" || pkg.tlType == "bin" || pkg.hasManpages || pkg.pname == "cm-super";
+      pkg: pkg.tlType == "run" || pkg.tlType == "bin" || pkg.hasManpages || pkg.pname == "cm-super";
     # elem tlType [ "run" "bin" "doc" "source" ]
     # there are also other attributes: version, name
   }
@@ -121,7 +134,10 @@ let
     pname = "latex-foiltex";
     version = "2.1.4b";
 
-    outputs = [ "tex" "texdoc" ];
+    outputs = [
+      "tex"
+      "texdoc"
+    ];
     passthru.tlDeps = with texlive; [ latex ];
 
     srcs = [
@@ -146,7 +162,13 @@ let
     '';
 
     nativeBuildInputs = [
-      (texliveSmall.withPackages (ps: with ps; [ cm-super hypdoc latexmk ]))
+      (texliveSmall.withPackages (
+        ps: with ps; [
+          cm-super
+          hypdoc
+          latexmk
+        ]
+      ))
       # multiple-outputs.sh fails if $out is not defined
       (writeShellScript "force-tex-output.sh" ''
         out="''${tex-}"
@@ -192,9 +214,11 @@ let
 
   latex_with_foiltex = texliveSmall.withPackages (_: [ foiltex ]);
 in
-  runCommand "test.pdf" {
+runCommand "test.pdf"
+  {
     nativeBuildInputs = [ latex_with_foiltex ];
-  } ''
+  }
+  ''
     cat >test.tex <<EOF
     \documentclass{foils}
 
@@ -215,9 +239,11 @@ EOF
 The font cache for LuaLaTeX is written to `$HOME`.
 Therefore, it is necessary to set `$HOME` to a writable path, e.g. [before using LuaLaTeX in nix derivations](https://github.com/NixOS/nixpkgs/issues/180639):
 ```nix
-runCommandNoCC "lualatex-hello-world" {
+runCommandNoCC "lualatex-hello-world"
+  {
     buildInputs = [ texliveFull ];
-} ''
+  }
+  ''
     mkdir $out
     echo '\documentclass{article} \begin{document} Hello world \end{document}' > main.tex
     env HOME=$(mktemp -d) lualatex  -interaction=nonstopmode -output-format=pdf -output-directory=$out ./main.tex

doc/languages-frameworks/vim.section.md

@@ -47,11 +47,17 @@ To store your plugins in Vim packages (the native Vim plugin manager, see `:help
 vim-full.customize {
   vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
     # loaded on launch
-    start = [ youcompleteme fugitive ];
+    start = [
+      youcompleteme
+      fugitive
+    ];
     # manually loadable by calling `:packadd $plugin-name`
     # however, if a Vim plugin has a dependency that is not explicitly listed in
     # opt that dependency will always be added to start to avoid confusion.
-    opt = [ phpCompletion elm-vim ];
+    opt = [
+      phpCompletion
+      elm-vim
+    ];
     # To automatically load a plugin when opening a filetype, add vimrc lines like:
     # autocmd FileType php :packadd phpCompletion
   };
@@ -63,7 +69,8 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
+    pkgs: with pkgs; {
       myVim = vim-full.customize {
         # `name` specifies the name of the executable and package
         name = "vim-with-plugins";
@@ -100,8 +107,7 @@ let
 in
 {
   environment.systemPackages = [
-    (
+    (pkgs.neovim.override {
-      pkgs.neovim.override {
       configure = {
         packages.myPlugins = with pkgs.vimPlugins; {
           start = [
@@ -112,8 +118,7 @@ in
         };
         # ...
       };
-     }
+    })
-    )
   ];
 }
 ```
@@ -129,7 +134,12 @@ plugins the following example can be used:
 vim-full.customize {
   vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
     # loaded on launch
-    plug.plugins = [ youcompleteme fugitive phpCompletion elm-vim ];
+    plug.plugins = [
+      youcompleteme
+      fugitive
+      phpCompletion
+      elm-vim
+    ];
   };
 }
 ```
@@ -148,7 +158,10 @@ Some plugins require overrides in order to function properly. Overrides are plac
 ```nix
 {
   deoplete-fish = super.deoplete-fish.overrideAttrs (old: {
-    dependencies = with super; [ deoplete-nvim vim-fish ];
+    dependencies = with super; [
+      deoplete-nvim
+      vim-fish
+    ];
   });
 }
 ```
@@ -199,9 +212,7 @@ You can then reference the generated vim plugins via:
 
 ```nix
 {
-  myVimPlugins = pkgs.vimPlugins.extend (
+  myVimPlugins = pkgs.vimPlugins.extend ((pkgs.callPackage ./generated.nix { }));
-    (pkgs.callPackage ./generated.nix {})
-  );
 }
 ```
 

doc/packages/cataclysm-dda.section.md

@@ -75,9 +75,11 @@ To install Cataclysm DDA with mods of your choice, you can use `withMods`
 attribute:
 
 ```nix
-cataclysm-dda.withMods (mods: with mods; [
+cataclysm-dda.withMods (
+  mods: with mods; [
     tileset.UndeadPeople
-])
+  ]
+)
 ```
 
 All mods, soundpacks, and tilesets available in nixpkgs are found in
@@ -88,7 +90,9 @@ in nixpkgs:
 
 ```nix
 let
-  customMods = self: super: lib.recursiveUpdate super {
+  customMods =
+    self: super:
+    lib.recursiveUpdate super {
       # Modify existing mod
       tileset.UndeadPeople = super.tileset.UndeadPeople.overrideAttrs (old: {
         # If you like to apply a patch to the tileset for example
@@ -120,10 +124,12 @@ let
       };
     };
 in
-cataclysm-dda.withMods (mods: with mods.extend customMods; [
+cataclysm-dda.withMods (
+  mods: with mods.extend customMods; [
     tileset.UndeadPeople
     mod.Awesome
     soundpack.Fantastic
     tileset.SuperDuper
-])
+  ]
+)
 ```

doc/packages/citrix.section.md

@@ -28,5 +28,6 @@ let
     ./custom-cert-1.pem
     ./custom-cert-2.pem # ...
   ];
-in citrix_workspace.override { inherit extraCerts; }
+in
+citrix_workspace.override { inherit extraCerts; }
 ```

doc/packages/darwin-builder.section.md

@@ -89,7 +89,13 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
     darwin.inputs.nixpkgs.follows = "nixpkgs";
   };
 
-  outputs = { self, darwin, nixpkgs, ... }@inputs:
+  outputs =
+    {
+      self,
+      darwin,
+      nixpkgs,
+      ...
+    }@inputs:
     let
 
       inherit (darwin.lib) darwinSystem;
@@ -101,7 +107,8 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
         system = linuxSystem;
         modules = [
           "${nixpkgs}/nixos/modules/profiles/nix-builder-vm.nix"
-        { virtualisation = {
+          {
+            virtualisation = {
               host.pkgs = pkgs;
               darwin-builder.workingDirectory = "/var/lib/darwin-builder";
               darwin-builder.hostPort = 22;
@@ -109,7 +116,8 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
           }
         ];
       };
-  in {
+    in
+    {
 
       darwinConfigurations = {
         machine1 = darwinSystem {
@@ -117,14 +125,20 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
           modules = [
             {
               nix.distributedBuilds = true;
-            nix.buildMachines = [{
+              nix.buildMachines = [
+                {
                   hostName = "localhost";
                   sshUser = "builder";
                   sshKey = "/etc/nix/builder_ed25519";
                   system = linuxSystem;
                   maxJobs = 4;
-              supportedFeatures = [ "kvm" "benchmark" "big-parallel" ];
+                  supportedFeatures = [
-            }];
+                    "kvm"
+                    "benchmark"
+                    "big-parallel"
+                  ];
+                }
+              ];
 
               launchd.daemons.darwin-builder = {
                 command = "${darwin-builder.config.system.build.macos-builder-installer}/bin/create-builder";

doc/packages/eclipse.section.md

@@ -15,7 +15,9 @@ If you prefer to install plugins in a more declarative manner, then Nixpkgs also
 ```nix
 {
   packageOverrides = pkgs: {
-    myEclipse = with pkgs.eclipses; eclipseWithPlugins {
+    myEclipse =
+      with pkgs.eclipses;
+      eclipseWithPlugins {
         eclipse = eclipse-platform;
         jvmArgs = [ "-Xmx2048m" ];
         plugins = [ plugins.color-theme ];
@@ -37,7 +39,9 @@ Expanding the previous example with two plugins using the above functions, we ha
 ```nix
 {
   packageOverrides = pkgs: {
-    myEclipse = with pkgs.eclipses; eclipseWithPlugins {
+    myEclipse =
+      with pkgs.eclipses;
+      eclipseWithPlugins {
         eclipse = eclipse-platform;
         jvmArgs = [ "-Xmx2048m" ];
         plugins = [

doc/packages/emacs.section.md

@@ -6,8 +6,11 @@ The Emacs package comes with some extra helpers to make it easier to configure.
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
-    myEmacs = emacs.pkgs.withPackages (epkgs: (with epkgs.melpaStablePackages; [
+    pkgs: with pkgs; {
+      myEmacs = emacs.pkgs.withPackages (
+        epkgs:
+        (with epkgs.melpaStablePackages; [
           company
           counsel
           flycheck
@@ -15,7 +18,8 @@ The Emacs package comes with some extra helpers to make it easier to configure.
           magit
           projectile
           use-package
-    ]));
+        ])
+      );
     };
 }
 ```
@@ -24,7 +28,8 @@ You can install it like any other packages via `nix-env -iA myEmacs`. However, t
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; rec {
+  packageOverrides =
+    pkgs: with pkgs; rec {
       myEmacsConfig = writeText "default.el" ''
         (eval-when-compile
           (require 'use-package))
@@ -80,7 +85,9 @@ You can install it like any other packages via `nix-env -iA myEmacs`. However, t
           (projectile-global-mode))
       '';
 
-    myEmacs = emacs.pkgs.withPackages (epkgs: (with epkgs.melpaStablePackages; [
+      myEmacs = emacs.pkgs.withPackages (
+        epkgs:
+        (with epkgs.melpaStablePackages; [
           (runCommand "default.el" { } ''
             mkdir -p $out/share/emacs/site-lisp
             cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
@@ -92,7 +99,8 @@ You can install it like any other packages via `nix-env -iA myEmacs`. However, t
           magit
           projectile
           use-package
-    ]));
+        ])
+      );
     };
 }
 ```
@@ -108,11 +116,12 @@ let
     # ...
   };
 in
-((emacsPackagesFor emacs).overrideScope overrides).withPackages
+((emacsPackagesFor emacs).overrideScope overrides).withPackages (
-  (p: with p; [
+  p: with p; [
     # here both these package will use haskell-mode of our own choice
     ghc-mod
     dante
-  ])
+  ]
+)
 ```
 }

doc/packages/fish.section.md

@@ -42,7 +42,10 @@ way to test Fish plugins and scripts without having to alter the environment.
 
 ```nix
 wrapFish {
-  pluginPkgs = with fishPlugins; [ pure foreign-env ];
+  pluginPkgs = with fishPlugins; [
+    pure
+    foreign-env
+  ];
   completionDirs = [ ];
   functionDirs = [ ];
   confDirs = [ "/path/to/some/fish/init/dir/" ];

doc/packages/ibus.section.md

@@ -9,7 +9,8 @@ IBus needs to be configured accordingly to activate `typing-booster`. The config
 On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
 
 ```nix
-{ pkgs, ... }: {
+{ pkgs, ... }:
+{
   i18n.inputMethod = {
     enable = true;
     type = "ibus";
@@ -23,7 +24,12 @@ On NixOS, you need to explicitly enable `ibus` with given engines before customi
 The IBus engine is based on `hunspell` to support completion in many languages. By default, the dictionaries `de-de`, `en-us`, `fr-moderne` `es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
 
 ```nix
-ibus-engines.typing-booster.override { langs = [ "de-at" "en-gb" ]; }
+ibus-engines.typing-booster.override {
+  langs = [
+    "de-at"
+    "en-gb"
+  ];
+}
 ```
 
 _Note: each language passed to `langs` must be an attribute name in `pkgs.hunspellDicts`._
@@ -35,7 +41,8 @@ The `ibus-engines.typing-booster` package contains a program named `emoji-picker
 On NixOS, it can be installed using the following expression:
 
 ```nix
-{ pkgs, ... }: {
+{ pkgs, ... }:
+{
   fonts.packages = with pkgs; [ noto-fonts-color-emoji ];
 }
 ```

doc/packages/python-tree-sitter.section.md

@@ -7,16 +7,20 @@ Python bindings for Tree Sitter grammars are provided through the [py-tree-sitte
 For example, to experiment with the Rust grammar, you can create a shell environment with the following configuration:
 
 ```nix
-{ pkgs ? <nixpkgs> {} }:
+{
+  pkgs ? <nixpkgs> { },
+}:
 
 pkgs.mkShell {
   name = "py-tree-sitter-dev-shell";
 
   buildInputs = with pkgs; [
-    (python3.withPackages (ps: with ps; [
+    (python3.withPackages (
+      ps: with ps; [
         tree-sitter
         tree-sitter-grammars.tree-sitter-rust
-    ]))
+      ]
+    ))
   ];
 }
 ```

doc/packages/urxvt.section.md

@@ -8,8 +8,14 @@ In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It can be configu
 
 ```nix
 rxvt-unicode.override {
-  configure = { availablePlugins, ... }: {
+  configure =
-    plugins = with availablePlugins; [ perls resize-font vtwheel ];
+    { availablePlugins, ... }:
+    {
+      plugins = with availablePlugins; [
+        perls
+        resize-font
+        vtwheel
+      ];
     };
 }
 ```
@@ -20,7 +26,9 @@ In order to add plugins but also keep all default plugins installed, it is possi
 
 ```nix
 rxvt-unicode.override {
-  configure = { availablePlugins, ... }: {
+  configure =
+    { availablePlugins, ... }:
+    {
       plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
     };
 }
@@ -40,7 +48,9 @@ In addition to `plugins` the options `extraDeps` and `perlDeps` can be used to i
 
 ```nix
 rxvt-unicode.override {
-  configure = { availablePlugins, ... }: {
+  configure =
+    { availablePlugins, ... }:
+    {
       pluginsDeps = [ xsel ];
     };
 }
@@ -50,7 +60,9 @@ rxvt-unicode.override {
 
 ```nix
 rxvt-unicode.override {
-  configure = { availablePlugins, ... }: {
+  configure =
+    { availablePlugins, ... }:
+    {
       perlDeps = with perlPackages; [ AnyEvent ];
     };
 }

doc/packages/weechat.section.md

@@ -3,9 +3,16 @@
 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 {
-    plugins = with availablePlugins; [ python perl ];
+  configure = (
-  });
+    { availablePlugins, ... }:
+    {
+      plugins = with availablePlugins; [
+        python
+        perl
+      ];
+    }
+  );
 }
 ```
 
@@ -16,9 +23,17 @@ The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and
 The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
 
 ```nix
-weechat.override { configure = {availablePlugins, ...}: {
+weechat.override {
+  configure =
+    { availablePlugins, ... }:
+    {
       plugins = with availablePlugins; [
-            (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
+        (python.withPackages (
+          ps: with ps; [
+            pycrypto
+            python-dbus
+          ]
+        ))
       ];
     };
 }
@@ -27,18 +42,32 @@ weechat.override { configure = {availablePlugins, ...}: {
 In order to also keep all default plugins installed, it is possible to use the following method:
 
 ```nix
-weechat.override { configure = { availablePlugins, ... }: {
+weechat.override {
-  plugins = builtins.attrValues (availablePlugins // {
+  configure =
-    python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
+    { availablePlugins, ... }:
-  });
+    {
-}; }
+      plugins = builtins.attrValues (
+        availablePlugins
+        // {
+          python = availablePlugins.python.withPackages (
+            ps: with ps; [
+              pycrypto
+              python-dbus
+            ]
+          );
+        }
+      );
+    };
+}
 ```
 
 WeeChat allows to set defaults on startup using the `--run-command`. The `configure` method can be used to pass commands to the program:
 
 ```nix
 weechat.override {
-  configure = { availablePlugins, ... }: {
+  configure =
+    { availablePlugins, ... }:
+    {
       init = ''
         /set foo bar
         /server add libera irc.libera.chat
@@ -53,9 +82,13 @@ Additionally, it's possible to specify scripts to be loaded when starting `weech
 
 ```nix
 weechat.override {
-  configure = { availablePlugins, ... }: {
+  configure =
+    { availablePlugins, ... }:
+    {
       scripts = with pkgs.weechatScripts; [
-      weechat-xmpp weechat-matrix-bridge wee-slack
+        weechat-xmpp
+        weechat-matrix-bridge
+        wee-slack
       ];
       init = ''
         /set plugins.var.python.jabber.key "val"
@@ -75,7 +108,10 @@ stdenv.mkDerivation {
     url = "https://scripts.tld/your-scripts.tar.gz";
     hash = "...";
   };
-  passthru.scripts = [ "foo.py" "bar.lua" ];
+  passthru.scripts = [
+    "foo.py"
+    "bar.lua"
+  ];
   installPhase = ''
     mkdir $out/share
     cp foo.py $out/share

doc/stdenv/cross-compilation.chapter.md

@@ -15,7 +15,13 @@ 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,
+  fooDep,
+  barDep,
+  ...
+}:
+{
   # ...stdenv.buildPlatform...
 }
 ```
@@ -169,9 +175,11 @@ e.g.
 
 ```nix
 {
-  nativeBuildInputs = [
+  nativeBuildInputs =
+    [
       meson
-  ] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
+    ]
+    ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
       mesonEmulatorHook
     ];
 }

doc/stdenv/meta.chapter.md

@@ -169,7 +169,12 @@ This means that `broken` can be used to express constraints, for example:
 
   ```nix
   {
-    meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ]);
+    meta.broken = lib.all (
+      map (p: p.meta.broken) [
+        glibc
+        musl
+      ]
+    );
   }
   ```
 

doc/stdenv/multiple-output.chapter.md

@@ -31,7 +31,12 @@ In nixpkgs there is a framework supporting multiple-output derivations. It tries
 
 ```nix
 {
-  outputs = [ "bin" "dev" "out" "doc" ];
+  outputs = [
+    "bin"
+    "dev"
+    "out"
+    "doc"
+  ];
 }
 ```
 

doc/stdenv/passthru.chapter.md

@@ -18,7 +18,9 @@ Its value can be accessed as if it was set inside a derivation.
 let
   hello = stdenv.mkDerivation {
     pname = "hello";
-    src = fetchGit { /* ... */ };
+    src = fetchGit {
+      # ...
+    };
 
     passthru = {
       foo = "bar";

doc/stdenv/stdenv.chapter.md

@@ -37,7 +37,11 @@ stdenv.mkDerivation {
   pname = "libfoo";
   version = "1.2.3";
   # ...
-  buildInputs = [libbar perl ncurses];
+  buildInputs = [
+    libbar
+    perl
+    ncurses
+  ];
 }
 ```
 
@@ -217,7 +221,10 @@ stdenv.mkDerivation rec {
     hash = "sha256-viwrS9lnaU8sTGuzK/+L/PlMM/xRRtgVuK5pixVeDEw=";
   };
 
-  nativeBuildInputs = [ makeWrapper pkg-config ];
+  nativeBuildInputs = [
+    makeWrapper
+    pkg-config
+  ];
   buildInputs = [ libseccomp ];
 
   postInstall = ''
@@ -227,11 +234,21 @@ stdenv.mkDerivation rec {
       --replace-fail "cp " "cp --no-preserve=mode "
 
     wrapProgram $out/bin/solo5-virtio-mkimage \
-      --prefix PATH : ${lib.makeBinPath [ dosfstools mtools parted syslinux ]}
+      --prefix PATH : ${
+        lib.makeBinPath [
+          dosfstools
+          mtools
+          parted
+          syslinux
+        ]
+      }
   '';
 
   doCheck = true;
-  nativeCheckInputs = [ util-linux qemu ];
+  nativeCheckInputs = [
+    util-linux
+    qemu
+  ];
   checkPhase = ''[elided] '';
 }
 ```
@@ -442,8 +459,7 @@ If you pass a function to `mkDerivation`, it will receive as its argument the fi
 mkDerivation (finalAttrs: {
   pname = "hello";
   withFeature = true;
-  configureFlags =
+  configureFlags = lib.optionals finalAttrs.withFeature [ "--with-feature" ];
-    lib.optionals finalAttrs.withFeature ["--with-feature"];
 })
 ```
 
@@ -460,8 +476,8 @@ various bindings:
 
 ```nix
 # `pkg` is the _original_ definition (for illustration purposes)
-let pkg =
+let
-  mkDerivation (finalAttrs: {
+  pkg = mkDerivation (finalAttrs: {
     # ...
 
     # An example attribute
@@ -471,17 +487,21 @@ let pkg =
     passthru.tests.simple = f finalAttrs.finalPackage;
 
     # An example of an attribute containing a function
-    passthru.appendPackages = packages':
+    passthru.appendPackages =
-      finalAttrs.finalPackage.overrideAttrs (newSelf: super: {
+      packages':
+      finalAttrs.finalPackage.overrideAttrs (
+        newSelf: super: {
           packages = super.packages ++ packages';
-      });
+        }
+      );
 
     # For illustration purposes; referenced as
     # `(pkg.overrideAttrs(x)).finalAttrs` etc in the text below.
     passthru.finalAttrs = finalAttrs;
     passthru.original = pkg;
   });
-in pkg
+in
+pkg
 ```
 
 Unlike the `pkg` binding in the above example, the `finalAttrs` parameter always references the final attributes. For instance `(pkg.overrideAttrs(x)).finalAttrs.finalPackage` is identical to `pkg.overrideAttrs(x)`, whereas `(pkg.overrideAttrs(x)).original` is the same as the original `pkg`.

doc/using/configuration.chapter.md

@@ -99,7 +99,9 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     ```nix
     {
-      allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
+      allowUnfreePredicate =
+        pkg:
+        builtins.elem (lib.getName pkg) [
           "roon-server"
           "vscode"
         ];
@@ -112,7 +114,10 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     ```nix
     {
-      allowlistedLicenses = with lib.licenses; [ amd wtfpl ];
+      allowlistedLicenses = with lib.licenses; [
+        amd
+        wtfpl
+      ];
     }
     ```
 
@@ -120,7 +125,10 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     ```nix
     {
-      blocklistedLicenses = with lib.licenses; [ agpl3Only gpl3Only ];
+      blocklistedLicenses = with lib.licenses; [
+        agpl3Only
+        gpl3Only
+      ];
     }
     ```
 
@@ -158,7 +166,9 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     ```nix
     {
-      allowInsecurePredicate = pkg: builtins.elem (lib.getName pkg) [
+      allowInsecurePredicate =
+        pkg:
+        builtins.elem (lib.getName pkg) [
           "ovftool"
         ];
     }
@@ -173,7 +183,9 @@ You can define a function called `packageOverrides` in your local `~/.config/nix
 ```nix
 {
   packageOverrides = pkgs: rec {
-    foo = pkgs.foo.override { /* ... */ };
+    foo = pkgs.foo.override {
+      # ...
+    };
   };
 }
 ```
@@ -197,7 +209,8 @@ Using `packageOverrides`, it is possible to manage packages declaratively. This
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
+    pkgs: with pkgs; {
       myPackages = pkgs.buildEnv {
         name = "my-packages";
         paths = [
@@ -221,7 +234,8 @@ To install it into our environment, you can just run `nix-env -iA nixpkgs.myPack
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
+    pkgs: with pkgs; {
       myPackages = pkgs.buildEnv {
         name = "my-packages";
         paths = [
@@ -236,7 +250,10 @@ To install it into our environment, you can just run `nix-env -iA nixpkgs.myPack
           nox
           silver-searcher
         ];
-      pathsToLink = [ "/share" "/bin" ];
+        pathsToLink = [
+          "/share"
+          "/bin"
+        ];
       };
     };
 }
@@ -250,7 +267,8 @@ After building that new environment, look through `~/.nix-profile` to make sure
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; {
+  packageOverrides =
+    pkgs: with pkgs; {
       myPackages = pkgs.buildEnv {
         name = "my-packages";
         paths = [
@@ -264,8 +282,15 @@ After building that new environment, look through `~/.nix-profile` to make sure
           nox
           silver-searcher
         ];
-      pathsToLink = [ "/share/man" "/share/doc" "/bin" ];
+        pathsToLink = [
-      extraOutputsToInstall = [ "man" "doc" ];
+          "/share/man"
+          "/share/doc"
+          "/bin"
+        ];
+        extraOutputsToInstall = [
+          "man"
+          "doc"
+        ];
       };
     };
 }
@@ -275,7 +300,8 @@ This provides us with some useful documentation for using our packages.  However
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; rec {
+  packageOverrides =
+    pkgs: with pkgs; rec {
       myProfile = writeText "my-profile" ''
         export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
         export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
@@ -298,8 +324,16 @@ This provides us with some useful documentation for using our packages.  However
           nox
           silver-searcher
         ];
-      pathsToLink = [ "/share/man" "/share/doc" "/bin" "/etc" ];
+        pathsToLink = [
-      extraOutputsToInstall = [ "man" "doc" ];
+          "/share/man"
+          "/share/doc"
+          "/bin"
+          "/etc"
+        ];
+        extraOutputsToInstall = [
+          "man"
+          "doc"
+        ];
       };
     };
 }
@@ -326,7 +360,8 @@ Configuring GNU info is a little bit trickier than man pages. To work correctly,
 
 ```nix
 {
-  packageOverrides = pkgs: with pkgs; rec {
+  packageOverrides =
+    pkgs: with pkgs; rec {
       myProfile = writeText "my-profile" ''
         export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
         export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
@@ -351,8 +386,18 @@ Configuring GNU info is a little bit trickier than man pages. To work correctly,
           silver-searcher
           texinfoInteractive
         ];
-      pathsToLink = [ "/share/man" "/share/doc" "/share/info" "/bin" "/etc" ];
+        pathsToLink = [
-      extraOutputsToInstall = [ "man" "doc" "info" ];
+          "/share/man"
+          "/share/doc"
+          "/share/info"
+          "/bin"
+          "/etc"
+        ];
+        extraOutputsToInstall = [
+          "man"
+          "doc"
+          "info"
+        ];
         postBuild = ''
           if [ -x $out/bin/install-info -a -w $out/share/info ]; then
             shopt -s nullglob

doc/using/overlays.chapter.md

@@ -136,7 +136,12 @@ self: super:
 For BLAS/LAPACK switching to work correctly, all packages must depend on `blas` or `lapack`. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions of BLAS/LAPACK currently in the wild, `LP64` (integer size = 32 bits) and `ILP64` (integer size = 64 bits). The attributes `blas` and `lapack` are `LP64` by default. Their `ILP64` version are provided through the attributes `blas-ilp64` and `lapack-ilp64`. Some software needs special flags or patches to work with `ILP64`. You can check if `ILP64` is used in Nixpkgs with `blas.isILP64` and `lapack.isILP64`. Some software does NOT work with `ILP64`, and derivations need to specify an assertion to prevent this. You can prevent `ILP64` from being used with the following:
 
 ```nix
-{ stdenv, blas, lapack, ... }:
+{
+  stdenv,
+  blas,
+  lapack,
+  ...
+}:
 
 assert (!blas.isILP64) && (!lapack.isILP64);
 

doc/using/overrides.chapter.md

@@ -13,27 +13,38 @@ 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 -->
 
 ```nix
-import pkgs.path { overlays = [ (self: super: {
+import pkgs.path {
+  overlays = [
+    (self: super: {
       foo = super.foo.override { barSupport = true; };
-  })];}
+    })
+  ];
+}
 ```
 
 ```nix
 {
   mypkg = pkgs.callPackage ./mypkg.nix {
-    mydep = pkgs.mydep.override { /* ... */ };
+    mydep = pkgs.mydep.override {
+      # ...
+    };
   };
 }
 ```
@@ -55,9 +66,11 @@ Example usages:
 
 ```nix
 {
-  helloBar = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
+  helloBar = pkgs.hello.overrideAttrs (
+    finalAttrs: previousAttrs: {
       pname = previousAttrs.pname + "-bar";
-  });
+    }
+  );
 }
 ```
 
@@ -128,8 +141,15 @@ Example usage:
 
 ```nix
 {
-  f = { a, b }: { result = a+b; };
+  f =
-  c = lib.makeOverridable f { a = 1; b = 2; };
+    { a, b }:
+    {
+      result = a + b;
+    };
+  c = lib.makeOverridable f {
+    a = 1;
+    b = 2;
+  };
 }
 ```