Merge commit 'd8fe5e6c'

Conflicts:
	nixpkgs/pkgs/build-support/go/module.nix

27 files changed, 502 insertions, 281 deletions

diff --git a/nixpkgs/doc/languages-frameworks/agda.section.md b/nixpkgs/doc/languages-frameworks/agda.section.md
index cb1f12eec234..33fffc60c8db 100644
--- a/nixpkgs/doc/languages-frameworks/agda.section.md
+++ b/nixpkgs/doc/languages-frameworks/agda.section.md
@@ -114,7 +114,7 @@ This can be overridden by a different version of `ghc` as follows:
 
 ```nix
 agda.withPackages {
-  pkgs = [ ... ];
+  pkgs = [ /* ... */ ];
   ghc = haskell.compiler.ghcHEAD;
 }
 ```
@@ -180,6 +180,7 @@ To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/d
 
 ```nix
 { mkDerivation, standard-library, fetchFromGitHub }:
+{}
 ```
 
 Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you
@@ -193,7 +194,7 @@ mkDerivation {
   version = "1.5.0";
   pname = "iowa-stdlib";
 
-  src = ...
+  src = <...>;
 
   libraryFile = "";
   libraryName = "IAL-1.3";
diff --git a/nixpkgs/doc/languages-frameworks/android.section.md b/nixpkgs/doc/languages-frameworks/android.section.md
index 6f9717ca09cc..1c5687f8ebf1 100644
--- a/nixpkgs/doc/languages-frameworks/android.section.md
+++ b/nixpkgs/doc/languages-frameworks/android.section.md
@@ -104,18 +104,20 @@ pull from:
   repo.json to the Nix store based on the given repository XMLs.
 
 ```nix
-repoXmls = {
-  packages = [ ./xml/repository2-1.xml ];
-  images = [
-    ./xml/android-sys-img2-1.xml
-    ./xml/android-tv-sys-img2-1.xml
-    ./xml/android-wear-sys-img2-1.xml
-    ./xml/android-wear-cn-sys-img2-1.xml
-    ./xml/google_apis-sys-img2-1.xml
-    ./xml/google_apis_playstore-sys-img2-1.xml
-  ];
-  addons = [ ./xml/addon2-1.xml ];
-};
+{
+  repoXmls = {
+    packages = [ ./xml/repository2-1.xml ];
+    images = [
+      ./xml/android-sys-img2-1.xml
+      ./xml/android-tv-sys-img2-1.xml
+      ./xml/android-wear-sys-img2-1.xml
+      ./xml/android-wear-cn-sys-img2-1.xml
+      ./xml/google_apis-sys-img2-1.xml
+      ./xml/google_apis_playstore-sys-img2-1.xml
+    ];
+    addons = [ ./xml/addon2-1.xml ];
+  };
+}
 ```
 
 When building the above expression with:
diff --git a/nixpkgs/doc/languages-frameworks/beam.section.md b/nixpkgs/doc/languages-frameworks/beam.section.md
index 992149090c63..3653cdb337d1 100644
--- a/nixpkgs/doc/languages-frameworks/beam.section.md
+++ b/nixpkgs/doc/languages-frameworks/beam.section.md
@@ -117,6 +117,7 @@ If there are git dependencies.
 - From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
 
 ```nix
+{
   mixNixDeps = import ./mix.nix {
     inherit beamPackages lib;
     overrides = (final: prev: {
@@ -138,8 +139,9 @@ If there are git dependencies.
         # you can re-use the same beamDeps argument as generated
         beamDeps = with final; [ prometheus ];
       };
-  });
-};
+    });
+  };
+}
 ```
 
 You will need to run the build process once to fix the hash to correspond to your new git src.
@@ -153,11 +155,13 @@ Practical steps
 - start with the following argument to mixRelease
 
 ```nix
+{
   mixFodDeps = fetchMixDeps {
     pname = "mix-deps-${pname}";
     inherit src version;
     hash = lib.fakeHash;
   };
+}
 ```
 
 The first build will complain about the hash value, you can replace with the suggested value after that.
diff --git a/nixpkgs/doc/languages-frameworks/bower.section.md b/nixpkgs/doc/languages-frameworks/bower.section.md
index fceb6aaccb6d..20c142dad5b9 100644
--- a/nixpkgs/doc/languages-frameworks/bower.section.md
+++ b/nixpkgs/doc/languages-frameworks/bower.section.md
@@ -28,7 +28,7 @@ buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
   (fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
   (fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
   (fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
-];
+]; }
 ```
 
 Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.
@@ -42,11 +42,13 @@ The function is implemented in [pkgs/development/bower-modules/generic/default.n
 ### Example buildBowerComponents {#ex-buildBowerComponents}
 
 ```nix
-bowerComponents = buildBowerComponents {
-  name = "my-web-app";
-  generated = ./bower-packages.nix; # note 1
-  src = myWebApp; # note 2
-};
+{
+  bowerComponents = buildBowerComponents {
+    name = "my-web-app";
+    generated = ./bower-packages.nix; # note 1
+    src = myWebApp; # note 2
+  };
+}
 ```
 
 In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
diff --git a/nixpkgs/doc/languages-frameworks/chicken.section.md b/nixpkgs/doc/languages-frameworks/chicken.section.md
index 72c2642a6478..16b00b3f5b5d 100644
--- a/nixpkgs/doc/languages-frameworks/chicken.section.md
+++ b/nixpkgs/doc/languages-frameworks/chicken.section.md
@@ -13,10 +13,12 @@ done in the typical Nix fashion. For example, to include support for [SRFI
 might write:
 
 ```nix
+{
   buildInputs = [
     chicken
     chickenPackages.chickenEggs.srfi-189
   ];
+}
 ```
 
 Both `chicken` and its eggs have a setup hook which configures the environment
@@ -67,12 +69,12 @@ let
       chickenEggs = super.chickenEggs.overrideScope' (eggself: eggsuper: {
         srfi-180 = eggsuper.srfi-180.overrideAttrs {
           # path to a local copy of srfi-180
-          src = ...
+          src = <...>;
         };
       });
   });
 in
 # Here, `myChickenPackages.chickenEggs.json-rpc`, which depends on `srfi-180` will use
 # the local copy of `srfi-180`.
-# ...
+<...>
 ```
diff --git a/nixpkgs/doc/languages-frameworks/crystal.section.md b/nixpkgs/doc/languages-frameworks/crystal.section.md
index b97e75a58da1..9953f357048a 100644
--- a/nixpkgs/doc/languages-frameworks/crystal.section.md
+++ b/nixpkgs/doc/languages-frameworks/crystal.section.md
@@ -33,22 +33,26 @@ crystal.buildCrystalPackage rec {
   # Insert the path to your shards.nix file here
   shardsFile = ./shards.nix;
 
-  ...
+  # ...
 }
 ```
 
 This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
 
 ```nix
+{
   crystalBinaries.mint.src = "src/mint.cr";
 
   # ...
+}
 ```
 
 Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
 
 ```nix
+{
   crystalBinaries.mint.options = [ "--release" "--verbose" ];
+}
 ```
 
 Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
diff --git a/nixpkgs/doc/languages-frameworks/cuda.section.md b/nixpkgs/doc/languages-frameworks/cuda.section.md
index 09af824531a2..9791018c7f5f 100644
--- a/nixpkgs/doc/languages-frameworks/cuda.section.md
+++ b/nixpkgs/doc/languages-frameworks/cuda.section.md
@@ -16,24 +16,28 @@ To use one or more CUDA packages in an expression, give the expression a `cudaPa
 , cudaSupport ? config.cudaSupport
 , cudaPackages ? { }
 , ...
-}:
+}: {}
 ```
 
 When using `callPackage`, you can choose to pass in a different variant, e.g.
 when a different version of the toolkit suffices
 ```nix
-mypkg = callPackage { cudaPackages = cudaPackages_11_5; }
+{
+  mypkg = callPackage { cudaPackages = cudaPackages_11_5; };
+}
 ```
 
 If another version of say `cudnn` or `cutensor` is needed, you can override the
 package set to make it the default. This guarantees you get a consistent package
 set.
 ```nix
-mypkg = let
-  cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
-    cudnn = prev.cudnn_8_3;
-  }});
-in callPackage { inherit cudaPackages; };
+{
+  mypkg = let
+    cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
+      cudnn = prev.cudnn_8_3;
+    });
+  in callPackage { inherit cudaPackages; };
+}
 ```
 
 The CUDA NVCC compiler requires flags to determine which hardware you
diff --git a/nixpkgs/doc/languages-frameworks/cuelang.section.md b/nixpkgs/doc/languages-frameworks/cuelang.section.md
index 86304208aa20..70329b15fd7d 100644
--- a/nixpkgs/doc/languages-frameworks/cuelang.section.md
+++ b/nixpkgs/doc/languages-frameworks/cuelang.section.md
@@ -26,7 +26,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
 Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
 
 Here is an example:
-```
+```nix
 pkgs.writeCueValidator
   (pkgs.writeText "schema.cue" ''
     #Def1: {
@@ -42,7 +42,7 @@ pkgs.writeCueValidator
 `document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
 
 Another example, given the following `validator.nix` :
-```
+```nix
 { pkgs ? import <nixpkgs> {} }:
 let
   genericValidator = version:
diff --git a/nixpkgs/doc/languages-frameworks/dhall.section.md b/nixpkgs/doc/languages-frameworks/dhall.section.md
index 83567ab17ace..8d85c9f1daf7 100644
--- a/nixpkgs/doc/languages-frameworks/dhall.section.md
+++ b/nixpkgs/doc/languages-frameworks/dhall.section.md
@@ -187,6 +187,7 @@ wish to specify `source = true` for all Dhall packages, then you can amend the
 Dhall overlay like this:
 
 ```nix
+{
   dhallOverrides = self: super: {
     # Enable source for all Dhall packages
     buildDhallPackage =
@@ -194,6 +195,7 @@ Dhall overlay like this:
 
     true = self.callPackage ./true.nix { };
   };
+}
 ```
 
 … and now the Prelude will contain the fully decoded result of interpreting
@@ -429,22 +431,26 @@ $ dhall-to-nixpkgs github https://github.com/dhall-lang/dhall-lang.git \
 the Prelude globally for all packages, like this:
 
 ```nix
+{
   dhallOverrides = self: super: {
     true = self.callPackage ./true.nix { };
 
     Prelude = self.callPackage ./Prelude.nix { };
   };
+}
 ```
 
 … or selectively overriding the Prelude dependency for just the `true` package,
 like this:
 
 ```nix
+{
   dhallOverrides = self: super: {
     true = self.callPackage ./true.nix {
       Prelude = self.callPackage ./Prelude.nix { };
     };
   };
+}
 ```
 
 ## Overrides {#ssec-dhall-overrides}
@@ -454,11 +460,13 @@ You can override any of the arguments to `buildDhallGitHubPackage` or
 For example, suppose we wanted to selectively enable `source = true` just for the Prelude.  We can do that like this:
 
 ```nix
+{
   dhallOverrides = self: super: {
     Prelude = super.Prelude.overridePackage { source = true; };
 
-    …
+    # ...
   };
+}
 ```
 
 [semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages
diff --git a/nixpkgs/doc/languages-frameworks/dotnet.section.md b/nixpkgs/doc/languages-frameworks/dotnet.section.md
index 7466c8cdc228..a4e9d6cf9a6c 100644
--- a/nixpkgs/doc/languages-frameworks/dotnet.section.md
+++ b/nixpkgs/doc/languages-frameworks/dotnet.section.md
@@ -134,7 +134,7 @@ Here is an example `default.nix`, using some of the previously discussed argumen
 { lib, buildDotnetModule, dotnetCorePackages, ffmpeg }:
 
 let
-  referencedProject = import ../../bar { ... };
+  referencedProject = import ../../bar { /* ... */ };
 in buildDotnetModule rec {
   pname = "someDotnetApplication";
   version = "0.1";
@@ -236,7 +236,7 @@ the packages inside the `out` directory.
 $ nuget-to-nix out > deps.nix
 ```
 Which `nuget-to-nix` will generate an output similar to below
-```
+```nix
 { fetchNuGet }: [
   (fetchNuGet { pname = "FosterFramework"; version = "0.1.15-alpha"; sha256 = "0pzsdfbsfx28xfqljcwy100xhbs6wyx0z1d5qxgmv3l60di9xkll"; })
   (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1gjz379y61ag9whi78qxx09bwkwcznkx2mzypgycibxk61g11da1"; })
diff --git a/nixpkgs/doc/languages-frameworks/gnome.section.md b/nixpkgs/doc/languages-frameworks/gnome.section.md
index 5208f1013cbd..6bf867b21abe 100644
--- a/nixpkgs/doc/languages-frameworks/gnome.section.md
+++ b/nixpkgs/doc/languages-frameworks/gnome.section.md
@@ -47,6 +47,7 @@ When an application uses icons, an icon theme should be available in `XDG_DATA_D
 In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
 
 ```nix
+{
   buildInputs = [
     pantheon.elementary-icon-theme
   ];
@@ -56,6 +57,7 @@ In the rare case you need to use icons from dependencies (e.g. when an app force
       --prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
     )
   '';
+}
 ```
 
 To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
@@ -85,17 +87,19 @@ If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Gri
 Given the requirements above, the package expression would become messy quickly:
 
 ```nix
-preFixup = ''
-  for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
-    wrapProgram "$f" \
-      --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
-      --prefix XDG_DATA_DIRS : "$out/share" \
-      --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
-      --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
-      --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
-      --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
-  done
-'';
+{
+  preFixup = ''
+    for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
+      wrapProgram "$f" \
+        --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
+        --prefix XDG_DATA_DIRS : "$out/share" \
+        --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
+        --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
+        --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
+        --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
+    done
+  '';
+}
 ```
 
 Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
@@ -121,14 +125,16 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
 You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
 
 ```nix
-preFixup = ''
-  gappsWrapperArgs+=(
-    # Thumbnailers
-    --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
-    --prefix XDG_DATA_DIRS : "${librsvg}/share"
-    --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
-  )
-'';
+{
+  preFixup = ''
+    gappsWrapperArgs+=(
+      # Thumbnailers
+      --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
+      --prefix XDG_DATA_DIRS : "${librsvg}/share"
+      --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
+    )
+  '';
+}
 ```
 
 ## Updating GNOME packages {#ssec-gnome-updating}
@@ -159,7 +165,7 @@ python3.pkgs.buildPythonApplication {
   nativeBuildInputs = [
     wrapGAppsHook
     gobject-introspection
-    ...
+    # ...
   ];
 
   dontWrapGApps = true;
@@ -181,7 +187,7 @@ mkDerivation {
   nativeBuildInputs = [
     wrapGAppsHook
     qmake
-    ...
+    # ...
   ];
 
   dontWrapGApps = true;
diff --git a/nixpkgs/doc/languages-frameworks/go.section.md b/nixpkgs/doc/languages-frameworks/go.section.md
index 369eb88d331f..6db0e73505d2 100644
--- a/nixpkgs/doc/languages-frameworks/go.section.md
+++ b/nixpkgs/doc/languages-frameworks/go.section.md
@@ -38,24 +38,26 @@ The `buildGoModule` function accepts the following parameters in addition to the
 The following is an example expression using `buildGoModule`:
 
 ```nix
-pet = buildGoModule rec {
-  pname = "pet";
-  version = "0.3.4";
-
-  src = fetchFromGitHub {
-    owner = "knqyf263";
-    repo = "pet";
-    rev = "v${version}";
-    hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
-  };
+{
+  pet = buildGoModule rec {
+    pname = "pet";
+    version = "0.3.4";
+
+    src = fetchFromGitHub {
+      owner = "knqyf263";
+      repo = "pet";
+      rev = "v${version}";
+      hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
+    };
 
-  vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
+    vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
 
-  meta = {
-    description = "Simple command-line snippet manager, written in Go";
-    homepage = "https://github.com/knqyf263/pet";
-    license = lib.licenses.mit;
-    maintainers = with lib.maintainers; [ kalbasit ];
+    meta = {
+      description = "Simple command-line snippet manager, written in Go";
+      homepage = "https://github.com/knqyf263/pet";
+      license = lib.licenses.mit;
+      maintainers = with lib.maintainers; [ kalbasit ];
+    };
   };
 }
 ```
@@ -72,20 +74,22 @@ In the following is an example expression using `buildGoPackage`, the following
 - `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
 
 ```nix
-deis = buildGoPackage rec {
-  pname = "deis";
-  version = "1.13.0";
-
-  goPackagePath = "github.com/deis/deis";
+{
+  deis = buildGoPackage rec {
+    pname = "deis";
+    version = "1.13.0";
+
+    goPackagePath = "github.com/deis/deis";
+
+    src = fetchFromGitHub {
+      owner = "deis";
+      repo = "deis";
+      rev = "v${version}";
+      hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
+    };
 
-  src = fetchFromGitHub {
-    owner = "deis";
-    repo = "deis";
-    rev = "v${version}";
-    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
+    goDeps = ./deps.nix;
   };
-
-  goDeps = ./deps.nix;
 }
 ```
 
@@ -153,10 +157,12 @@ A string list of flags to pass to the Go linker tool via the `-ldflags` argument
 The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:
 
 ```nix
+{
   ldflags = [
     "-X main.Version=${version}"
     "-X main.Commit=${version}"
   ];
+}
 ```
 
 ### `tags` {#var-go-tags}
@@ -164,16 +170,20 @@ The most common use case for this argument is to make the resulting executable a
 A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`.  These constraints control whether Go files from the source should be included in the build. For example:
 
 ```nix
+{
   tags = [
     "production"
     "sqlite"
   ];
+}
 ```
 
 Tags can also be set conditionally:
 
 ```nix
+{
   tags = [ "production" ] ++ lib.optionals withSqlite [ "sqlite" ];
+}
 ```
 
 ### `deleteVendor` {#var-go-deleteVendor}
@@ -188,10 +198,12 @@ Many Go projects keep the main package in a `cmd` directory.
 Following example could be used to only build the example-cli and example-server binaries:
 
 ```nix
-subPackages = [
-  "cmd/example-cli"
-  "cmd/example-server"
-];
+{
+  subPackages = [
+    "cmd/example-cli"
+    "cmd/example-server"
+  ];
+}
 ```
 
 ### `excludedPackages` {#var-go-excludedPackages}
@@ -213,10 +225,12 @@ on a per package level using build tags (`tags`). In case CGO is disabled, these
 When a Go program depends on C libraries, place those dependencies in `buildInputs`:
 
 ```nix
+{
   buildInputs = [
     libvirt
     libxml2
   ];
+}
 ```
 
 `CGO_ENABLED` defaults to `1`.
@@ -245,15 +259,18 @@ This is done with the [`-skip` or `-run`](https://pkg.go.dev/cmd/go#hdr-Testing_
 For example, only a selection of tests could be run with:
 
 ```nix
+{
   # -run and -skip accept regular expressions
   checkFlags = [
     "-run=^Test(Simple|Fast)$"
   ];
+}
 ```
 
 If a larger amount of tests should be skipped, the following pattern can be used:
 
 ```nix
+{
   checkFlags =
     let
       # Skip tests that require network access
@@ -264,6 +281,7 @@ If a larger amount of tests should be skipped, the following pattern can be used
       ];
     in
     [ "-skip=^${builtins.concatStringsSep "$|^" skippedTests}$" ];
+}
 ```
 
 To disable tests altogether, set `doCheck = false;`.
diff --git a/nixpkgs/doc/languages-frameworks/idris.section.md b/nixpkgs/doc/languages-frameworks/idris.section.md
index e30a849dd456..0fa828825749 100644
--- a/nixpkgs/doc/languages-frameworks/idris.section.md
+++ b/nixpkgs/doc/languages-frameworks/idris.section.md
@@ -134,9 +134,9 @@ For example you could set
 
 ```nix
 build-idris-package {
-  idrisBuildOptions = [ "--log" "1" "--verbose" ]
+  idrisBuildOptions = [ "--log" "1" "--verbose" ];
 
-  ...
+  # ...
 }
 ```
 
diff --git a/nixpkgs/doc/languages-frameworks/java.section.md b/nixpkgs/doc/languages-frameworks/java.section.md
index 0ce1442cca68..6d56ffcd4503 100644
--- a/nixpkgs/doc/languages-frameworks/java.section.md
+++ b/nixpkgs/doc/languages-frameworks/java.section.md
@@ -7,7 +7,7 @@ stdenv.mkDerivation {
   pname = "...";
   version = "...";
 
-  src = fetchurl { ... };
+  src = fetchurl { /* ... */ };
 
   nativeBuildInputs = [
     ant
@@ -48,8 +48,10 @@ installs a JAR named `foo.jar` in its `share/java` directory, and
 another package declares the attribute
 
 ```nix
-buildInputs = [ libfoo ];
-nativeBuildInputs = [ jdk ];
+{
+  buildInputs = [ libfoo ];
+  nativeBuildInputs = [ jdk ];
+}
 ```
 
 then `CLASSPATH` will be set to
@@ -62,13 +64,15 @@ If your Java package provides a program, you need to generate a wrapper
 script to run it using a JRE. You can use `makeWrapper` for this:
 
 ```nix
-nativeBuildInputs = [ makeWrapper ];
+{
+  nativeBuildInputs = [ makeWrapper ];
 
-installPhase = ''
-  mkdir -p $out/bin
-  makeWrapper ${jre}/bin/java $out/bin/foo \
-    --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
-'';
+  installPhase = ''
+    mkdir -p $out/bin
+    makeWrapper ${jre}/bin/java $out/bin/foo \
+      --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
+  '';
+}
 ```
 
 Since the introduction of the Java Platform Module System in Java 9,
@@ -92,16 +96,18 @@ let
   something = (pkgs.something.override { jre = my_jre; });
   other = (pkgs.other.override { jre = my_jre; });
 in
-  ...
+  <...>
 ```
 
 You can also specify what JDK your JRE should be based on, for example
 selecting a 'headless' build to avoid including a link to GTK+:
 
 ```nix
-my_jre = pkgs.jre_minimal.override {
-  jdk = jdk11_headless;
-};
+{
+  my_jre = pkgs.jre_minimal.override {
+    jdk = jdk11_headless;
+  };
+}
 ```
 
 Note all JDKs passthru `home`, so if your application requires
@@ -116,7 +122,9 @@ It is possible to use a different Java compiler than `javac` from the
 OpenJDK. For instance, to use the GNU Java Compiler:
 
 ```nix
-nativeBuildInputs = [ gcj ant ];
+{
+  nativeBuildInputs = [ gcj ant ];
+}
 ```
 
 Here, Ant will automatically use `gij` (the GNU Java Runtime) instead of
diff --git a/nixpkgs/doc/languages-frameworks/javascript.section.md b/nixpkgs/doc/languages-frameworks/javascript.section.md
index d553444d53b0..b0da08d022c0 100644
--- a/nixpkgs/doc/languages-frameworks/javascript.section.md
+++ b/nixpkgs/doc/languages-frameworks/javascript.section.md
@@ -76,11 +76,13 @@ Exceptions to this rule are:
   when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
 
   ```nix
-  patchedPackageJSON = final.runCommand "package.json" { } ''
-    ${jq}/bin/jq '.version = "0.4.0" |
-      .devDependencies."@jsdoc/cli" = "^0.2.5"
-      ${sonar-src}/package.json > $out
-  '';
+  {
+    patchedPackageJSON = final.runCommand "package.json" { } ''
+      ${jq}/bin/jq '.version = "0.4.0" |
+        .devDependencies."@jsdoc/cli" = "^0.2.5"
+        ${sonar-src}/package.json > $out
+    '';
+  }
   ```
 
   You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
@@ -115,10 +117,12 @@ After you have identified the correct system, you need to override your package
 For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
 
 ```nix
+  {
     dat = prev.dat.override (oldAttrs: {
       buildInputs = [ final.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
       meta = oldAttrs.meta // { broken = since "12"; };
     });
+  }
 ```
 
 ### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
@@ -315,10 +319,12 @@ You will need at least a `yarn.lock` file. If upstream does not have one you nee
 If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:
 
 ```nix
-offlineCache = fetchYarnDeps {
-  yarnLock = src + "/yarn.lock";
-  hash = "....";
-};
+{
+  offlineCache = fetchYarnDeps {
+    yarnLock = src + "/yarn.lock";
+    hash = "....";
+  };
+}
 ```
 
 #### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
@@ -328,33 +334,41 @@ offlineCache = fetchYarnDeps {
 It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
 
 ```nix
-buildPhase = ''
-  export HOME=$(mktemp -d)
-  yarn --offline build
-'';
+{
+  buildPhase = ''
+    export HOME=$(mktemp -d)
+    yarn --offline build
+  '';
+}
 ```
 
 The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:
 
 ```nix
-doDist = false;
+{
+  doDist = false;
+}
 ```
 
 The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
 
 ```nix
-configurePhase = ''
-  ln -s $node_modules node_modules
-'';
+{
+  configurePhase = ''
+    ln -s $node_modules node_modules
+  '';
+}
 ```
 
 or if you need a writeable node_modules directory:
 
 ```nix
-configurePhase = ''
-  cp -r $node_modules node_modules
-  chmod +w node_modules
-'';
+{
+  configurePhase = ''
+    cp -r $node_modules node_modules
+    chmod +w node_modules
+  '';
+}
 ```
 
 #### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
@@ -394,12 +408,14 @@ mkYarnPackage rec {
 - Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:
 
   ```nix
-  yarnPreBuild = ''
-    mkdir -p $HOME/.node-gyp/${nodejs.version}
-    echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
-    ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
-    export npm_config_nodedir=${nodejs}
-  '';
+  {
+    yarnPreBuild = ''
+      mkdir -p $HOME/.node-gyp/${nodejs.version}
+      echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
+      ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
+      export npm_config_nodedir=${nodejs}
+    '';
+  }
   ```
 
   - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
diff --git a/nixpkgs/doc/languages-frameworks/lisp.section.md b/nixpkgs/doc/languages-frameworks/lisp.section.md
index 09193093b08f..73f20436c76f 100644
--- a/nixpkgs/doc/languages-frameworks/lisp.section.md
+++ b/nixpkgs/doc/languages-frameworks/lisp.section.md
@@ -45,7 +45,7 @@ $ sbcl
 
 Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
 
-```
+```nix
 let
   sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
 in mkShell {
@@ -55,10 +55,12 @@ in mkShell {
 
 Such a Lisp can be now used e.g. to compile your sources:
 
-```
-buildPhase = ''
-  ${sbcl'}/bin/sbcl --load my-build-file.lisp
-''
+```nix
+{
+  buildPhase = ''
+    ${sbcl'}/bin/sbcl --load my-build-file.lisp
+  '';
+}
 ```
 
 ## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
@@ -173,7 +175,7 @@ into the package scope with `withOverrides`.
 A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
 Nixpkgs-provided scope like this:
 
-```
+```nix
 let
   alexandria = sbcl.buildASDFSystem rec {
     pname = "alexandria";
@@ -199,7 +201,7 @@ new package with different parameters.
 
 Example of overriding `alexandria`:
 
-```
+```nix
 sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
   version = "1.4";
   src = fetchFromGitLab {
@@ -225,7 +227,7 @@ vice versa.
 
 To package slashy systems, use `overrideLispAttrs`, like so:
 
-```
+```nix
 ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
   systems = oldAttrs.systems ++ [ "alexandria/tests" ];
   lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
@@ -290,7 +292,7 @@ derivation.
 
 This example wraps CLISP:
 
-```
+```nix
 wrapLisp {
   pkg = clisp;
   faslExt = "fas";
diff --git a/nixpkgs/doc/languages-frameworks/lua.section.md b/nixpkgs/doc/languages-frameworks/lua.section.md
index a6577a56a436..db230cf944a5 100644
--- a/nixpkgs/doc/languages-frameworks/lua.section.md
+++ b/nixpkgs/doc/languages-frameworks/lua.section.md
@@ -87,6 +87,7 @@ final: prev:
         pname = "luarocks-nix";
         src = /home/my_luarocks/repository;
       });
+    };
   };
 
   luaPackages = lua.pkgs;
@@ -154,7 +155,9 @@ You can develop your package as you usually would, just don't forget to wrap it
 within a `toLuaModule` call, for instance
 
 ```nix
-mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
+{
+  mynewlib = toLuaModule ( stdenv.mkDerivation { /* ... */ });
+}
 ```
 
 There is also the `buildLuaPackage` function that can be used when lua modules
@@ -182,24 +185,26 @@ Each interpreter has the following attributes:
 The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
 The following is an example:
 ```nix
-luaposix = buildLuarocksPackage {
-  pname = "luaposix";
-  version = "34.0.4-1";
-
-  src = fetchurl {
-    url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
-    hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
-  };
-  disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
-  propagatedBuildInputs = [ bit32 lua std_normalize ];
-
-  meta = {
-    homepage = "https://github.com/luaposix/luaposix/";
-    description = "Lua bindings for POSIX";
-    maintainers = with lib.maintainers; [ vyp lblasc ];
-    license.fullName = "MIT/X11";
+{
+  luaposix = buildLuarocksPackage {
+    pname = "luaposix";
+    version = "34.0.4-1";
+
+    src = fetchurl {
+      url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
+      hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
+    };
+    disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
+    propagatedBuildInputs = [ bit32 lua std_normalize ];
+
+    meta = {
+      homepage = "https://github.com/luaposix/luaposix/";
+      description = "Lua bindings for POSIX";
+      maintainers = with lib.maintainers; [ vyp lblasc ];
+      license.fullName = "MIT/X11";
+    };
   };
-};
+}
 ```
 
 The `buildLuarocksPackage` delegates most tasks to luarocks:
diff --git a/nixpkgs/doc/languages-frameworks/maven.section.md b/nixpkgs/doc/languages-frameworks/maven.section.md
index 2ec419e010eb..e56beb102570 100644
--- a/nixpkgs/doc/languages-frameworks/maven.section.md
+++ b/nixpkgs/doc/languages-frameworks/maven.section.md
@@ -40,7 +40,7 @@ maven.buildMavenPackage rec {
     license = lib.licenses.gpl3Plus;
     maintainers = with lib.maintainers; [ majiir ];
   };
-}:
+}
 ```
 
 This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.
diff --git a/nixpkgs/doc/languages-frameworks/ocaml.section.md b/nixpkgs/doc/languages-frameworks/ocaml.section.md
index 4f3b6e0264f7..44f514e90a1b 100644
--- a/nixpkgs/doc/languages-frameworks/ocaml.section.md
+++ b/nixpkgs/doc/languages-frameworks/ocaml.section.md
@@ -92,6 +92,7 @@ buildDunePackage rec {
     license = lib.licenses.bsd3;
     maintainers = with lib.maintainers; [ sternenseemann ];
   };
+}
 ```
 
 Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
diff --git a/nixpkgs/doc/languages-frameworks/perl.section.md b/nixpkgs/doc/languages-frameworks/perl.section.md
index c188e228112c..4ef6d173a178 100644
--- a/nixpkgs/doc/languages-frameworks/perl.section.md
+++ b/nixpkgs/doc/languages-frameworks/perl.section.md
@@ -34,23 +34,27 @@ Nixpkgs provides a function `buildPerlPackage`, a generic package builder functi
 Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
 
 ```nix
-ClassC3 = buildPerlPackage rec {
-  pname = "Class-C3";
-  version = "0.21";
-  src = fetchurl {
-    url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
-    hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
+{
+  ClassC3 = buildPerlPackage rec {
+    pname = "Class-C3";
+    version = "0.21";
+    src = fetchurl {
+      url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
+      hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
+    };
   };
-};
+}
 ```
 
 Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
 
 ```nix
-foo = import ../path/to/foo.nix {
-  inherit stdenv fetchurl ...;
-  inherit (perlPackages) ClassC3;
-};
+{
+  foo = import ../path/to/foo.nix {
+    inherit stdenv fetchurl /* ... */;
+    inherit (perlPackages) ClassC3;
+  };
+}
 ```
 
 in `all-packages.nix`. You can test building a Perl package as follows:
@@ -91,17 +95,19 @@ buildPerlPackage rec {
 Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
 
 ```nix
-ClassC3Componentised = buildPerlPackage rec {
-  pname = "Class-C3-Componentised";
-  version = "1.0004";
-  src = fetchurl {
-    url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
-    hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
+{
+  ClassC3Componentised = buildPerlPackage rec {
+    pname = "Class-C3-Componentised";
+    version = "1.0004";
+    src = fetchurl {
+      url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
+      hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
+    };
+    propagatedBuildInputs = [
+      ClassC3 ClassInspector TestException MROCompat
+    ];
   };
-  propagatedBuildInputs = [
-    ClassC3 ClassInspector TestException MROCompat
-  ];
-};
+}
 ```
 
 On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
@@ -109,20 +115,22 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
 ```nix
 { lib, stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
 
-ImageExifTool = buildPerlPackage {
-  pname = "Image-ExifTool";
-  version = "12.50";
+{
+  ImageExifTool = buildPerlPackage {
+    pname = "Image-ExifTool";
+    version = "12.50";
 
-  src = fetchurl {
-    url = "https://exiftool.org/${pname}-${version}.tar.gz";
-    hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
-  };
+    src = fetchurl {
+      url = "https://exiftool.org/${pname}-${version}.tar.gz";
+      hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
+    };
 
-  nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
-  postInstall = lib.optionalString stdenv.isDarwin ''
-    shortenPerlShebang $out/bin/exiftool
-  '';
-};
+    nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
+    postInstall = lib.optionalString stdenv.isDarwin ''
+      shortenPerlShebang $out/bin/exiftool
+    '';
+  };
+}
 ```
 
 This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
diff --git a/nixpkgs/doc/languages-frameworks/php.section.md b/nixpkgs/doc/languages-frameworks/php.section.md
index 154d8174f9aa..c1493588a606 100644
--- a/nixpkgs/doc/languages-frameworks/php.section.md
+++ b/nixpkgs/doc/languages-frameworks/php.section.md
@@ -97,7 +97,7 @@ let
   myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
 in {
   services.phpfpm.pools."foo".phpPackage = myPhp;
-};
+}
 ```
 
 ```nix
@@ -108,7 +108,7 @@ let
   };
 in {
   services.phpfpm.pools."foo".phpPackage = myPhp;
-};
+}
 ```
 
 #### Example usage with `nix-shell` {#ssec-php-user-guide-installing-with-extensions-nix-shell}
@@ -149,7 +149,7 @@ php.override {
     extensions = prev.extensions // {
       mysqlnd = prev.extensions.mysqlnd.overrideAttrs (attrs: {
         patches = attrs.patches or [] ++ [
-          …
+          # ...
         ];
       });
     };
diff --git a/nixpkgs/doc/languages-frameworks/pkg-config.section.md b/nixpkgs/doc/languages-frameworks/pkg-config.section.md
index 75cbdaeb6fe8..e5a2b85b6576 100644
--- a/nixpkgs/doc/languages-frameworks/pkg-config.section.md
+++ b/nixpkgs/doc/languages-frameworks/pkg-config.section.md
@@ -12,18 +12,18 @@ Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixp
 
 A good example of all these things is zlib:
 
-```
+```nix
 { pkg-config, testers, ... }:
 
 stdenv.mkDerivation (finalAttrs: {
-  ...
+  /* ... */
 
   nativeBuildInputs = [ pkg-config validatePkgConfig ];
 
   passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
 
   meta = {
-    ...
+    /* ... */
     pkgConfigModules = [ "zlib" ];
   };
 })
diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md
index 049b395dcc25..f325af0641f6 100644
--- a/nixpkgs/doc/languages-frameworks/python.section.md
+++ b/nixpkgs/doc/languages-frameworks/python.section.md
@@ -254,17 +254,19 @@ The next example shows a non trivial overriding of the `blas` implementation to
 be used through out all of the Python package set:
 
 ```nix
-python3MyBlas = pkgs.python3.override {
-  packageOverrides = self: super: {
-    # We need toPythonModule for the package set to evaluate this
-    blas = super.toPythonModule(super.pkgs.blas.override {
-      blasProvider = super.pkgs.mkl;
-    });
-    lapack = super.toPythonModule(super.pkgs.lapack.override {
-      lapackProvider = super.pkgs.mkl;
-    });
+{
+  python3MyBlas = pkgs.python3.override {
+    packageOverrides = self: super: {
+      # We need toPythonModule for the package set to evaluate this
+      blas = super.toPythonModule(super.pkgs.blas.override {
+        blasProvider = super.pkgs.mkl;
+      });
+      lapack = super.toPythonModule(super.pkgs.lapack.override {
+        lapackProvider = super.pkgs.mkl;
+      });
+    };
   };
-};
+}
 ```
 
 This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.
@@ -322,7 +324,9 @@ python3Packages.buildPythonApplication rec {
 This is then added to `all-packages.nix` just as any other application would be.
 
 ```nix
-luigi = callPackage ../applications/networking/cluster/luigi { };
+{
+  luigi = callPackage ../applications/networking/cluster/luigi { };
+}
 ```
 
 Since the package is an application, a consumer doesn't need to care about
@@ -342,7 +346,9 @@ the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
 applied to the reference:
 
 ```nix
-youtube-dl = with python3Packages; toPythonApplication youtube-dl;
+{
+  youtube-dl = with python3Packages; toPythonApplication youtube-dl;
+}
 ```
 
 #### `toPythonModule` function {#topythonmodule-function}
@@ -354,10 +360,12 @@ bindings should be made available from `python-packages.nix`. The
 modifications.
 
 ```nix
-opencv = toPythonModule (pkgs.opencv.override {
-  enablePython = true;
-  pythonPackages = self;
-});
+{
+  opencv = toPythonModule (pkgs.opencv.override {
+    enablePython = true;
+    pythonPackages = self;
+  });
+}
 ```
 
 Do pay attention to passing in the right Python version!
@@ -1197,7 +1205,8 @@ a good indication that the package is not in a valid state.
 Pytest is the most common test runner for python repositories. A trivial
 test run would be:
 
-```
+```nix
+{
   nativeCheckInputs = [ pytest ];
   checkPhase = ''
     runHook preCheck
@@ -1206,6 +1215,7 @@ test run would be:
 
     runHook postCheck
   '';
+}
 ```
 
 However, many repositories' test suites do not translate well to nix's build
@@ -1213,7 +1223,8 @@ sandbox, and will generally need many tests to be disabled.
 
 To filter tests using pytest, one can do the following:
 
-```
+```nix
+{
   nativeCheckInputs = [ pytest ];
   # avoid tests which need additional data or touch network
   checkPhase = ''
@@ -1223,6 +1234,7 @@ To filter tests using pytest, one can do the following:
 
     runHook postCheck
   '';
+}
 ```
 
 `--ignore` will tell pytest to ignore that file or directory from being
@@ -1248,7 +1260,8 @@ when a package may need many items disabled to run the test suite.
 
 Using the example above, the analogous `pytestCheckHook` usage would be:
 
-```
+```nix
+{
   nativeCheckInputs = [
     pytestCheckHook
   ];
@@ -1268,12 +1281,14 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
   disabledTestPaths = [
     "tests/test_failing.py"
   ];
+}
 ```
 
 This is especially useful when tests need to be conditionally disabled,
 for example:
 
-```
+```nix
+{
   disabledTests = [
     # touches network
     "download"
@@ -1285,6 +1300,7 @@ for example:
     # can fail when building with other packages
     "socket"
   ];
+}
 ```
 
 Trying to concatenate the related strings to disable tests in a regular
@@ -1298,20 +1314,24 @@ all packages have test suites that can be run easily, and some have none at all.
 To help ensure the package still works, [`pythonImportsCheck`](#using-pythonimportscheck) can attempt to import
 the listed modules.
 
-```
+```nix
+{
   pythonImportsCheck = [
     "requests"
     "urllib"
   ];
+}
 ```
 
 roughly translates to:
 
-```
+```nix
+{
   postCheck = ''
     PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
     python -c "import requests; import urllib"
   '';
+}
 ```
 
 However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).
@@ -1342,7 +1362,8 @@ pkg3>=1.0,<=2.0
 
 we can do:
 
-```
+```nix
+{
   nativeBuildInputs = [
     pythonRelaxDepsHook
   ];
@@ -1353,6 +1374,7 @@ we can do:
   pythonRemoveDeps = [
     "pkg2"
   ];
+}
 ```
 
 which would result in the following `requirements.txt` file:
@@ -1365,9 +1387,11 @@ pkg3
 Another option is to pass `true`, that will relax/remove all dependencies, for
 example:
 
-```
+```nix
+{
   nativeBuildInputs = [ pythonRelaxDepsHook ];
   pythonRelaxDeps = true;
+}
 ```
 
 which would result in the following `requirements.txt` file:
@@ -1392,7 +1416,8 @@ work with any of the [existing hooks](#setup-hooks).
 
 `unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
 
-```
+```nix
+{
   nativeCheckInputs = [
     unittestCheckHook
   ];
@@ -1400,6 +1425,7 @@ work with any of the [existing hooks](#setup-hooks).
   unittestFlagsArray = [
     "-s" "tests" "-v"
   ];
+}
 ```
 
 #### Using sphinxHook {#using-sphinxhook}
@@ -1409,7 +1435,8 @@ using the popular Sphinx documentation generator.
 It is setup to automatically find common documentation source paths and
 render them using the default `html` style.
 
-```
+```nix
+{
   outputs = [
     "out"
     "doc"
@@ -1418,13 +1445,15 @@ render them using the default `html` style.
   nativeBuildInputs = [
     sphinxHook
   ];
+}
 ```
 
 The hook will automatically build and install the artifact into the
 `doc` output, if it exists. It also provides an automatic diversion
 for the artifacts of the `man` builder into the `man` target.
 
-```
+```nix
+{
   outputs = [
     "out"
     "doc"
@@ -1436,14 +1465,17 @@ for the artifacts of the `man` builder into the `man` target.
     "singlehtml"
     "man"
   ];
+}
 ```
 
 Overwrite `sphinxRoot` when the hook is unable to find your
 documentation source root.
 
-```
+```nix
+{
   # Configure sphinxRoot for uncommon paths
   sphinxRoot = "weird/docs/path";
+}
 ```
 
 The hook is also available to packages outside the python ecosystem by
@@ -1827,6 +1859,7 @@ folder and not downloaded again.
 If you need to change a package's attribute(s) from `configuration.nix` you could do:
 
 ```nix
+{
   nixpkgs.config.packageOverrides = super: {
     python3 = super.python3.override {
       packageOverrides = python-self: python-super: {
@@ -1841,6 +1874,7 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
       };
     };
   };
+}
 ```
 
 `python3Packages.twisted` is now globally overridden.
@@ -1853,11 +1887,13 @@ To modify only a Python package set instead of a whole Python derivation, use
 this snippet:
 
 ```nix
+{
   myPythonPackages = python3Packages.override {
     overrides = self: super: {
-      twisted = ...;
+      twisted = <...>;
     };
-  }
+  };
+}
 ```
 
 ### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
@@ -1893,7 +1929,7 @@ final: prev: {
     (
       python-final: python-prev: {
         foo = python-prev.foo.overridePythonAttrs (oldAttrs: {
-          ...
+          # ...
         });
       }
     )
@@ -1920,7 +1956,7 @@ The Python interpreters are by default not built with optimizations enabled, bec
 the builds are in that case not reproducible. To enable optimizations, override the
 interpreter of interest, e.g using
 
-```
+```nix
 let
   pkgs = import ./. {};
   mypython = pkgs.python3.override {
@@ -1938,17 +1974,21 @@ Some packages define optional dependencies for additional features. With
 `extras-require`, while PEP 621 calls these `optional-dependencies`.
 
 ```nix
-optional-dependencies = {
-  complete = [ distributed ];
-};
+{
+  optional-dependencies = {
+    complete = [ distributed ];
+  };
+}
 ```
 
 and letting the package requiring the extra add the list to its dependencies
 
 ```nix
-dependencies = [
-  ...
-] ++ dask.optional-dependencies.complete;
+{
+  dependencies = [
+    # ...
+  ] ++ dask.optional-dependencies.complete;
+}
 ```
 
 This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.
diff --git a/nixpkgs/doc/languages-frameworks/ruby.section.md b/nixpkgs/doc/languages-frameworks/ruby.section.md
index 9527395de58f..7dede6944a3d 100644
--- a/nixpkgs/doc/languages-frameworks/ruby.section.md
+++ b/nixpkgs/doc/languages-frameworks/ruby.section.md
@@ -124,11 +124,13 @@ mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
 Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
 
 ```nix
+{
   gems = bundlerEnv {
     name = "gems-for-some-project";
     gemdir = ./.;
     extraConfigPaths = [ "${./.}/.ruby-version" ];
   };
+}
 ```
 
 ### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}
diff --git a/nixpkgs/doc/languages-frameworks/rust.section.md b/nixpkgs/doc/languages-frameworks/rust.section.md
index 75e57a8bb574..8a1007b7bb8a 100644
--- a/nixpkgs/doc/languages-frameworks/rust.section.md
+++ b/nixpkgs/doc/languages-frameworks/rust.section.md
@@ -3,10 +3,12 @@
 To install the rust compiler and cargo put
 
 ```nix
-environment.systemPackages = [
-  rustc
-  cargo
-];
+{
+  environment.systemPackages = [
+    rustc
+    cargo
+  ];
+}
 ```
 
 into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
@@ -51,7 +53,9 @@ preferred over `cargoSha256` which was used for traditional Nix SHA-256 hashes.
 For example:
 
 ```nix
+{
   cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
+}
 ```
 
 Exception: If the application has cargo `git` dependencies, the `cargoHash`/`cargoSha256`
@@ -67,13 +71,17 @@ then be taken from the failed build. A fake hash can be used for
 `cargoHash` as follows:
 
 ```nix
+{
   cargoHash = lib.fakeHash;
+}
 ```
 
 For `cargoSha256` you can use:
 
 ```nix
+{
   cargoSha256 = lib.fakeSha256;
+}
 ```
 
 Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)
@@ -162,9 +170,11 @@ doesn't add a `Cargo.lock` to your `src`, and a `Cargo.lock` is still
 required to build a rust package. A simple fix is to use:
 
 ```nix
-postPatch = ''
-  ln -s ${./Cargo.lock} Cargo.lock
-'';
+{
+  postPatch = ''
+    ln -s ${./Cargo.lock} Cargo.lock
+  '';
+}
 ```
 
 The output hash of each dependency that uses a git source must be
@@ -409,7 +419,7 @@ the `cargoPatches` attribute to update or add it.
 
 ```nix
 rustPlatform.buildRustPackage rec {
-  (...)
+  # ...
   cargoPatches = [
     # a patch file to add/update Cargo.lock in the source code
     ./add-Cargo.lock.patch
@@ -433,10 +443,12 @@ containing `Cargo.toml` and `Cargo.lock`, `fetchCargoTarball`
 can be used as follows:
 
 ```nix
-cargoDeps = rustPlatform.fetchCargoTarball {
-  inherit src;
-  hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
-};
+{
+  cargoDeps = rustPlatform.fetchCargoTarball {
+    inherit src;
+    hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
+  };
+}
 ```
 
 The `src` attribute is required, as well as a hash specified through
@@ -458,23 +470,27 @@ function does not require a hash (unless git dependencies are used)
 and fetches every dependency as a separate fixed-output derivation.
 `importCargoLock` can be used as follows:
 
-```
-cargoDeps = rustPlatform.importCargoLock {
-  lockFile = ./Cargo.lock;
-};
+```nix
+{
+  cargoDeps = rustPlatform.importCargoLock {
+    lockFile = ./Cargo.lock;
+  };
+}
 ```
 
 If the `Cargo.lock` file includes git dependencies, then their output
 hashes need to be specified since they are not available through the
 lock file. For example:
 
-```
-cargoDeps = rustPlatform.importCargoLock {
-  lockFile = ./Cargo.lock;
-  outputHashes = {
-    "rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
+```nix
+{
+  cargoDeps = rustPlatform.importCargoLock {
+    lockFile = ./Cargo.lock;
+    outputHashes = {
+      "rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
+    };
   };
-};
+}
 ```
 
 If you do not specify an output hash for a git dependency, building
@@ -651,6 +667,66 @@ buildPythonPackage rec {
 }
 ```
 
+#### Rust package built with `meson` {#rust-package-built-with-meson}
+
+Some projects, especially GNOME applications, are built with the Meson Build System instead of calling Cargo directly. Using `rustPlatform.buildRustPackage` may successfully build the main program, but related files will be missing. Instead, you need to set up Cargo dependencies with `fetchCargoTarball` and `cargoSetupHook` and leave the rest to Meson. `rust` and `cargo` are still needed in `nativeBuildInputs` for Meson to use.
+
+```nix
+{ lib
+, stdenv
+, fetchFromGitLab
+, meson
+, ninja
+, pkg-config
+, rustPlatform
+, rustc
+, cargo
+, wrapGAppsHook4
+, blueprint-compiler
+, libadwaita
+, libsecret
+, tracker
+}:
+
+stdenv.mkDerivation rec {
+  pname = "health";
+  version = "0.95.0";
+
+  src = fetchFromGitLab {
+    domain = "gitlab.gnome.org";
+    owner = "World";
+    repo = "health";
+    rev = version;
+    hash = "sha256-PrNPprSS98yN8b8yw2G6hzTSaoE65VbsM3q7FVB4mds=";
+  };
+
+  cargoDeps = rustPlatform.fetchCargoTarball {
+    inherit src;
+    name = "${pname}-${version}";
+    hash = "sha256-8fa3fa+sFi5H+49B5sr2vYPkp9C9s6CcE0zv4xB8gww=";
+  };
+
+  nativeBuildInputs = [
+    meson
+    ninja
+    pkg-config
+    rustPlatform.cargoSetupHook
+    rustc
+    cargo
+    wrapGAppsHook4
+    blueprint-compiler
+  ];
+
+  buildInputs = [
+    libadwaita
+    libsecret
+    tracker
+  ];
+
+  # ...
+}
+```
+
 ## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
 
 ### Simple operation {#simple-operation}
@@ -732,27 +808,27 @@ general. A number of other parameters can be overridden:
 - The version of `rustc` used to compile the crate:
 
   ```nix
-  (hello {}).override { rust = pkgs.rust; };
+  (hello {}).override { rust = pkgs.rust; }
   ```
 
 - Whether to build in release mode or debug mode (release mode by
   default):
 
   ```nix
-  (hello {}).override { release = false; };
+  (hello {}).override { release = false; }
   ```
 
 - Whether to print the commands sent to `rustc` when building
   (equivalent to `--verbose` in cargo:
 
   ```nix
-  (hello {}).override { verbose = false; };
+  (hello {}).override { verbose = false; }
   ```
 
 - Extra arguments to be passed to `rustc`:
 
   ```nix
-  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
+  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; }
   ```
 
 - Phases, just like in any other derivation, can be specified using
@@ -768,7 +844,7 @@ general. A number of other parameters can be overridden:
     preConfigure = ''
        echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
     '';
-  };
+  }
   ```
 
 ### Setting Up `nix-shell` {#setting-up-nix-shell}
diff --git a/nixpkgs/doc/languages-frameworks/swift.section.md b/nixpkgs/doc/languages-frameworks/swift.section.md
index 213d444f499f..88d98deeb2dd 100644
--- a/nixpkgs/doc/languages-frameworks/swift.section.md
+++ b/nixpkgs/doc/languages-frameworks/swift.section.md
@@ -112,13 +112,17 @@ stdenv.mkDerivation rec {
 If you'd like to build a different configuration than `release`:
 
 ```nix
-swiftpmBuildConfig = "debug";
+{
+  swiftpmBuildConfig = "debug";
+}
 ```
 
 It is also possible to provide additional flags to `swift build`:
 
 ```nix
-swiftpmFlags = [ "--disable-dead-strip" ];
+{
+  swiftpmFlags = [ "--disable-dead-strip" ];
+}
 ```
 
 The default `buildPhase` already passes `-j` for parallel building.
@@ -132,7 +136,9 @@ Including `swiftpm` in your `nativeBuildInputs` also provides a default
 `checkPhase`, but it must be enabled with:
 
 ```nix
-doCheck = true;
+{
+  doCheck = true;
+}
 ```
 
 This essentially runs: `swift test -c release`
@@ -147,13 +153,15 @@ them, we need to make them writable.
 A special function `swiftpmMakeMutable` is available to replace the symlink
 with a writable copy:
 
-```
-configurePhase = generated.configure ++ ''
-  # Replace the dependency symlink with a writable copy.
-  swiftpmMakeMutable swift-crypto
-  # Now apply a patch.
-  patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
-'';
+```nix
+{
+  configurePhase = generated.configure ++ ''
+    # Replace the dependency symlink with a writable copy.
+    swiftpmMakeMutable swift-crypto
+    # Now apply a patch.
+    patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
+  '';
+}
 ```
 
 ## Considerations for custom build tools {#ssec-swift-considerations-for-custom-build-tools}
diff --git a/nixpkgs/doc/languages-frameworks/vim.section.md b/nixpkgs/doc/languages-frameworks/vim.section.md
index 1f3727f552c8..69031ccbd340 100644
--- a/nixpkgs/doc/languages-frameworks/vim.section.md
+++ b/nixpkgs/doc/languages-frameworks/vim.section.md
@@ -219,9 +219,11 @@ After running the updater, if nvim-treesitter received an update, also run [`nvi
 Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
 
 ```nix
-deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
-  dependencies = with super; [ deoplete-nvim vim-fish ];
-});
+{
+  deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
+    dependencies = with super; [ deoplete-nvim vim-fish ];
+  });
+}
 ```
 
 Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
@@ -264,8 +266,10 @@ pwntester/octo.nvim,,
 You can then reference the generated vim plugins via:
 
 ```nix
-myVimPlugins = pkgs.vimPlugins.extend (
-  (pkgs.callPackage ./generated.nix {})
-);
+{
+  myVimPlugins = pkgs.vimPlugins.extend (
+    (pkgs.callPackage ./generated.nix {})
+  );
+}
 ```