nixos/boot: hint nixos-rebuild build-vm-with-bootloader

as that is one of the last boot methods that doesn't support initrd secrets

.editorconfig

@@ -44,10 +44,6 @@ indent_size = 4
 indent_size = 2
 indent_style = space
 
-# Match package.json, which are generally pulled from upstream and accept them as they are
-[package.json]
-indent_style = unset
-
 # Disable file types or individual files
 # some of these files may be auto-generated and/or require significant changes
 

.git-blame-ignore-revs

@@ -102,75 +102,3 @@ fb0e5be84331188a69b3edd31679ca6576edb75a
 
 # systemd: break too long lines of Nix code
 67643f8ec84bef1482204709073e417c9f07eb87
-
-# {pkgs/development/cuda-modules,pkgs/test/cuda,pkgs/top-level/cuda-packages.nix}: reformat all CUDA files with nixfmt-rfc-style 2023-03-01
-802a1b4d3338f24cbc4efd704616654456d75a94
-
-# postgresql: move packages.nix to ext/default.nix
-719034f6f6749d624faa28dff259309fc0e3e730
-
-# php ecosystem: reformat with nixfmt-rfc-style
-75ae7621330ff8db944ce4dff4374e182d5d151f
-c759efa5e7f825913f9a69ef20f025f50f56dc4d
-
-# pkgs/os-specific/bsd: Reformat with nixfmt-rfc-style 2024-03-01
-3fe3b055adfc020e6a923c466b6bcd978a13069a
-
-# k3s: format with nixfmt-rfc-style
-6cfcd3c75428ede517bc6b15a353d704837a2830
-
-# python3Packages: format with nixfmt
-59b1aef59071cae6e87859dc65de973d2cc595c0
-
-# treewide description changes (#317959)
-bf995e3641950f4183c1dd9010349263dfa0123b
-755b915a158c9d588f08e9b08da9f7f3422070cc
-f8c4a98e8e138e21353a2c33b90db3359f539b37
-
-# vscode-extensions.*: format with nixfmt (RFC 166)
-7bf9febfa6271012b1ef86647a3a06f06875fdcf
-
-# remove uses of mdDoc (#303841)
-1a24330f792c8625746d07d842290e6fd95ae6f9
-acd0e3898feb321cb9a71a0fd376f1157d0f4553
-1b28414d2886c57343864326dbb745a634d3e37d
-6afb255d976f85f3359e4929abd6f5149c323a02
-
-# azure-cli: move to by-name, nixfmt #325950
-96cd538b68bd1d0a0a37979356d669abbba32ebc
-
-# poptracker: format with nixfmt-rfc-style (#326697)
-ff5c8f6cc3d1f2e017e86d50965c14b71f00567b
-
-# mangal: format with nixfmt-rfc-style #328284
-3bb5e993cac3a6e1c3056d2bc9bf43eb2c7a5951
-
-# pico-sdk: switch to finalAttrs (#329438)
-8946018b0391ae594d167f1e58497b18de068968
-
-# ollama: format with nixfmt-rfc-style (#329353)
-bdfde18037f8d9f9b641a4016c8ada4dc4cbf856
-
-# nixos/ollama: format with nixfmt-rfc-style (#329561)
-246d1ee533810ac1946d863bbd9de9b525818d56
-
-# steam: cleanup (#216972)
-ad815aebfbfe1415ff6436521d545029c803c3fb
-
-# nixos/nvidia: apply nixfmt-rfc-style (#313440)
-fbdcdde04a7caa007e825a8b822c75fab9adb2d6
-
-# step-cli: format package.nix with nixfmt (#331629)
-fc7a83f8b62e90de5679e993d4d49ca014ea013d
-
-# darwin.stdenv: format with nixfmt-rfc-style (#333962)
-93c10ac9e561c6594d3baaeaff2341907390d9b8
-
-# nrr: format with nixfmt-rfc-style (#334578)
-cffc27daf06c77c0d76bc35d24b929cb9d68c3c9
-
-# nixos/kanidm: inherit lib, nixfmt
-8f18393d380079904d072007fb19dc64baef0a3a
-
-# fetchurl: nixfmt-rfc-style
-ce21e97a1f20dee15da85c084f9d1148d84f853b

.github/CODEOWNERS

@@ -11,15 +11,12 @@
 # This also holds true for GitHub teams. Since almost none of our teams have write
 # permissions, you need to list all members of the team with commit access individually.
 
-# CI
+# GitHub actions
 /.github/workflows @NixOS/Security @Mic92 @zowoq
-/.github/workflows/check-nix-format.yml @infinisil
-/.github/workflows/nixpkgs-vet.yml @infinisil @philiptaron
-/ci @infinisil @philiptaron @NixOS/Security
+/.github/workflows/merge-staging @FRidh
 
-# Development support
+# EditorConfig
 /.editorconfig @Mic92 @zowoq
-/shell.nix @infinisil @NixOS/Security
 
 # Libraries
 /lib                        @infinisil
@@ -44,12 +41,9 @@
 /pkgs/top-level/stage.nix                        @Ericson2314
 /pkgs/top-level/splice.nix                       @Ericson2314
 /pkgs/top-level/release-cross.nix                @Ericson2314
-/pkgs/top-level/by-name-overlay.nix              @infinisil @philiptaron
-/pkgs/stdenv                                     @philiptaron
 /pkgs/stdenv/generic                             @Ericson2314
-/pkgs/stdenv/generic/check-meta.nix              @Ericson2314
+/pkgs/stdenv/generic/check-meta.nix              @Ericson2314 @piegamesde
 /pkgs/stdenv/cross                               @Ericson2314
-/pkgs/build-support                              @philiptaron
 /pkgs/build-support/cc-wrapper                   @Ericson2314
 /pkgs/build-support/bintools-wrapper             @Ericson2314
 /pkgs/build-support/setup-hooks                  @Ericson2314
@@ -57,9 +51,15 @@
 /pkgs/build-support/setup-hooks/auto-patchelf.py @layus
 /pkgs/pkgs-lib                                   @infinisil
 ## Format generators/serializers
-/pkgs/pkgs-lib/formats/libconfig                 @h7x4
+/pkgs/pkgs-lib/formats/libconfig                 @ckiee @h7x4
 /pkgs/pkgs-lib/formats/hocon                     @h7x4
 
+# pkgs/by-name
+/pkgs/test/nixpkgs-check-by-name @infinisil
+/pkgs/by-name/README.md @infinisil
+/pkgs/top-level/by-name-overlay.nix @infinisil
+/.github/workflows/check-by-name.yml @infinisil
+
 # Nixpkgs build-support
 /pkgs/build-support/writers @lassulus @Profpatsch
 
@@ -68,11 +68,8 @@
 /nixos/lib/make-disk-image.nix                 @raitobezarius
 
 # Nix, the package manager
-# @raitobezarius is not "code owner", but is listed here to be notified of changes
-# pertaining to the Nix package manager.
-# i.e. no authority over those files.
-pkgs/tools/package-management/nix/                    @NixOS/nix-team @raitobezarius
-nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobezarius
+pkgs/tools/package-management/nix/                    @raitobezarius @ma27
+nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
 
 # Nixpkgs documentation
 /maintainers/scripts/db-to-md.sh @jtojnar @ryantm
@@ -87,7 +84,6 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 /doc/README.md @infinisil
 /nixos/README.md @infinisil
 /pkgs/README.md @infinisil
-/pkgs/by-name/README.md @infinisil
 /maintainers/README.md @infinisil
 
 # User-facing development documentation
@@ -98,6 +94,7 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 /nixos/default.nix                                    @infinisil
 /nixos/lib/from-env.nix                               @infinisil
 /nixos/lib/eval-config.nix                            @infinisil
+/nixos/modules/system                                 @dasJ
 /nixos/modules/system/activation/bootspec.nix         @grahamc @cole-h @raitobezarius
 /nixos/modules/system/activation/bootspec.cue         @grahamc @cole-h @raitobezarius
 
@@ -107,9 +104,6 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 # NixOS QEMU virtualisation
 /nixos/virtualisation/qemu-vm.nix           @raitobezarius
 
-# ACME
-/nixos/modules/security/acme                @arianvp @flokli @aanderse @emilazy # no merge permission: @m1cr0man
-
 # Systemd
 /nixos/modules/system/boot/systemd.nix      @NixOS/systemd
 /nixos/modules/system/boot/systemd          @NixOS/systemd
@@ -120,9 +114,8 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 /nixos/modules/system/boot/loader/systemd-boot      @JulienMalka
 
 # Images and installer media
-/nixos/modules/profiles/installation-device.nix @ElvishJerricco
-/nixos/modules/installer/cd-dvd/                @ElvishJerricco
-/nixos/modules/installer/sd-card/
+/nixos/modules/installer/cd-dvd/            @samueldr
+/nixos/modules/installer/sd-card/           @samueldr
 
 # Updaters
 ## update.nix
@@ -132,30 +125,33 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 /pkgs/common-updater/scripts/update-source-version    @jtojnar
 
 # Python-related code and docs
-/doc/languages-frameworks/python.section.md   @mweinelt @natsukium
-/maintainers/scripts/update-python-libraries            @natsukium
-/pkgs/development/interpreters/python                   @natsukium
-/pkgs/top-level/python-packages.nix                     @natsukium
-/pkgs/top-level/release-python.nix                      @natsukium
+/maintainers/scripts/update-python-libraries	              @FRidh
+/pkgs/development/interpreters/python                       @FRidh
+/doc/languages-frameworks/python.section.md                 @FRidh @mweinelt
+/pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
 
 # Haskell
-/doc/languages-frameworks/haskell.section.md  @sternenseemann @maralorn
-/maintainers/scripts/haskell                  @sternenseemann @maralorn
-/pkgs/development/compilers/ghc               @sternenseemann @maralorn
-/pkgs/development/haskell-modules             @sternenseemann @maralorn
-/pkgs/test/haskell                            @sternenseemann @maralorn
-/pkgs/top-level/release-haskell.nix           @sternenseemann @maralorn
-/pkgs/top-level/haskell-packages.nix          @sternenseemann @maralorn
+/doc/languages-frameworks/haskell.section.md  @sternenseemann @maralorn @ncfavier
+/maintainers/scripts/haskell                  @sternenseemann @maralorn @ncfavier
+/pkgs/development/compilers/ghc               @sternenseemann @maralorn @ncfavier
+/pkgs/development/haskell-modules             @sternenseemann @maralorn @ncfavier
+/pkgs/test/haskell                            @sternenseemann @maralorn @ncfavier
+/pkgs/top-level/release-haskell.nix           @sternenseemann @maralorn @ncfavier
+/pkgs/top-level/haskell-packages.nix          @sternenseemann @maralorn @ncfavier
 
 # Perl
-/pkgs/development/interpreters/perl @stigtsp @zakame @marcusramberg
-/pkgs/top-level/perl-packages.nix   @stigtsp @zakame @marcusramberg
-/pkgs/development/perl-modules      @stigtsp @zakame @marcusramberg
+/pkgs/development/interpreters/perl @stigtsp @zakame @dasJ
+/pkgs/top-level/perl-packages.nix   @stigtsp @zakame @dasJ
+/pkgs/development/perl-modules      @stigtsp @zakame @dasJ
 
 # R
 /pkgs/applications/science/math/R   @jbedo
 /pkgs/development/r-modules         @jbedo
 
+# Ruby
+/pkgs/development/interpreters/ruby @marsam
+/pkgs/development/ruby-modules      @marsam
+
 # Rust
 /pkgs/development/compilers/rust @Mic92 @zowoq @winterqt @figsoda
 /pkgs/build-support/rust @zowoq @winterqt @figsoda
@@ -163,7 +159,7 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @NixOS/nix-team @raitobeza
 
 # C compilers
 /pkgs/development/compilers/gcc
-/pkgs/development/compilers/llvm @alyssais @RossComputerGuy
+/pkgs/development/compilers/llvm @RaitoBezarius
 /pkgs/development/compilers/emscripten @raitobezarius
 /doc/languages-frameworks/emscripten.section.md @raitobezarius
 
@@ -190,24 +186,28 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /lib/licenses.nix @alyssais
 
 # Qt
-/pkgs/development/libraries/qt-5 @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/development/libraries/qt-6 @K900 @NickCao @SuperSandro2000 @ttuegel
+/pkgs/development/libraries/qt-5 @NixOS/qt-kde
+/pkgs/development/libraries/qt-6 @NixOS/qt-kde
 
 # KDE / Plasma 5
-/pkgs/applications/kde @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/desktops/plasma-5 @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/development/libraries/kde-frameworks @K900 @NickCao @SuperSandro2000 @ttuegel
+/pkgs/applications/kde @NixOS/qt-kde
+/pkgs/desktops/plasma-5 @NixOS/qt-kde
+/pkgs/development/libraries/kde-frameworks @NixOS/qt-kde
 
 # KDE / Plasma 6
-/pkgs/kde @K900 @NickCao @SuperSandro2000 @ttuegel
-/maintainers/scripts/kde @K900 @NickCao @SuperSandro2000 @ttuegel
+/pkgs/kde @NixOS/qt-kde
+/maintainers/scripts/kde @NixOS/qt-kde
 
 # PostgreSQL and related stuff
-/pkgs/servers/sql/postgresql @thoughtpolice
+/pkgs/servers/sql/postgresql @thoughtpolice @marsam
 /nixos/modules/services/databases/postgresql.xml @thoughtpolice
 /nixos/modules/services/databases/postgresql.nix @thoughtpolice
 /nixos/tests/postgresql.nix @thoughtpolice
 
+# Linux kernel
+/pkgs/os-specific/linux/kernel    @raitobezarius
+/pkgs/top-level/linux-kernels.nix @raitobezarius
+
 # Hardened profile & related modules
 /nixos/modules/profiles/hardened.nix @joachifm
 /nixos/modules/security/hidepid.nix @joachifm
@@ -231,6 +231,7 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /nixos/modules/services/networking/ntp @thoughtpolice
 
 # Network
+/pkgs/tools/networking/octodns @Janik-Haag
 /pkgs/tools/networking/kea/default.nix @mweinelt
 /pkgs/tools/networking/babeld/default.nix @mweinelt
 /nixos/modules/services/networking/babeld.nix @mweinelt
@@ -252,7 +253,6 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 
 # Idris
 /pkgs/development/idris-modules @Infinisil
-/pkgs/development/compilers/idris2 @mattpolzin
 
 # Bazel
 /pkgs/development/tools/build-managers/bazel @Profpatsch
@@ -268,17 +268,14 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /pkgs/applications/editors/emacs                @adisbladis
 /pkgs/top-level/emacs-packages.nix              @adisbladis
 
-# Kakoune
-/pkgs/applications/editors/kakoune     @philiptaron
-
 # Neovim
-/pkgs/applications/editors/neovim      @figsoda @teto
+/pkgs/applications/editors/neovim      @figsoda @jonringer @teto
 
 # VimPlugins
-/pkgs/applications/editors/vim/plugins         @figsoda
+/pkgs/applications/editors/vim/plugins         @figsoda @jonringer
 
 # VsCode Extensions
-/pkgs/applications/editors/vscode/extensions
+/pkgs/applications/editors/vscode/extensions   @jonringer
 
 # PHP interpreter, packages, extensions, tests and documentation
 /doc/languages-frameworks/php.section.md          @aanderse @drupol @globin @ma27 @talyz
@@ -298,21 +295,17 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /pkgs/applications/blockchains  @mmahut @RaghavSood
 
 # Go
-/doc/languages-frameworks/go.section.md @kalbasit @katexochen @Mic92 @zowoq
-/pkgs/build-support/go @kalbasit @katexochen @Mic92 @zowoq
-/pkgs/development/compilers/go @kalbasit @katexochen @Mic92 @zowoq
+/doc/languages-frameworks/go.section.md @kalbasit @Mic92 @zowoq
+/pkgs/build-support/go @kalbasit @Mic92 @zowoq
+/pkgs/development/compilers/go @kalbasit @Mic92 @zowoq
 
 # GNOME
 /pkgs/desktops/gnome                              @jtojnar
-/pkgs/desktops/gnome/extensions                   @jtojnar
+/pkgs/desktops/gnome/extensions       @piegamesde @jtojnar
 /pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
 
 # Cinnamon
-/pkgs/by-name/ci/cinnamon-*    @mkg20001
-/pkgs/by-name/cj/cjs           @mkg20001
-/pkgs/by-name/mu/muffin        @mkg20001
-/pkgs/by-name/ne/nemo          @mkg20001
-/pkgs/by-name/ne/nemo-*        @mkg20001
+/pkgs/desktops/cinnamon @mkg20001
 
 # nim
 /pkgs/development/compilers/nim   @ehmry
@@ -322,20 +315,30 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 # terraform providers
 /pkgs/applications/networking/cluster/terraform-providers @zowoq
 
+# Matrix
+/pkgs/servers/heisenbridge                                 @piegamesde
+/pkgs/servers/matrix-conduit                               @piegamesde
+/nixos/modules/services/misc/heisenbridge.nix              @piegamesde
+/nixos/modules/services/misc/matrix-conduit.nix            @piegamesde
+/nixos/tests/matrix-conduit.nix                            @piegamesde
+
 # Forgejo
-nixos/modules/services/misc/forgejo.nix @adamcstephens @bendlas @emilylange
-pkgs/by-name/fo/forgejo/                @adamcstephens @bendlas @emilylange
+nixos/modules/services/misc/forgejo.nix      @bendlas @emilylange
+pkgs/applications/version-management/forgejo @bendlas @emilylange
 
 # Dotnet
-/pkgs/build-support/dotnet                  @corngood
-/pkgs/development/compilers/dotnet          @corngood
-/pkgs/test/dotnet                           @corngood
-/doc/languages-frameworks/dotnet.section.md @corngood
+/pkgs/build-support/dotnet                  @IvarWithoutBones
+/pkgs/development/compilers/dotnet          @IvarWithoutBones
+/pkgs/test/dotnet                           @IvarWithoutBones
+/doc/languages-frameworks/dotnet.section.md @IvarWithoutBones
 
 # Node.js
-/pkgs/build-support/node/build-npm-package      @winterqt
-/pkgs/build-support/node/fetch-npm-deps         @winterqt
-/doc/languages-frameworks/javascript.section.md @winterqt
+/pkgs/build-support/node/build-npm-package      @lilyinstarlight @winterqt
+/pkgs/build-support/node/fetch-npm-deps         @lilyinstarlight @winterqt
+/doc/languages-frameworks/javascript.section.md @lilyinstarlight @winterqt
+
+# environment.noXlibs option aka NoX
+/nixos/modules/config/no-x-libs.nix  @SuperSandro2000
 
 # OCaml
 /pkgs/build-support/ocaml           @ulrikstrid
@@ -359,34 +362,5 @@ pkgs/development/tools/continuous-integration/buildbot @Mic92 @zowoq
 
 # Pretix
 pkgs/by-name/pr/pretix/ @mweinelt
-pkgs/by-name/pr/pretalx/ @mweinelt
 nixos/modules/services/web-apps/pretix.nix @mweinelt
-nixos/modules/services/web-apps/pretalx.nix @mweinelt
 nixos/tests/web-apps/pretix.nix @mweinelt
-nixos/tests/web-apps/pretalx.nix @mweinelt
-
-# incus/lxc
-nixos/maintainers/scripts/incus/        @adamcstephens
-nixos/modules/virtualisation/incus.nix  @adamcstephens
-nixos/modules/virtualisation/lxc*       @adamcstephens
-nixos/tests/incus/                      @adamcstephens
-pkgs/by-name/in/incus/                  @adamcstephens
-pkgs/by-name/lx/lxc*                    @adamcstephens
-
-# ExpidusOS, Flutter
-/pkgs/development/compilers/flutter @RossComputerGuy
-/pkgs/desktops/expidus              @RossComputerGuy
-
-# GNU Tar & Zip
-/pkgs/tools/archivers/gnutar        @RossComputerGuy
-/pkgs/tools/archivers/zip           @RossComputerGuy
-
-# SELinux
-/pkgs/os-specific/linux/checkpolicy @RossComputerGuy
-/pkgs/os-specific/linux/libselinux  @RossComputerGuy
-/pkgs/os-specific/linux/libsepol    @RossComputerGuy
-
-# installShellFiles
-/pkgs/by-name/in/installShellFiles/*     @Ericson2314
-/pkgs/test/install-shell-files/*         @Ericson2314
-/doc/hooks/installShellFiles.section.md  @Ericson2314

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,12 +19,12 @@ For new packages please briefly describe the package or provide a link to its ho
   - [ ] `sandbox = true`
 - [ ] Tested, as applicable:
   - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
-  - and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
+  - and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
   - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
-  - made sure NixOS tests are [linked](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
+  - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
 - [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
 - [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
-- [24.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) (or backporting [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) and [24.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) Release notes)
+- [24.05 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) (or backporting [23.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md) and [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) Release notes)
   - [ ] (Package updates) Added a release notes entry if the change is major or breaking
   - [ ] (Module updates) Added a release notes entry if the change is significant
   - [ ] (Module addition) Added a release notes entry if adding a new NixOS module

.github/labeler.yml

@@ -12,25 +12,9 @@
   - any:
     - changed-files:
       - any-glob-to-any-file:
+        - pkgs/desktops/cinnamon/**/*
         - nixos/modules/services/x11/desktop-managers/cinnamon.nix
         - nixos/tests/cinnamon.nix
-        - nixos/tests/cinnamon-wayland.nix
-        - pkgs/by-name/ci/cinnamon-*/**/*
-        - pkgs/by-name/cj/cjs/**/*
-        - pkgs/by-name/mu/muffin/**/*
-        - pkgs/by-name/ne/nemo/**/*
-        - pkgs/by-name/ne/nemo-*/**/*
-
-"6.topic: dotnet":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/dotnet.section.md
-        - maintainers/scripts/update-dotnet-lockfiles.nix
-        - pkgs/build-support/dotnet/**/*
-        - pkgs/development/compilers/dotnet/**/*
-        - pkgs/test/dotnet/**/*
-        - pkgs/top-level/dotnet-packages.nix
 
 "6.topic: emacs":
   - any:
@@ -39,9 +23,9 @@
         - nixos/modules/services/editors/emacs.nix
         - nixos/modules/services/editors/emacs.xml
         - nixos/tests/emacs-daemon.nix
-        - pkgs/applications/editors/emacs/build-support/**/*
         - pkgs/applications/editors/emacs/elisp-packages/**/*
         - pkgs/applications/editors/emacs/**/*
+        - pkgs/build-support/emacs/**/*
         - pkgs/top-level/emacs-packages.nix
 
 "6.topic: Enlightenment DE":
@@ -79,13 +63,6 @@
         - lib/systems/flake-systems.nix
         - nixos/modules/config/nix-flakes.nix
 
-"6.topic: flutter":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/build-support/flutter/*.nix
-        - pkgs/development/compilers/flutter/**/*.nix
-
 "6.topic: GNOME":
   - any:
     - changed-files:
@@ -118,14 +95,6 @@
         - pkgs/top-level/haskell-packages.nix
         - pkgs/top-level/release-haskell.nix
 
-"6.topic: julia":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/julia.section.md
-        - pkgs/development/compilers/julia/**/*
-        - pkgs/development/julia-modules/**/*
-
 "6.topic: jupyter":
   - any:
     - changed-files:
@@ -136,14 +105,6 @@
         - pkgs/applications/editors/jupyter-kernels/**/*
         - pkgs/applications/editors/jupyter/**/*
 
-"6.topic: k3s":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/cluster/k3s/**/*
-        - nixos/tests/k3s/**/*
-        - pkgs/applications/networking/cluster/k3s/**/*
-
 "6.topic: kernel":
   - any:
     - changed-files:
@@ -157,17 +118,10 @@
       - any-glob-to-any-file:
         - lib/**
 
-"6.topic: llvm/clang":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/development/compilers/llvm/**/*
-
 "6.topic: lua":
   - any:
     - changed-files:
       - any-glob-to-any-file:
-        - pkgs/development/tools/misc/luarocks/*
         - pkgs/development/interpreters/lua-5/**/*
         - pkgs/development/interpreters/luajit/**/*
         - pkgs/development/lua-modules/**/*
@@ -230,7 +184,6 @@
         - pkgs/development/node-packages/**/*
         - pkgs/development/tools/yarn/*
         - pkgs/development/tools/yarn2nix-moretea/**/*
-        - pkgs/development/tools/pnpm/**/*
         - pkgs/development/web/nodejs/*
 
 "6.topic: ocaml":
@@ -270,12 +223,6 @@
     - changed-files:
       - any-glob-to-any-file:
         - .github/**/*
-        - CONTRIBUTING.md
-        - pkgs/README.md
-        - nixos/README.md
-        - maintainers/README.md
-        - lib/README.md
-        - doc/README.md
 
 "6.topic: printing":
   - any:
@@ -356,7 +303,6 @@
         #       *developed in this repo*;
         #       - not individual tests
         #       - not packages for test frameworks
-        - pkgs/build-support/testers/**
         - nixos/lib/testing/**
         - nixos/lib/test-driver/**
         - nixos/tests/nixos-test-driver/**
@@ -380,17 +326,6 @@
       - any-glob-to-any-file:
         - pkgs/applications/editors/vscode/**/*
 
-"6.topic: xen-project":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/virtualisation/xen*
-        - pkgs/applications/virtualization/xen/**
-        - pkgs/by-name/xe/xen-guest-agent/*
-        - pkgs/by-name/xt/xtf/*
-        - pkgs/development/ocaml-modules/xen*/*
-        - pkgs/development/ocaml-modules/vchan/*
-
 "6.topic: xfce":
   - any:
     - changed-files:
@@ -425,8 +360,3 @@
     - changed-files:
       - any-glob-to-any-file:
         - nixos/modules/**/*
-"8.has: maintainer-list (update)":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - maintainers/maintainer-list.nix

.github/workflows/backport.yml

@@ -20,11 +20,11 @@ jobs:
     if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - name: Create backport PRs
-        uses: korthout/backport-action@bd410d37cdcae80be6d969823ff5a225fe5c833f # v3.0.2
+        uses: korthout/backport-action@e8161d6a0dbfa2651b7daa76cbb75bc7c925bbf3 # v2.4.1
         with:
           # Config README: https://github.com/korthout/backport-action#backport-action
           copy_labels_pattern: 'severity:\ssecurity'

.github/workflows/basic-eval.yml

@@ -15,16 +15,15 @@ permissions:
 
 jobs:
   tests:
-    name: basic-eval-checks
     runs-on: ubuntu-latest
     # we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
     steps:
-    - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-    - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-    - uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
+    - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
+    - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+    - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
       with:
         # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
         name: nixpkgs-ci
         signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
     # explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset
-    - run: nix-build pkgs/top-level/release.nix -A release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin"  ]'
+    - run: nix-build pkgs/top-level/release.nix -A tarball.nixpkgs-basic-release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin"  ]'

.github/workflows/check-by-name.yml

@@ -0,0 +1,117 @@
+# Checks pkgs/by-name (see pkgs/by-name/README.md)
+# using the nixpkgs-check-by-name tool (see pkgs/test/nixpkgs-check-by-name)
+#
+# When you make changes to this workflow, also update pkgs/test/nixpkgs-check-by-name/scripts/run-local.sh adequately
+name: Check pkgs/by-name
+
+# The tool is pinned to a pre-built version on Hydra,
+# see pkgs/test/nixpkgs-check-by-name/scripts/README.md
+on:
+  # Using pull_request_target instead of pull_request avoids having to approve first time contributors
+  pull_request_target:
+    # This workflow depends on the base branch of the PR,
+    # but changing the base branch is not included in the default trigger events,
+    # which would be `opened`, `synchronize` or `reopened`.
+    # Instead it causes an `edited` event, so we need to add it explicitly here
+    # While `edited` is also triggered when the PR title/body is changed,
+    # this PR action is fairly quick, and PR's don't get edited that often,
+    # so it shouldn't be a problem
+    types: [opened, synchronize, reopened, edited]
+
+permissions:
+  # We need this permission to cancel the workflow run if there's a merge conflict
+  actions: write
+
+jobs:
+  check:
+    # This is x86_64-linux, for which the tool is always prebuilt on the nixos-* channels,
+    # as specified in nixos/release-combined.nix
+    runs-on: ubuntu-latest
+    # This should take 1 minute at most, but let's be generous.
+    # The default of 6 hours is definitely too long
+    timeout-minutes: 10
+    steps:
+      # This step has to be in this file,
+      # because it's needed to determine which revision of the repository to fetch,
+      # and we can only use other files from the repository once it's fetched.
+      - name: Resolving the merge commit
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          # This checks for mergeability of a pull request as recommended in
+          # https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests
+
+          # Retry the API query this many times
+          retryCount=3
+          # Start with 5 seconds, but double every retry
+          retryInterval=5
+          while true; do
+            echo "Checking whether the pull request can be merged"
+            prInfo=$(gh api \
+              -H "Accept: application/vnd.github+json" \
+              -H "X-GitHub-Api-Version: 2022-11-28" \
+              /repos/"$GITHUB_REPOSITORY"/pulls/${{ github.event.pull_request.number }})
+            mergeable=$(jq -r .mergeable <<< "$prInfo")
+            mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo")
+
+            if [[ "$mergeable" == "null" ]]; then
+              if (( retryCount == 0 )); then
+                echo "Not retrying anymore, probably GitHub is having internal issues"
+                exit 1
+              else
+                (( retryCount -= 1 )) || true
+
+                # null indicates that GitHub is still computing whether it's mergeable
+                # Wait a couple seconds before trying again
+                echo "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
+                sleep "$retryInterval"
+
+                (( retryInterval *= 2 )) || true
+              fi
+            else
+              break
+            fi
+          done
+
+          if [[ "$mergeable" == "true" ]]; then
+            echo "The PR can be merged, checking the merge commit $mergedSha"
+          else
+            echo "The PR cannot be merged, it has a merge conflict, cancelling the workflow.."
+            gh api \
+              --method POST \
+              -H "Accept: application/vnd.github+json" \
+              -H "X-GitHub-Api-Version: 2022-11-28" \
+              /repos/"$GITHUB_REPOSITORY"/actions/runs/"$GITHUB_RUN_ID"/cancel
+            sleep 60
+            # If it's still not canceled after a minute, something probably went wrong, just exit
+            exit 1
+          fi
+          echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
+        with:
+          # pull_request_target checks out the base branch by default
+          ref: ${{ env.mergedSha }}
+          # Fetches the merge commit and its parents
+          fetch-depth: 2
+      - name: Checking out base branch
+        run: |
+          base=$(mktemp -d)
+          git worktree add "$base" "$(git rev-parse HEAD^1)"
+          echo "base=$base" >> "$GITHUB_ENV"
+      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+      - name: Fetching the pinned tool
+        # Update the pinned version using pkgs/test/nixpkgs-check-by-name/scripts/update-pinned-tool.sh
+        run: |
+          # Get the direct /nix/store path from the pin to avoid having to evaluate Nixpkgs
+          toolPath=$(jq -r '."ci-path"' pkgs/test/nixpkgs-check-by-name/scripts/pinned-tool.json)
+          # This asks the substituter for the path, which should be there because Hydra will have pre-built and pushed it
+          nix-store --realise "$toolPath" --add-root result
+      - name: Running nixpkgs-check-by-name
+        run: |
+          if result/bin/nixpkgs-check-by-name --base "$base" .; then
+            exit 0
+          else
+            exitCode=$?
+            echo "To run locally: ./maintainers/scripts/check-by-name.sh $GITHUB_BASE_REF https://github.com/$GITHUB_REPOSITORY.git"
+            exit "$exitCode"
+          fi

.github/workflows/check-cherry-picks.yml

@@ -1,26 +0,0 @@
-name: "Check cherry-picks"
-on:
-  pull_request_target:
-    branches:
-     - 'release-**'
-     - 'staging-**'
-     - '!staging-next'
-
-permissions: {}
-
-jobs:
-  check:
-    name: cherry-pick-check
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-    - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-      with:
-        fetch-depth: 0
-        filter: blob:none
-    - name: Check cherry-picks
-      env:
-        BASE_SHA: ${{ github.event.pull_request.base.sha }}
-        HEAD_SHA: ${{ github.event.pull_request.head.sha }}
-      run: |
-        ./maintainers/scripts/check-cherry-picks.sh "$BASE_SHA" "$HEAD_SHA"

.github/workflows/check-maintainers-sorted.yaml

@@ -9,19 +9,14 @@ permissions:
 
 jobs:
   nixos:
-    name: maintainer-list-check
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-          # Only these directories to perform the check
-          sparse-checkout: |
-            lib
-            maintainers
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/check-nix-format.yml

@@ -1,90 +0,0 @@
-# This file was copied mostly from check-maintainers-sorted.yaml.
-# NOTE: Formatting with the RFC-style nixfmt command is not yet stable. See
-# https://github.com/NixOS/rfcs/pull/166.
-# Because of this, this action is not yet enabled for all files -- only for
-# those who have opted in.
-name: Check that Nix files are formatted
-
-on:
-  pull_request_target:
-    # See the comment at the same location in ./nixpkgs-vet.yml
-    types: [opened, synchronize, reopened, edited]
-permissions:
-  contents: read
-
-jobs:
-  nixos:
-    name: nixfmt-check
-    runs-on: ubuntu-latest
-    if: "!contains(github.event.pull_request.title, '[skip treewide]')"
-    steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-        with:
-          # pull_request_target checks out the base branch by default
-          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-          # Fetches the merge commit and its parents
-          fetch-depth: 2
-      - name: Checking out base branch
-        run: |
-          base=$(mktemp -d)
-          baseRev=$(git rev-parse HEAD^1)
-          git worktree add "$base" "$baseRev"
-          echo "baseRev=$baseRev" >> "$GITHUB_ENV"
-          echo "base=$base" >> "$GITHUB_ENV"
-      - name: Get Nixpkgs revision for nixfmt
-        run: |
-          # pin to a commit from nixpkgs-unstable to avoid e.g. building nixfmt
-          # from staging
-          # This should not be a URL, because it would allow PRs to run arbitrary code in CI!
-          rev=$(jq -r .rev ci/pinned-nixpkgs.json)
-          echo "url=https://github.com/NixOS/nixpkgs/archive/$rev.tar.gz" >> "$GITHUB_ENV"
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-          nix_path: nixpkgs=${{ env.url }}
-      - name: Install nixfmt
-        run: "nix-env -f '<nixpkgs>' -iAP nixfmt-rfc-style"
-      - name: Check that Nix files are formatted according to the RFC style
-        run: |
-          unformattedFiles=()
-
-          # TODO: Make this more parallel
-
-          # Loop through all Nix files touched by the PR
-          while readarray -d '' -n 2 entry && (( ${#entry[@]} != 0 )); do
-            type=${entry[0]}
-            file=${entry[1]}
-            case $type in
-              A*)
-                source=""
-                dest=$file
-                ;;
-              M*)
-                source=$file
-                dest=$file
-                ;;
-              C*|R*)
-                source=$file
-                read -r -d '' dest
-                ;;
-              *)
-                echo "Ignoring file $file with type $type"
-                continue
-            esac
-
-            # Ignore files that weren't already formatted
-            if [[ -n "$source" ]] && ! nixfmt --check ${{ env.base }}/"$source" 2>/dev/null; then
-              echo "Ignoring file $file because it's not formatted in the base commit"
-            elif ! nixfmt --check "$dest"; then
-              unformattedFiles+=("$dest")
-            fi
-          done < <(git diff -z --name-status ${{ env.baseRev }} -- '*.nix')
-
-          if (( "${#unformattedFiles[@]}" > 0 )); then
-            echo "Some new/changed Nix files are not properly formatted"
-            echo "Please go to the Nixpkgs root directory, run \`nix-shell\`, then:"
-            echo "nixfmt ${unformattedFiles[*]@Q}"
-            echo "If you're having trouble, please ping @NixOS/nix-formatting"
-            exit 1
-          fi

.github/workflows/check-nixf-tidy.yml

@@ -1,129 +0,0 @@
-name: Check changed Nix files with nixf-tidy (experimental)
-
-on:
-  pull_request_target:
-    types: [opened, synchronize, reopened, edited]
-permissions:
-  contents: read
-
-jobs:
-  nixos:
-    name: exp-nixf-tidy-check
-    runs-on: ubuntu-latest
-    if: "!contains(github.event.pull_request.title, '[skip treewide]')"
-    steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-        with:
-          # pull_request_target checks out the base branch by default
-          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-          # Fetches the merge commit and its parents
-          fetch-depth: 2
-      - name: Checking out base branch
-        run: |
-          base=$(mktemp -d)
-          baseRev=$(git rev-parse HEAD^1)
-          git worktree add "$base" "$baseRev"
-          echo "baseRev=$baseRev" >> "$GITHUB_ENV"
-          echo "base=$base" >> "$GITHUB_ENV"
-      - name: Get Nixpkgs revision for nixf
-        run: |
-          # pin to a commit from nixpkgs-unstable to avoid e.g. building nixf
-          # from staging
-          # This should not be a URL, because it would allow PRs to run arbitrary code in CI!
-          rev=$(jq -r .rev ci/pinned-nixpkgs.json)
-          echo "url=https://github.com/NixOS/nixpkgs/archive/$rev.tar.gz" >> "$GITHUB_ENV"
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-          nix_path: nixpkgs=${{ env.url }}
-      - name: Install nixf and jq
-        # provided jq is incompatible with our expression
-        run: "nix-env -f '<nixpkgs>' -iAP nixf jq"
-      - name: Check that Nix files pass nixf-tidy
-        run: |
-          # Filtering error messages we don't like
-          nixf_wrapper(){
-            nixf-tidy --variable-lookup < "$1" | jq -r '
-              [
-                "sema-escaping-with"
-              ]
-              as $ignored_errors|[.[]|select(.sname as $s|$ignored_errors|index($s)|not)]
-            '
-          }
-
-          failedFiles=()
-
-          # Don't report errors to file overview
-          # to avoid duplicates when editing title and description
-          if [[ "${{ github.event.action }}" == 'edited' ]] && [[ -z "${{ github.event.edited.changes.base }}" ]]; then
-            DONT_REPORT_ERROR=1
-          else
-            DONT_REPORT_ERROR=
-          fi
-          # TODO: Make this more parallel
-
-          # Loop through all Nix files touched by the PR
-          while readarray -d '' -n 2 entry && (( ${#entry[@]} != 0 )); do
-            type=${entry[0]}
-            file=${entry[1]}
-            case $type in
-              A*)
-                source=""
-                dest=$file
-                ;;
-              M*)
-                source=$file
-                dest=$file
-                ;;
-              C*|R*)
-                source=$file
-                read -r -d '' dest
-                ;;
-              *)
-                echo "Ignoring file $file with type $type"
-                continue
-            esac
-
-            if [[ -n "$source" ]] && [[ "$(nixf_wrapper ${{ env.base }}/"$source")" != '[]' ]] 2>/dev/null; then
-              echo "Ignoring file $file because it doesn't pass nixf-tidy in the base commit"
-              echo # insert blank line
-            else
-              nixf_report="$(nixf_wrapper "$dest")"
-              if [[ "$nixf_report" != '[]' ]]; then
-                echo "$dest doesn't pass nixf-tidy. Reported by nixf-tidy:"
-                errors=$(echo "$nixf_report" | jq -r --arg dest "$dest" '
-                  def getLCur: "line=" + (.line+1|tostring) + ",col=" + (.column|tostring);
-                  def getRCur: "endLine=" + (.line+1|tostring) + ",endColumn=" + (.column|tostring);
-                  def getRange: "file=\($dest)," + (.lCur|getLCur) + "," + (.rCur|getRCur);
-                  def getBody: . as $top|(.range|getRange) + ",title="+ .sname + "::" +
-                    (.message|sub("{}" ; ($top.args.[]|tostring)));
-                  def getNote: "\n::notice " + (.|getBody);
-                  def getMessage: "::error " + (.|getBody) + (if (.notes|length)>0 then
-                    ([.notes.[]|getNote]|add) else "" end);
-                  .[]|getMessage
-                ')
-                if [[ -z "$DONT_REPORT_ERROR" ]]; then
-                  echo "$errors"
-                else
-                  # just print in plain text
-                  echo "$errors" | sed 's/^:://'
-                  echo # add one empty line
-                fi
-                failedFiles+=("$dest")
-              fi
-            fi
-          done < <(git diff -z --name-status ${{ env.baseRev }} -- '*.nix')
-
-          if [[ -n "$DONT_REPORT_ERROR" ]]; then
-            echo "Edited the PR but didn't change the base branch, only the description/title."
-            echo "Not reporting errors again to avoid duplication."
-            echo # add one empty line
-          fi
-
-          if (( "${#failedFiles[@]}" > 0 )); then
-            echo "Some new/changed Nix files don't pass nixf-tidy."
-            echo "See ${{ github.event.pull_request.html_url }}/files for reported errors."
-            echo "If you believe this is a false positive, ping @Aleksanaa and @inclyc in this PR."
-            exit 1
-          fi

.github/workflows/check-shell.yml

@@ -1,31 +0,0 @@
-name: "Check shell"
-
-on:
-  pull_request_target:
-
-permissions: {}
-
-jobs:
-  x86_64-linux:
-    name: shell-check-x86_64-linux
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-        with:
-          # pull_request_target checks out the base branch by default
-          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-      - name: Build shell
-        run: nix-build shell.nix
-
-  aarch64-darwin:
-    name: shell-check-aarch64-darwin
-    runs-on: macos-latest
-    steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-        with:
-          # pull_request_target checks out the base branch by default
-          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-      - name: Build shell
-        run: nix-build shell.nix

.github/workflows/editorconfig.yml

@@ -10,7 +10,6 @@ on:
 
 jobs:
   tests:
-    name: editorconfig-check
     runs-on: ubuntu-latest
     if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
     steps:
@@ -25,11 +24,11 @@ jobs:
     - name: print list of changed files
       run: |
         cat "$HOME/changed_files"
-    - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+    - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
       with:
         # pull_request_target checks out the base branch by default
         ref: refs/pull/${{ github.event.pull_request.number }}/merge
-    - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+    - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0

.github/workflows/labels.yml

@@ -15,7 +15,6 @@ permissions:
 
 jobs:
   labels:
-    name: label-pr
     runs-on: ubuntu-latest
     if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
     steps:

.github/workflows/manual-nixos.yml

@@ -11,22 +11,21 @@ on:
 
 jobs:
   nixos:
-    name: nixos-manual-build
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
+      - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
         with:
           # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
           name: nixpkgs-ci
-          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
       - name: Building NixOS manual
         run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux

.github/workflows/manual-nixpkgs.yml

@@ -9,26 +9,24 @@ on:
     paths:
       - 'doc/**'
       - 'lib/**'
-      - 'pkgs/tools/nix/nixdoc/**'
 
 jobs:
   nixpkgs:
-    name: nixpkgs-manual-build
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
+      - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
         with:
           # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
           name: nixpkgs-ci
-          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
       - name: Building Nixpkgs manual
         run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual -A manual.tests

.github/workflows/nix-parse.yml

@@ -10,7 +10,6 @@ on:
 
 jobs:
   tests:
-    name: nix-files-parseable-check
     runs-on: ubuntu-latest
     if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
     steps:
@@ -25,12 +24,12 @@ jobs:
         if [[ -s "$HOME/changed_files" ]]; then
           echo "CHANGED_FILES=$HOME/changed_files" > "$GITHUB_ENV"
         fi
-    - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+    - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
       with:
         # pull_request_target checks out the base branch by default
         ref: refs/pull/${{ github.event.pull_request.number }}/merge
       if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}
-    - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+    - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
       with:
         nix_path: nixpkgs=channel:nixpkgs-unstable
     - name: Parse all changed or added nix files

.github/workflows/nixpkgs-vet.yml

@@ -1,116 +0,0 @@
-# `nixpkgs-vet` is a tool to vet Nixpkgs: its architecture, package structure, and more.
-# Among other checks, it makes sure that `pkgs/by-name` (see `../../pkgs/by-name/README.md`) follows the validity rules outlined in [RFC 140](https://github.com/NixOS/rfcs/pull/140).
-# When you make changes to this workflow, please also update `ci/nixpkgs-vet.sh` to reflect the impact of your work to the CI.
-# See https://github.com/NixOS/nixpkgs-vet for details on the tool and its checks.
-name: Vet nixpkgs
-
-on:
-  # Using pull_request_target instead of pull_request avoids having to approve first time contributors.
-  pull_request_target:
-    # This workflow depends on the base branch of the PR, but changing the base branch is not included in the default trigger events, which would be `opened`, `synchronize` or `reopened`.
-    # Instead it causes an `edited` event, so we need to add it explicitly here.
-    # While `edited` is also triggered when the PR title/body is changed, this PR action is fairly quick, and PRs don't get edited **that** often, so it shouldn't be a problem.
-    # There is a feature request for adding a `base_changed` event: https://github.com/orgs/community/discussions/35058
-    types: [opened, synchronize, reopened, edited]
-
-permissions: {}
-
-# We don't use a concurrency group here, because the action is triggered quite often (due to the PR edit trigger), and contributors would get notified on any canceled run.
-# There is a feature request for suppressing notifications on concurrency-canceled runs: https://github.com/orgs/community/discussions/13015
-
-jobs:
-  check:
-    name: nixpkgs-vet
-    # This needs to be x86_64-linux, because we depend on the tooling being pre-built in the GitHub releases.
-    runs-on: ubuntu-latest
-    # This should take 1 minute at most, but let's be generous. The default of 6 hours is definitely too long.
-    timeout-minutes: 10
-    steps:
-      # This step has to be in this file, because it's needed to determine which revision of the repository to fetch, and we can only use other files from the repository once it's fetched.
-      - name: Resolving the merge commit
-        env:
-          GH_TOKEN: ${{ github.token }}
-        run: |
-          # This checks for mergeability of a pull request as recommended in
-          # https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests
-
-          # Retry the API query this many times
-          retryCount=5
-          # Start with 5 seconds, but double every retry
-          retryInterval=5
-          while true; do
-            echo "Checking whether the pull request can be merged"
-            prInfo=$(gh api \
-              -H "Accept: application/vnd.github+json" \
-              -H "X-GitHub-Api-Version: 2022-11-28" \
-              /repos/"$GITHUB_REPOSITORY"/pulls/${{ github.event.pull_request.number }})
-            mergeable=$(jq -r .mergeable <<< "$prInfo")
-            mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo")
-
-            if [[ "$mergeable" == "null" ]]; then
-              if (( retryCount == 0 )); then
-                echo "Not retrying anymore. It's likely that GitHub is having internal issues: check https://www.githubstatus.com/"
-                exit 1
-              else
-                (( retryCount -= 1 )) || true
-
-                # null indicates that GitHub is still computing whether it's mergeable
-                # Wait a couple seconds before trying again
-                echo "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
-                sleep "$retryInterval"
-
-                (( retryInterval *= 2 )) || true
-              fi
-            else
-              break
-            fi
-          done
-
-          if [[ "$mergeable" == "true" ]]; then
-            echo "The PR can be merged, checking the merge commit $mergedSha"
-            echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
-          else
-            echo "The PR cannot be merged, it has a merge conflict, skipping the rest.."
-          fi
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-        if: env.mergedSha
-        with:
-          # pull_request_target checks out the base branch by default
-          ref: ${{ env.mergedSha }}
-          # Fetches the merge commit and its parents
-          fetch-depth: 2
-      - name: Checking out base branch
-        if: env.mergedSha
-        run: |
-          base=$(mktemp -d)
-          git worktree add "$base" "$(git rev-parse HEAD^1)"
-          echo "base=$base" >> "$GITHUB_ENV"
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
-        if: env.mergedSha
-      - name: Fetching the pinned tool
-        if: env.mergedSha
-        # Update the pinned version using ci/nixpkgs-vet/update-pinned-tool.sh
-        run: |
-          # The pinned version of the tooling to use.
-          toolVersion=$(<ci/nixpkgs-vet/pinned-version.txt)
-
-          # Fetch the x86_64-linux-specific release artifact containing the gzipped NAR of the pre-built tool.
-          toolPath=$(curl -sSfL https://github.com/NixOS/nixpkgs-vet/releases/download/"$toolVersion"/x86_64-linux.nar.gz \
-            | gzip -cd | nix-store --import | tail -1)
-
-          # Adds a result symlink as a GC root.
-          nix-store --realise "$toolPath" --add-root result
-      - name: Running nixpkgs-vet
-        if: env.mergedSha
-        env:
-          # Force terminal colors to be enabled. The library that `nixpkgs-vet` uses respects https://bixense.com/clicolors/
-          CLICOLOR_FORCE: 1
-        run: |
-          if result/bin/nixpkgs-vet --base "$base" .; then
-            exit 0
-          else
-            exitCode=$?
-            echo "To run locally: ./ci/nixpkgs-vet.sh $GITHUB_BASE_REF https://github.com/$GITHUB_REPOSITORY.git"
-            echo "If you're having trouble, ping @NixOS/nixpkgs-vet"
-            exit "$exitCode"
-          fi

.github/workflows/ofborg-pending.yml

@@ -16,7 +16,6 @@ permissions:
 
 jobs:
   action:
-    name: set-ofborg-pending
     if: github.repository_owner == 'NixOS'
     permissions:
       statuses: write

.github/workflows/periodic-merge-24h.yml

@@ -35,13 +35,13 @@ jobs:
         pairs:
           - from: master
             into: haskell-updates
-          - from: release-24.05
-            into: staging-next-24.05
-          - from: staging-next-24.05
-            into: staging-24.05
+          - from: release-23.11
+            into: staging-next-23.11
+          - from: staging-next-23.11
+            into: staging-23.11
     name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
 
       - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
         uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0

.github/workflows/periodic-merge-6h.yml

@@ -39,7 +39,7 @@ jobs:
             into: staging
     name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
 
       - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
         uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0

.github/workflows/update-terraform-providers.yml

@@ -16,8 +16,8 @@ jobs:
     if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
-      - uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
+      - uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633 # v4.1.2
+      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
         with:
           nix_path: nixpkgs=channel:nixpkgs-unstable
       - name: setup
@@ -46,7 +46,7 @@ jobs:
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@6cd32fd93684475c31847837f87bb135d40a2b79 # v7.0.3
+        uses: peter-evans/create-pull-request@70a41aba780001da0a30141984ae2a0c95d8704e # v6.0.2
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.

.gitignore

@@ -7,7 +7,6 @@
 .idea/
 .nixos-test-history
 .vscode/
-.helix/
 outputs/
 result-*
 result
@@ -20,8 +19,6 @@ tags
 /doc/manual.pdf
 /source/
 .version-suffix
-.direnv
-.envrc
 
 .DS_Store
 .mypy_cache

.mailmap

@@ -1,23 +1,15 @@
 ajs124 <git@ajs124.de> <ajs124@users.noreply.github.com>
 Anderson Torres <torres.anderson.85@protonmail.com>
-Atemu <git@atemu.net> <atemu.main@gmail.com>
-Christina Sørensen <christina@cafkafk.com>
-Christina Sørensen <christina@cafkafk.com> <christinaafk@gmail.com>
-Christina Sørensen <christina@cafkafk.com> <89321978+cafkafk@users.noreply.github.com>
 Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
 Fabian Affolter <mail@fabian-affolter.ch> <fabian@affolter-engineering.ch>
-goatastronaut0212 <goatastronaut0212@outlook.com> <goatastronaut0212@proton.me>
 Janne Heß <janne@hess.ooo> <dasJ@users.noreply.github.com>
 Jörg Thalheim <joerg@thalheim.io> <Mic92@users.noreply.github.com>
-Lin Jian <me@linj.tech> <linj.dev@outlook.com>
-Lin Jian <me@linj.tech> <75130626+jian-lin@users.noreply.github.com>
 Martin Weinelt <hexa@darmstadt.ccc.de> <mweinelt@users.noreply.github.com>
 R. RyanTM <ryantm-bot@ryantm.com>
 Robert Hensing <robert@roberthensing.nl> <roberth@users.noreply.github.com>
 Sandro Jäckel <sandro.jaeckel@gmail.com>
 Sandro Jäckel <sandro.jaeckel@gmail.com> <sandro.jaeckel@sap.com>
 superherointj <5861043+superherointj@users.noreply.github.com>
-Tomodachi94 <tomodachi94@protonmail.com> Tomo <68489118+Tomodachi94@users.noreply.github.com>
 Vladimír Čunát <v@cunat.cz> <vcunat@gmail.com>
 Vladimír Čunát <v@cunat.cz> <vladimir.cunat@nic.cz>
 Yifei Sun <ysun@hey.com> StepBroBD <Hi@StepBroBD.com>

CONTRIBUTING.md

@@ -315,29 +315,13 @@ When reviewing a pull request, please always be nice and polite. Controversial c
 
 GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
 
-When doing a review:
-- Aim to drive the proposal to a timely conclusion.
-- Focus on the proposed changes to keep the scope of the discussion narrow.
-- Help the contributor prioritise their efforts towards getting their change merged.
-
-If you find anything related that could be improved but is not immediately required for acceptance, consider
-- Implementing the changes yourself in a follow-up pull request (and request review from the person who inspired you)
-- Tracking your idea in an issue
-- Offering the original contributor to review a follow-up pull request
-- Making concrete [suggestions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) in the same pull request.
-
-For example, follow-up changes could involve refactoring code in the affected files.
-
-But please remember not to make such additional considerations a blocker, and communicate that to the contributor, for example by following the [conventional comments](https://conventionalcomments.org/) pattern.
-If the related change is essential for the contribution at hand, make clear why you think it is important to address that first.
-
 Pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
 
 All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
 
 To get more information about how to review specific parts of Nixpkgs, refer to the documents linked to in the [overview section][overview].
 
-If a pull request contains documentation changes that might require feedback from the documentation team, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on the pull request.
+If a pull request contains documentation changes that might require feedback from the documentation team, ping [@NixOS/documentation-reviewers](https://github.com/orgs/nixos/teams/documentation-reviewers) on the pull request.
 
 If you consider having enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints.
 
@@ -346,14 +330,7 @@ Container system, boot system and library changes are some examples of the pull
 ## How to merge pull requests
 [pr-merge]: #how-to-merge-pull-requests
 
-To streamline automated updates, leverage the nixpkgs-merge-bot by simply commenting `@NixOS/nixpkgs-merge-bot merge`. The bot will verify if the following conditions are met, refusing to merge otherwise:
-
-- the commenter that issued the command should be among the package maintainers;
-- the package should reside in `pkgs/by-name`.
-
-Further, nixpkgs-merge-bot will ensure all ofBorg checks (except the Darwin-related ones) are successfully completed before merging the pull request. Should the checks still be underway, the bot patiently waits for ofBorg to finish before attempting the merge again.
-
-For other pull requests, the *Nixpkgs committers* are people who have been given
+The *Nixpkgs committers* are people who have been given
 permission to merge.
 
 It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
@@ -370,7 +347,7 @@ The following paragraphs about how to deal with unactive contributors is just a
 Please note that contributors with commit rights unactive for more than three months will have their commit rights revoked.
 -->
 
-Please see the discussion in [GitHub nixpkgs issue #321665](https://github.com/NixOS/nixpkgs/issues/321665) for information on how to proceed to be granted this level of access.
+Please see the discussion in [GitHub nixpkgs issue #50105](https://github.com/NixOS/nixpkgs/issues/50105) for information on how to proceed to be granted this level of access.
 
 In a case a contributor definitively leaves the Nix community, they should create an issue or post on [Discourse](https://discourse.nixos.org) with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
 
@@ -382,7 +359,7 @@ See [Nix Channel Status](https://status.nixos.org/) for the current channels and
 Here's a brief overview of the main Git branches and what channels they're used for:
 
 - `master`: The main branch, used for the unstable channels such as `nixpkgs-unstable`, `nixos-unstable` and `nixos-unstable-small`.
-- `release-YY.MM` (e.g. `release-24.05`): The NixOS release branches, used for the stable channels such as `nixos-24.05`, `nixos-24.05-small` and `nixpkgs-24.05-darwin`.
+- `release-YY.MM` (e.g. `release-23.11`): The NixOS release branches, used for the stable channels such as `nixos-23.11`, `nixos-23.11-small` and `nixpkgs-23.11-darwin`.
 
 When a channel is updated, a corresponding Git branch is also updated to point to the corresponding commit.
 So e.g. the [`nixpkgs-unstable` branch](https://github.com/nixos/nixpkgs/tree/nixpkgs-unstable) corresponds to the Git commit from the [`nixpkgs-unstable` channel](https://channels.nixos.org/nixpkgs-unstable).
@@ -395,12 +372,10 @@ See [this section][branch] to know when to use the release branches.
 [staging]: #staging
 
 The staging workflow exists to batch Hydra builds of many packages together.
-It is coordinated in the [Staging room](https://matrix.to/#/#staging:nixos.org) on Matrix.
 
 It works by directing commits that cause [mass rebuilds][mass-rebuild] to a separate `staging` branch that isn't directly built by Hydra.
 Regularly, the `staging` branch is _manually_ merged into a `staging-next` branch to be built by Hydra using the [`nixpkgs:staging-next` jobset](https://hydra.nixos.org/jobset/nixpkgs/staging-next).
-The `staging-next` branch should then only receive changes that fix Hydra builds;
-**for anything else, ask the [Staging room](https://matrix.to/#/#staging:nixos.org) first**.
+The `staging-next` branch should then only receive direct commits in order to fix Hydra builds.
 Once it is verified that there are no major regressions, it is merged into `master` using [a pull request](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
 This is done manually in order to ensure it's a good use of Hydra's computing resources.
 By keeping the `staging-next` branch separate from `staging`, this batching does not block developers from merging changes into `staging`.
@@ -537,7 +512,6 @@ To get a sense for what changes are considered mass rebuilds, see [previously me
 - Check for unnecessary whitespace with `git diff --check` before committing.
 
 - If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`.
-  See [Squashing Commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) for additional information.
 
 - For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
 
@@ -573,28 +547,151 @@ Names of files and directories should be in lowercase, with dashes between words
 
 ### Syntax
 
-- Set up [editorconfig](https://editorconfig.org/) for your editor, such that [the settings](./.editorconfig) are automatically applied.
+- Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
+
+- Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use `(setq-default indent-tabs-mode nil)` in Emacs. Everybody has different tab settings so it’s asking for trouble.
 
 - Use `lowerCamelCase` for variable names, not `UpperCamelCase`. Note, this rule does not apply to package attribute names, which instead follow the rules in [package naming](./pkgs/README.md#package-naming).
 
-- New files must be formatted by entering the `nix-shell` from the repository root and running `nixfmt`.
-
-- Functions should list their expected arguments as precisely as possible. That is, write
+- Function calls with attribute set arguments are written as
 
   ```nix
-  { stdenv, fetchurl, perl }: <...>
+  foo {
+    arg = ...;
+  }
   ```
 
-  instead of
+  not
 
   ```nix
-  args: with args; <...>
+  foo
+  {
+    arg = ...;
+  }
+  ```
+
+  Also fine is
+
+  ```nix
+  foo { arg = ...; }
+  ```
+
+  if it's a short call.
+
+- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
+
+  ```nix
+  # A long list.
+  list = [
+    elem1
+    elem2
+    elem3
+  ];
+
+  # A long attribute set.
+  attrs = {
+    attr1 = short_expr;
+    attr2 =
+      if true then big_expr else big_expr;
+  };
+
+  # Combined
+  listOfAttrs = [
+    {
+      attr1 = 3;
+      attr2 = "fff";
+    }
+    {
+      attr1 = 5;
+      attr2 = "ggg";
+    }
+  ];
+  ```
+
+- Short lists or attribute sets can be written on one line:
+
+  ```nix
+  # A short list.
+  list = [ elem1 elem2 elem3 ];
+
+  # A short set.
+  attrs = { x = 1280; y = 1024; };
+  ```
+
+- Breaking in the middle of a function argument can give hard-to-read code, like
+
+  ```nix
+  someFunction { x = 1280;
+    y = 1024; } otherArg
+    yetAnotherArg
+  ```
+
+  (especially if the argument is very large, spanning multiple lines).
+
+  Better:
+
+  ```nix
+  someFunction
+    { x = 1280; y = 1024; }
+    otherArg
+    yetAnotherArg
   ```
 
   or
 
   ```nix
-  { stdenv, fetchurl, perl, ... }: <...>
+  let res = { x = 1280; y = 1024; };
+  in someFunction res otherArg yetAnotherArg
+  ```
+
+- The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.
+
+  ```nix
+  { arg1, arg2 }:
+  assert system == "i686-linux";
+  stdenv.mkDerivation { ...
+  ```
+
+  not
+
+  ```nix
+  { arg1, arg2 }:
+    assert system == "i686-linux";
+      stdenv.mkDerivation { ...
+  ```
+
+- Function formal arguments are written as:
+
+  ```nix
+  { arg1, arg2, arg3 }:
+  ```
+
+  but if they don't fit on one line they're written as:
+
+  ```nix
+  { arg1, arg2, arg3
+  , arg4, ...
+  , # Some comment...
+    argN
+  }:
+  ```
+
+- Functions should list their expected arguments as precisely as possible. That is, write
+
+  ```nix
+  { stdenv, fetchurl, perl }: ...
+  ```
+
+  instead of
+
+  ```nix
+  args: with args; ...
+  ```
+
+  or
+
+  ```nix
+  { stdenv, fetchurl, perl, ... }: ...
   ```
 
   For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
@@ -603,7 +700,7 @@ Names of files and directories should be in lowercase, with dashes between words
   { stdenv, doCoverageAnalysis ? false, ... } @ args:
 
   stdenv.mkDerivation (args // {
-    foo = if doCoverageAnalysis then "bla" else "";
+    ... if doCoverageAnalysis then "bla" else "" ...
   })
   ```
 
@@ -613,40 +710,32 @@ Names of files and directories should be in lowercase, with dashes between words
   args:
 
   args.stdenv.mkDerivation (args // {
-    foo = if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "";
+    ... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
   })
   ```
 
 - Unnecessary string conversions should be avoided. Do
 
   ```nix
-  {
-    rev = version;
-  }
+  rev = version;
   ```
 
   instead of
 
   ```nix
-  {
-    rev = "${version}";
-  }
+  rev = "${version}";
   ```
 
 - Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
 
   ```nix
-  {
-    buildInputs = lib.optional stdenv.isDarwin iconv;
-  }
+  buildInputs = lib.optional stdenv.isDarwin iconv;
   ```
 
   instead of
 
   ```nix
-  {
-    buildInputs = if stdenv.isDarwin then [ iconv ] else null;
-  }
+  buildInputs = if stdenv.isDarwin then [ iconv ] else null;
   ```
 
   As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.

README.md

@@ -1,9 +1,9 @@
 <p align="center">
   <a href="https://nixos.org">
     <picture>
-      <source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
+      <source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png">
       <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
-      <img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="500px" alt="NixOS logo">
+      <img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo">
     </picture>
   </a>
 </p>
@@ -14,7 +14,7 @@
 </p>
 
 [Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over
-100,000 software packages that can be installed with the
+80,000 software packages that can be installed with the
 [Nix](https://nixos.org/nix/) package manager. It also implements
 [NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
 
@@ -29,8 +29,8 @@
 * [Discourse Forum](https://discourse.nixos.org/)
 * [Matrix Chat](https://matrix.to/#/#community:nixos.org)
 * [NixOS Weekly](https://weekly.nixos.org/)
-* [Official wiki](https://wiki.nixos.org/)
-* [Community-maintained list of ways to get in touch](https://wiki.nixos.org/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
+* [Community-maintained wiki](https://nixos.wiki/)
+* [Community-maintained list of ways to get in touch](https://nixos.wiki/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
 
 # Other Project Repositories
 
@@ -52,9 +52,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 24.05 release](https://hydra.nixos.org/jobset/nixos/release-24.05)
+* [Continuous package builds for the NixOS 23.11 release](https://hydra.nixos.org/jobset/nixos/release-23.11)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 24.05 release](https://hydra.nixos.org/job/nixos/release-24.05/tested#tabs-constituents)
+* [Tests for the NixOS 23.11 release](https://hydra.nixos.org/job/nixos/release-23.11/tested#tabs-constituents)
 
 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are

ci/README.md

@@ -1,43 +0,0 @@
-# CI support files
-
-This directory contains files to support CI, such as [GitHub Actions](https://github.com/NixOS/nixpkgs/tree/master/.github/workflows) and [Ofborg](https://github.com/nixos/ofborg).
-This is in contrast with [`maintainers/scripts`](../maintainers/scripts) which is for human use instead.
-
-## Pinned Nixpkgs
-
-CI may need certain packages from Nixpkgs.
-In order to ensure that the needed packages are generally available without building,
-[`pinned-nixpkgs.json`](./pinned-nixpkgs.json) contains a pinned Nixpkgs version tested by Hydra.
-
-Run [`update-pinned-nixpkgs.sh`](./update-pinned-nixpkgs.sh) to update it.
-
-## `ci/nixpkgs-vet.sh BASE_BRANCH [REPOSITORY]`
-
-Runs the [`nixpkgs-vet` tool](https://github.com/NixOS/nixpkgs-vet) on the HEAD commit, closely matching what CI does. This can't do exactly the same as CI, because CI needs to rely on GitHub's server-side Git history to compute the mergeability of PRs before the check can be started.
-In turn, when contributors are running this tool locally, we don't want to have to push commits to test them, and we can also rely on the local Git history to do the mergeability check.
-
-Arguments:
-
-- `BASE_BRANCH`: The base branch to use, e.g. master or release-24.05
-- `REPOSITORY`: The repository from which to fetch the base branch. Defaults to <https://github.com/NixOS/nixpkgs.git>.
-
-## `ci/nixpkgs-vet`
-
-This directory contains scripts and files used and related to [`nixpkgs-vet`](https://github.com/NixOS/nixpkgs-vet/), which the CI uses to implement `pkgs/by-name` checks, along with many other Nixpkgs architecture rules.
-See also the [CI GitHub Action](../.github/workflows/nixpkgs-vet.yml).
-
-## `ci/nixpkgs-vet/update-pinned-tool.sh`
-
-Updates the pinned [`nixpkgs-vet` tool](https://github.com/NixOS/nixpkgs-vet) in [`ci/nixpkgs-vet/pinned-version.txt`](./nixpkgs-vet/pinned-version.txt) to the latest [release](https://github.com/NixOS/nixpkgs-vet/releases).
-
-Each release contains a pre-built `x86_64-linux` version of the tool which is used by CI.
-
-This script currently needs to be called manually when the CI tooling needs to be updated.
-
-Why not just build the tooling right from the PRs Nixpkgs version?
-
-- Because it allows CI to check all PRs, even if they would break the CI tooling.
-- Because it makes the CI check very fast, since no Nix builds need to be done, even for mass rebuilds.
-- Because it improves security, since we don't have to build potentially untrusted code from PRs.
-  The tool only needs a very minimal Nix evaluation at runtime, which can work with [readonly-mode](https://nixos.org/manual/nix/stable/command-ref/opt-common.html#opt-readonly-mode) and [restrict-eval](https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-restrict-eval).
-

ci/nixpkgs-vet.sh

@@ -1,71 +0,0 @@
-#!/usr/bin/env nix-shell
-#!nix-shell -i bash -p jq
-
-set -o pipefail -o errexit -o nounset
-
-trace() { echo >&2 "$@"; }
-
-tmp=$(mktemp -d)
-cleanup() {
-    # Don't exit early if anything fails to cleanup
-    set +o errexit
-
-    trace -n "Cleaning up.. "
-
-    [[ -e "$tmp/base" ]] && git worktree remove --force "$tmp/base"
-    [[ -e "$tmp/merged" ]] && git worktree remove --force "$tmp/merged"
-
-    rm -rf "$tmp"
-
-    trace "Done"
-}
-trap cleanup exit
-
-
-repo=https://github.com/NixOS/nixpkgs.git
-
-if (( $# != 0 )); then
-    baseBranch=$1
-    shift
-else
-    trace "Usage: $0 BASE_BRANCH [REPOSITORY]"
-    trace "BASE_BRANCH: The base branch to use, e.g. master or release-23.11"
-    trace "REPOSITORY: The repository to fetch the base branch from, defaults to $repo"
-    exit 1
-fi
-
-if (( $# != 0 )); then
-    repo=$1
-    shift
-fi
-
-if [[ -n "$(git status --porcelain)" ]]; then
-    trace -e "\e[33mWarning: Dirty tree, uncommitted changes won't be taken into account\e[0m"
-fi
-headSha=$(git rev-parse HEAD)
-trace -e "Using HEAD commit \e[34m$headSha\e[0m"
-
-trace -n "Creating Git worktree for the HEAD commit in $tmp/merged.. "
-git worktree add --detach -q "$tmp/merged" HEAD
-trace "Done"
-
-trace -n "Fetching base branch $baseBranch to compare against.. "
-git fetch -q "$repo" refs/heads/"$baseBranch"
-baseSha=$(git rev-parse FETCH_HEAD)
-trace -e "\e[34m$baseSha\e[0m"
-
-trace -n "Creating Git worktree for the base branch in $tmp/base.. "
-git worktree add -q "$tmp/base" "$baseSha"
-trace "Done"
-
-trace -n "Merging base branch into the HEAD commit in $tmp/merged.. "
-git -C "$tmp/merged" merge -q --no-edit "$baseSha"
-trace -e "\e[34m$(git -C "$tmp/merged" rev-parse HEAD)\e[0m"
-trace -n "Reading pinned nixpkgs-vet version from pinned-version.txt.. "
-toolVersion=$(<"$tmp/merged/ci/nixpkgs-vet/pinned-version.txt")
-trace -e "\e[34m$toolVersion\e[0m"
-
-trace -n "Building tool.. "
-nix-build https://github.com/NixOS/nixpkgs-vet/tarball/"$toolVersion" -o "$tmp/tool" -A build
-trace "Running nixpkgs-vet.."
-"$tmp/tool/bin/nixpkgs-vet" --base "$tmp/base" "$tmp/merged"

ci/nixpkgs-vet/pinned-version.txt

@@ -1 +0,0 @@
-0.1.4

ci/nixpkgs-vet/update-pinned-tool.sh

@@ -1,22 +0,0 @@
-#!/usr/bin/env nix-shell
-#!nix-shell -i bash -p jq curl
-
-set -o pipefail -o errexit -o nounset
-
-trace() { echo >&2 "$@"; }
-
-SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
-
-repository=NixOS/nixpkgs-vet
-pin_file=$SCRIPT_DIR/pinned-version.txt
-
-trace -n "Fetching latest release of $repository.. "
-latestRelease=$(curl -sSfL \
-  -H "Accept: application/vnd.github+json" \
-  -H "X-GitHub-Api-Version: 2022-11-28" \
-  https://api.github.com/repos/"$repository"/releases/latest)
-latestVersion=$(jq .tag_name -r <<< "$latestRelease")
-trace "$latestVersion"
-
-trace "Updating $pin_file"
-echo "$latestVersion" > "$pin_file"

ci/pinned-nixpkgs.json

@@ -1,4 +0,0 @@
-{
-  "rev": "4de4818c1ffa76d57787af936e8a23648bda6be4",
-  "sha256": "0l3b9jr5ydzqgvd10j12imc9jqb6jv5v2bdi1gyy5cwkwplfay67"
-}

ci/update-pinned-nixpkgs.sh

@@ -1,17 +0,0 @@
-#!/usr/bin/env nix-shell
-#!nix-shell -i bash -p jq
-
-set -euo pipefail
-
-# https://stackoverflow.com/a/246128
-SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
-
-repo=https://github.com/nixos/nixpkgs
-branch=nixpkgs-unstable
-file=$SCRIPT_DIR/pinned-nixpkgs.json
-
-defaultRev=$(git ls-remote "$repo" refs/heads/"$branch" | cut -f1)
-rev=${1:-$defaultRev}
-sha256=$(nix-prefetch-url --unpack "$repo/archive/$rev.tar.gz" --name source)
-
-jq -n --arg rev "$rev" --arg sha256 "$sha256" '$ARGS.named' | tee /dev/stderr > $file

doc/README.md

@@ -2,20 +2,10 @@
 
 This directory houses the sources files for the Nixpkgs reference manual.
 
-> [!IMPORTANT]
-> We are actively restructuring our documentation to follow the [Diátaxis framework](https://diataxis.fr/)
->
-> Going forward, this directory should **only** contain [reference documentation](https://nix.dev/contributing/documentation/diataxis#reference).
-> For tutorials, guides and explanations, contribute to <https://nix.dev/> instead.
->
-> We are actively working to generate **all** reference documentation from the [doc-comments](https://github.com/NixOS/rfcs/blob/master/rfcs/0145-doc-strings.md) present in code.
-> This also provides the benefit of using `:doc` in the `nix repl` to view reference documentation locally on the fly.
+Going forward, it should only contain [reference](https://nix.dev/contributing/documentation/diataxis#reference) documentation.
+For tutorials, guides and explanations, contribute to <https://nix.dev/> instead.
 
-For documentation only relevant for contributors, use Markdown files next to the source and regular code comments.
-
-> [!TIP]
-> Feedback for improving support for parsing and rendering doc-comments is highly appreciated.
-> [Open an issue](https://github.com/NixOS/nixpkgs/issues/new?labels=6.topic%3A+documentation&title=Doc%3A+) to request bugfixes or new features.
+For documentation only relevant for contributors, use Markdown files and code comments in the source code.
 
 Rendered documentation:
 - [Unstable (from master)](https://nixos.org/manual/nixpkgs/unstable/)
@@ -72,7 +62,7 @@ Allow linking arbitrary place in the text (e.g. individual list items, sentences
 They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called [bracketed spans](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/bracketed_spans.md):
 
 ```markdown
-- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGApps*` hook will prepend it to `XDG_DATA_DIRS`.
+- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
 ```
 
 #### Automatic links
@@ -116,12 +106,12 @@ This is a warning
 
 The following are supported:
 
-- `caution`
-- `important`
-- `note`
-- `tip`
-- `warning`
-- `example`
+- [`caution`](https://tdg.docbook.org/tdg/5.0/caution.html)
+- [`important`](https://tdg.docbook.org/tdg/5.0/important.html)
+- [`note`](https://tdg.docbook.org/tdg/5.0/note.html)
+- [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
+- [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
+- [`example`](https://tdg.docbook.org/tdg/5.0/example.html)
 
 Example admonitions require a title to work.
 If you don't provide one, the manual won't be built.
@@ -261,42 +251,25 @@ You, as the writer of documentation, are still in charge of its content.
   For example:
 
   ```markdown
-  # pkgs.coolFunction {#pkgs.coolFunction}
+  # pkgs.coolFunction
 
-  `pkgs.coolFunction` *`name`* *`config`*
+  Description of what `coolFunction` does.
 
-  Description of what `callPackage` does.
+  ## Inputs
 
+  `coolFunction` expects a single argument which should be an attribute set, with the following possible attributes:
 
-  ## Inputs {#pkgs-coolFunction-inputs}
-
-  If something's special about `coolFunction`'s general argument handling, you can say so here.
-  Otherwise, just describe the single argument or start the arguments' definition list without introduction.
-
-  *`name`* (String)
+  `name` (String)
 
   : The name of the resulting image.
 
-  *`config`* (Attribute set)
+  `tag` (String; _optional_)
 
-  : Introduce the parameter. Maybe you have a test to make sure `{ }` is a sensible default; then you can say: these attributes are optional; `{ }` is a valid argument.
+  : Tag of the generated image.
 
-    `outputHash` (String; _optional_)
-
-    : A brief explanation including when and when not to pass this attribute.
-
-    : _Default:_ the output path's hash.
+    _Default:_ the output path's hash.
   ```
 
-  Checklist:
-  - Start with a synopsis, to show the order of positional arguments.
-  - Metavariables are in emphasized code spans: ``` *`arg1`* ```. Metavariables are placeholders where users may write arbitrary expressions. This includes positional arguments.
-  - Attribute names are regular code spans: ``` `attr1` ```. These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
-  - _optional_ attributes have a _`Default:`_ if it's easily described as a value.
-  - _optional_ attributes have a _`Default behavior:`_ if it's not easily described using a value.
-  - Nix types aren't in code spans, because they are not code
-  - Nix types are capitalized, to distinguish them from the camelCase Module System types, which _are_ code and behave like functions.
-
 #### Examples
 
 To define a referenceable figure use the following fencing:
@@ -320,7 +293,7 @@ Though this is not shown in the rendered documentation on nixos.org.
 
 #### Figures
 
-To define a referenceable figure use the following fencing:
+To define a referencable figure use the following fencing:
 
 ```markdown
 ::: {.figure #nixos-logo}
@@ -372,4 +345,4 @@ Typographic replacements are enabled. Check the [list of possible replacement pa
 
 ## Getting help
 
-If you need documentation-specific help or reviews, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on your pull request.
+If you need documentation-specific help or reviews, ping [@NixOS/documentation-reviewers](https://github.com/orgs/nixos/teams/documentation-reviewers) on your pull request.

doc/build-helpers.md

@@ -20,7 +20,6 @@ There is no uniform interface for build helpers.
 build-helpers/fetchers.chapter.md
 build-helpers/trivial-build-helpers.chapter.md
 build-helpers/testers.chapter.md
-build-helpers/dev-shell-tools.chapter.md
 build-helpers/special.md
 build-helpers/images.md
 hooks/index.md

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

@@ -1,75 +0,0 @@
-# Development Shell helpers {#chap-devShellTools}
-
-The `nix-shell` command has popularized the concept of transient shell environments for development or testing purposes.
-<!--
-  We should try to document the product, not its development process in the Nixpkgs reference manual,
-  but *something* needs to be said to provide context for this library.
-  This is the most future proof sentence I could come up with while Nix itself does yet make use of this.
-  Relevant is the current status of the devShell attribute "project": https://github.com/NixOS/nix/issues/7501
-  -->
-However, `nix-shell` is not the only way to create such environments, and even `nix-shell` itself can indirectly benefit from this library.
-
-This library provides a set of functions that help create such environments.
-
-## `devShellTools.valueToString` {#sec-devShellTools-valueToString}
-
-Converts Nix values to strings in the way the [`derivation` built-in function](https://nix.dev/manual/nix/2.23/language/derivations) does.
-
-:::{.example}
-## `valueToString` usage examples
-
-```nix
-devShellTools.valueToString (builtins.toFile "foo" "bar")
-=> "/nix/store/...-foo"
-```
-
-```nix
-devShellTools.valueToString false
-=> ""
-```
-
-:::
-
-## `devShellTools.unstructuredDerivationInputEnv` {#sec-devShellTools-unstructuredDerivationInputEnv}
-
-Convert a set of derivation attributes (as would be passed to [`derivation`]) to a set of environment variables that can be used in a shell script.
-This function does not support `__structuredAttrs`, but does support `passAsFile`.
-
-:::{.example}
-## `unstructuredDerivationInputEnv` usage example
-
-```nix
-devShellTools.unstructuredDerivationInputEnv {
-  drvAttrs = {
-    name = "foo";
-    buildInputs = [ hello figlet ];
-    builder = bash;
-    args = [ "-c" "${./builder.sh}" ];
-  };
-}
-=> {
-  name = "foo";
-  buildInputs = "/nix/store/...-hello /nix/store/...-figlet";
-  builder = "/nix/store/...-bash";
-}
-```
-
-Note that `args` is not included, because Nix does not added it to the builder process environment.
-
-:::
-
-## `devShellTools.derivationOutputEnv` {#sec-devShellTools-derivationOutputEnv}
-
-Takes the relevant parts of a derivation and returns a set of environment variables, that would be present in the derivation.
-
-:::{.example}
-## `derivationOutputEnv` usage example
-
-```nix
-let
-  pkg = hello;
-in
-devShellTools.derivationOutputEnv { outputList = pkg.outputs; outputMap = pkg; }
-```
-
-:::

doc/build-helpers/fetchers.chapter.md

@@ -1,687 +1,88 @@
 # Fetchers {#chap-pkgs-fetchers}
 
 Building software with Nix often requires downloading source code and other files from the internet.
-To this end, we use functions that we call _fetchers_, which obtain remote sources via various protocols and services.
-
-Nix provides built-in fetchers such as [`builtins.fetchTarball`](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-fetchTarball).
-Nixpkgs provides its own fetchers, which work differently:
+To this end, Nixpkgs provides *fetchers*: functions to obtain remote sources via various protocols and services.
 
+Nixpkgs fetchers differ from built-in fetchers such as [`builtins.fetchTarball`](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-fetchTarball):
 - A built-in fetcher will download and cache files at evaluation time and produce a [store path](https://nixos.org/manual/nix/stable/glossary#gloss-store-path).
-  A Nixpkgs fetcher will create a ([fixed-output](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation)) [derivation](https://nixos.org/manual/nix/stable/glossary#gloss-derivation), and files are downloaded at build time.
+  A Nixpkgs fetcher will create a ([fixed-output](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation)) [derivation](https://nixos.org/manual/nix/stable/language/derivations), and files are downloaded at build time.
 - Built-in fetchers will invalidate their cache after [`tarball-ttl`](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-tarball-ttl) expires, and will require network activity to check if the cache entry is up to date.
-  Nixpkgs fetchers only re-download if the specified hash changes or the store object is not available.
+  Nixpkgs fetchers only re-download if the specified hash changes or the store object is not otherwise available.
 - Built-in fetchers do not use [substituters](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-substituters).
   Derivations produced by Nixpkgs fetchers will use any configured binary cache transparently.
 
-This significantly reduces the time needed to evaluate Nixpkgs, and allows [Hydra](https://nixos.org/hydra) to retain and re-distribute sources used by Nixpkgs in the [public binary cache](https://cache.nixos.org).
-For these reasons, Nix's built-in fetchers are not allowed in Nixpkgs.
+This significantly reduces the time needed to evaluate the entirety of Nixpkgs, and allows [Hydra](https://nixos.org/hydra) to retain and re-distribute sources used by Nixpkgs in the [public binary cache](https://cache.nixos.org).
+For these reasons, built-in fetchers are not allowed in Nixpkgs source code.
 
-The following table summarises the differences:
+The following table shows an overview of the differences:
 
 | Fetchers | Download | Output | Cache | Re-download when |
 |-|-|-|-|-|
 | `builtins.fetch*` | evaluation time | store path | `/nix/store`, `~/.cache/nix` | `tarball-ttl` expires, cache miss in `~/.cache/nix`, output store object not in local store |
 | `pkgs.fetch*` | build time | derivation | `/nix/store`, substituters | output store object not available |
 
-:::{.tip}
-`pkgs.fetchFrom*` helpers retrieve _snapshots_ of version-controlled sources, as opposed to the entire version history, which is more efficient.
-`pkgs.fetchgit` by default also has the same behaviour, but can be changed through specific attributes given to it.
-:::
-
 ## Caveats {#chap-pkgs-fetchers-caveats}
 
-Because Nixpkgs fetchers are fixed-output derivations, an [output hash](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-outputHash) has to be specified, usually indirectly through a `hash` attribute.
-This hash refers to the derivation output, which can be different from the remote source itself!
-
-This has the following implications that you should be aware of:
-
-- Use Nix (or Nix-aware) tooling to produce the output hash.
-
-- When changing any fetcher parameters, always update the output hash.
-  Use one of the methods from [](#sec-pkgs-fetchers-updating-source-hashes).
-  Otherwise, existing store objects that match the output hash will be re-used rather than fetching new content.
-
-  :::{.note}
-  A similar problem arises while testing changes to a fetcher's implementation.
-  If the output of the derivation already exists in the Nix store, test failures can go undetected.
-  The [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function helps prevent reusing cached derivations.
-  :::
-
-## Updating source hashes {#sec-pkgs-fetchers-updating-source-hashes}
-
-There are several ways to obtain the hash corresponding to a remote source.
-Unless you understand how the fetcher you're using calculates the hash from the downloaded contents, you should use [the fake hash method](#sec-pkgs-fetchers-updating-source-hashes-fakehash-method).
-
-1. []{#sec-pkgs-fetchers-updating-source-hashes-fakehash-method} The fake hash method: In your package recipe, set the hash to one of
-
-   - `""`
-   - `lib.fakeHash`
-   - `lib.fakeSha256`
-   - `lib.fakeSha512`
-
-   Attempt to build, extract the calculated hashes from error messages, and put them into the recipe.
-
-   :::{.warning}
-   You must use one of these four fake hashes and not some arbitrarily-chosen hash.
-   See [](#sec-pkgs-fetchers-secure-hashes) for details.
-   :::
-
-   :::{.example #ex-fetchers-update-fod-hash}
-   # Update source hash with the fake hash method
-
-   Consider the following recipe that produces a plain file:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.05/.version";
-     hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM=";
-   }
-   ```
-
-   A common mistake is to update a fetcher parameter, such as `url`, without updating the hash:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-     hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM=";
-   }
-   ```
-
-   **This will produce the same output as before!**
-   Set the hash to an empty string:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-     hash = "";
-   }
-   ```
-
-   When building the package, use the error message to determine the correct hash:
-
-   ```shell
-   $ nix-build
-   (some output removed for clarity)
-   error: hash mismatch in fixed-output derivation '/nix/store/7yynn53jpc93l76z9zdjj4xdxgynawcw-version.drv':
-           specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-               got:    sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=
-   error: build of '/nix/store/bqdjcw5ij5ymfbm41dq230chk9hdhqff-version.drv' failed
-   ```
-   :::
-
-2. Prefetch the source with [`nix-prefetch-<type> <URL>`](https://search.nixos.org/packages?buckets={%22package_attr_set%22%3A[%22No%20package%20set%22]%2C%22package_license_set%22%3A[]%2C%22package_maintainers_set%22%3A[]%2C%22package_platforms%22%3A[]}&query=nix-prefetch), where `<type>` is one of
-
-   - `url`
-   - `git`
-   - `hg`
-   - `cvs`
-   - `bzr`
-   - `svn`
-
-   The hash is printed to stdout.
-
-3. Prefetch by package source (with `nix-prefetch-url '<nixpkgs>' -A <package>.src`, where `<package>` is package attribute name).
-   The hash is printed to stdout.
-
-   This works well when you've upgraded the existing package version and want to find out new hash, but is useless if the package can't be accessed by attribute or the package has multiple sources (`.srcs`, architecture-dependent sources, etc).
-
-4. Upstream hash: use it when upstream provides `sha256` or `sha512`.
-   Don't use it when upstream provides `md5`, compute `sha256` instead.
-
-   A little nuance is that `nix-prefetch-*` tools produce hashes with the `nix32` encoding (a Nix-specific base32 adaptation), but upstream usually provides hexadecimal (`base16`) encoding.
-   Fetchers understand both formats.
-   Nixpkgs does not standardise on any one format.
-
-   You can convert between hash formats with [`nix-hash`](https://nixos.org/manual/nix/stable/command-ref/nix-hash).
-
-5. Extract the hash from a local source archive with `sha256sum`.
-   Use `nix-prefetch-url file:///path/to/archive` if you want the custom Nix `base32` hash.
-
-## Obtaining hashes securely {#sec-pkgs-fetchers-secure-hashes}
-
-It's always a good idea to avoid Man-in-the-Middle (MITM) attacks when downloading source contents.
-Otherwise, you could unknowingly download malware instead of the intended source, and instead of the actual source hash, you'll end up using the hash of malware.
-Here are security considerations for this scenario:
-
-- `http://` URLs are not secure to prefetch hashes.
-
-- Upstream hashes should be obtained via a secure protocol.
-
-- `https://` URLs give you more protections when using `nix-prefetch-*` or for upstream hashes.
-
-- `https://` URLs are secure when using the [fake hash method](#sec-pkgs-fetchers-updating-source-hashes-fakehash-method) *only if* you use one of the listed fake hashes.
-  If you use any other hash, the download will be exposed to MITM attacks even if you use HTTPS URLs.
-
-  In more concrete terms, if you use any other hash, the [`--insecure` flag](https://curl.se/docs/manpage.html#-k) will be passed to the underlying call to `curl` when downloading content.
-
-## Proxy usage {#sec-pkgs-fetchers-proxy}
-
-Nixpkgs fetchers can make use of a http(s) proxy. Each fetcher will automatically inherit proxy-related environment variables (`http_proxy`, `https_proxy`, etc) via [impureEnvVars](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-impureEnvVars).
-
-The environment variable `NIX_SSL_CERT_FILE` is also inherited in fetchers, and can be used to provide a custom certificate bundle to fetchers. This is usually required for a https proxy to work without certificate validation errors.
-
-[]{#fetchurl}
-## `fetchurl` {#sec-pkgs-fetchers-fetchurl}
-
-`fetchurl` returns a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary.html#gloss-fixed-output-derivation) which downloads content from a given URL and stores the unaltered contents within the Nix store.
-
-It uses {manpage}`curl(1)` internally, and allows its behaviour to be modified by specifying a few attributes in the argument to `fetchurl` (see the documentation for attributes `curlOpts`, `curlOptsList`, and `netrcPhase`).
-
-The resulting [store path](https://nixos.org/manual/nix/stable/store/store-path) is determined by the hash given to `fetchurl`, and also the `name` (or `pname` and `version`) values.
-
-If neither `name` nor `pname` and `version` are specified when calling `fetchurl`, it will default to using the [basename](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-baseNameOf) of `url` or the first element of `urls`.
-If `pname` and `version` are specified, `fetchurl` will use those values and will ignore `name`, even if it is also specified.
-
-### Inputs {#sec-pkgs-fetchers-fetchurl-inputs}
-
-`fetchurl` requires an attribute set with the following attributes:
-
-`url` (String; _optional_)
-: The URL to download from.
-
-  :::{.note}
-  Either `url` or `urls` must be specified, but not both.
-  :::
-
-  All URLs of the format [specified here](https://curl.se/docs/url-syntax.html#rfc-3986-plus) are supported.
-
-  _Default value:_ `""`.
-
-`urls` (List of String; _optional_)
-: A list of URLs, specifying download locations for the same content.
-  Each URL will be tried in order until one of them succeeds with some content or all of them fail.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-multiple-urls) to understand how this attribute affects the behaviour of `fetchurl`.
-
-  :::{.note}
-  Either `url` or `urls` must be specified, but not both.
-  :::
-
-  _Default value:_ `[]`.
-
-`hash` (String; _optional_)
-: Hash of the derivation output of `fetchurl`, following the format for integrity metadata as defined by [SRI](https://www.w3.org/TR/SRI/).
-  For more information, see [](#chap-pkgs-fetchers-caveats).
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead of the other hash-specific attributes that exist for backwards compatibility.
-
-  If `hash` is not specified, you must specify `outputHash` and `outputHashAlgo`, or one of `sha512`, `sha256`, or `sha1`.
-  :::
-
-  _Default value:_ `""`.
-
-`outputHash` (String; _optional_)
-: Hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-
-  If `outputHash` is specified, you must also specify `outputHashAlgo`.
-  :::
-
-  _Default value:_ `""`.
-
-`outputHashAlgo` (String; _optional_)
-: Algorithm used to generate the value specified in `outputHash`.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHashAlgo) for more information about the values it supports.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-
-  The value specified in `outputHashAlgo` will be ignored if `outputHash` isn't also specified.
-  :::
-
-  _Default value:_ `""`.
-
-`sha1` (String; _optional_)
-: SHA-1 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`sha256` (String; _optional_)
-: SHA-256 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`sha512` (String; _optional_)
-: SHA-512 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`name` (String; _optional_)
-: The symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  _Default value:_ `""`.
-
-`pname` (String; _optional_)
-: A base name, which will be combined with `version` to form the symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  :::{.note}
-  If `pname` is specified, you must also specify `version`, otherwise `fetchurl` will ignore the value of `pname`.
-  :::
-
-  _Default value:_ `""`.
-
-`version` (String; _optional_)
-: A version, which will be combined with `pname` to form the symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  _Default value:_ `""`.
-
-`recursiveHash` (Boolean; _optional_) []{#sec-pkgs-fetchers-fetchurl-inputs-recursiveHash}
-: If set to `true`, will signal to Nix that the hash given to `fetchurl` was calculated using the `"recursive"` mode.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHashMode) for more information about the existing modes.
-
-  By default, `fetchurl` uses `"recursive"` mode when the `executable` attribute is set to `true`, so you don't need to specify `recursiveHash` in this case.
-
-  _Default value:_ `false`.
-
-`executable` (Boolean; _optional_)
-: If `true`, sets the executable bit on the downloaded file.
-
-  _Default value_: `false`.
-
-`downloadToTemp` (Boolean; _optional_) []{#sec-pkgs-fetchers-fetchurl-inputs-downloadToTemp}
-: If `true`, saves the downloaded file to a temporary location instead of the expected Nix store location.
-  This is useful when used in conjunction with `postFetch` attribute, otherwise `fetchurl` will not produce any meaningful output.
-
-  The location of the downloaded file will be set in the `$downloadedFile` variable, which should be used by the script in the `postFetch` attribute.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how to work with this attribute.
-
-  _Default value:_ `false`.
-
-`postFetch` (String; _optional_)
-: Script executed after the file has been downloaded successfully, and before `fetchurl` finishes running.
-  Useful for post-processing, to check or transform the file in some way.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how to work with this attribute.
-
-  _Default value:_ `""`.
-
-`netrcPhase` (String or Null; _optional_)
-: Script executed to create a {manpage}`netrc(5)` file to be used with {manpage}`curl(1)`.
-  The script should create the `netrc` file (note that it does not begin with a ".") in the directory it's currently running in (`$PWD`).
-
-  The script is executed during the setup done by `fetchurl` before it runs any of its code to download the specified content.
-
-  :::{.note}
-  If specified, `fetchurl` will automatically alter its invocation of {manpage}`curl(1)` to use the `netrc` file, so you don't need to add anything to `curlOpts` or `curlOptsList`.
-  :::
-
-  :::{.caution}
-  Since `netrcPhase` needs to be specified in your source Nix code, any secrets that you put directly in it will be world-readable by design (both in your source code, and when the derivation gets created in the Nix store).
-
-  If you want to avoid this behaviour, see the documentation of `netrcImpureEnvVars` for an alternative way of dealing with these secrets.
-  :::
-
-  _Default value_: `null`.
-
-`netrcImpureEnvVars` (List of String; _optional_)
-: If specified, `fetchurl` will add these environment variable names to the list of [impure environment variables](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-impureEnvVars), which will be passed from the environment of the calling user to the builder running the `fetchurl` code.
-
-  This is useful when used with `netrcPhase` to hide any secrets that are used in it, because the script in `netrcPhase` only needs to reference the environment variables with the secrets in them instead.
-  However, note that these are called _impure_ variables for a reason:
-  the environment that starts the build needs to have these variables declared for everything to work properly, which means that additional setup is required outside what Nix controls.
-
-  _Default value:_ `[]`.
-
-`curlOpts` (String; _optional_)
-: If specified, this value will be appended to the invocation of {manpage}`curl(1)` when downloading the URL(s) given to `fetchurl`.
-  Multiple arguments can be separated by spaces normally, but values with whitespaces will be interpreted as multiple arguments (instead of a single value), even if the value is escaped.
-  See `curlOptsList` for a way to pass values with whitespaces in them.
-
-  _Default value:_ `""`.
-
-`curlOptsList` (List of String; _optional_)
-: If specified, each element of this list will be passed as an argument to the invocation of {manpage}`curl(1)` when downloading the URL(s) given to `fetchurl`.
-  This allows passing values that contain spaces, with no escaping needed.
-
-  _Default value:_ `[]`.
-
-`showURLs` (Boolean; _optional_)
-: If set to `true`, this will stop `fetchurl` from downloading anything at all.
-  Instead, it will output a list of all the URLs it would've used to download the content (after resolving `mirror://` URLs, for example).
-  This is useful for debugging.
-
-  _Default value:_ `false`.
-
-`meta` (Attribute Set; _optional_)
-: Specifies any [meta-attributes](#chap-meta) for the derivation returned by `fetchurl`.
-
-  _Default value:_ `{}`.
-
-`passthru` (Attribute Set; _optional_)
-: Specifies any extra [`passthru`](#chap-passthru) attributes for the derivation returned by `fetchurl`.
-  Note that `fetchurl` defines [`passthru` attributes of its own](#ssec-pkgs-fetchers-fetchurl-passthru-outputs).
-  Attributes specified in `passthru` can override the default attributes returned by `fetchurl`.
-
-  _Default value:_ `{}`.
-
-`preferLocalBuild` (Boolean; _optional_)
-: This is the same attribute as [defined in the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-preferLocalBuild).
-  It is `true` by default because making a remote machine download the content just duplicates network traffic (since the local machine might download the results from the derivation anyway), but this could be useful in cases where network access is restricted on local machines.
-
-  _Default value:_ `true`.
-
-`nativeBuildInputs` (List of Attribute Set; _optional_)
-: Additional packages needed to download the content.
-  This is useful if you need extra packages for `postFetch` or `netrcPhase`, for example.
-  Has the same semantics as in [](#var-stdenv-nativeBuildInputs).
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how this can be used with `postFetch`.
-
-  _Default value:_ `[]`.
-
-### Passthru outputs {#ssec-pkgs-fetchers-fetchurl-passthru-outputs}
-
-`fetchurl` also defines its own [`passthru`](#chap-passthru) attributes:
-
-`url` (String)
-
-: The same `url` attribute passed in the argument to `fetchurl`.
-
-### Examples {#ssec-pkgs-fetchers-fetchurl-examples}
-
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version}
-# Using `fetchurl` to download a file
-
-The following package downloads a small file from a URL and shows the most common way to use `fetchurl`:
+The fact that the hash belongs to the Nix derivation output and not the file itself can lead to confusion.
+For example, consider the following fetcher:
 
 ```nix
-{ fetchurl }:
 fetchurl {
-  url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.0.tar.gz";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+};
 ```
 
-After building the package, the file will be downloaded and place into the Nix store:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
-
-$ cat /nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
-23.11
-```
-:::
-
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version-multiple-urls}
-# Using `fetchurl` to download a file with multiple possible URLs
-
-The following package adapts [](#ex-fetchers-fetchurl-nixpkgs-version) to use multiple URLs.
-The first URL was crafted to intentionally return an error to illustrate how `fetchurl` will try multiple URLs until it finds one that works (or all URLs fail).
+A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.
 
 ```nix
-{ fetchurl }:
 fetchurl {
-  urls = [
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
-  ];
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.1.tar.gz";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+};
 ```
 
-After building the package, both URLs will be used to download the file:
-
-```shell
-$ nix-build
-(some output removed for clarity)
-trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist
-(some output removed for clarity)
-curl: (22) The requested URL returned error: 404
-
-trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version
-(some output removed for clarity)
-/nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
-
-$ cat /nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
-23.11
-```
-
-However, note that the name of the file was derived from the first URL (this is further explained in [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl)).
-To ensure the result will have the same name regardless of which URLs are used, we can modify the package:
+**This will reuse the old contents**.
+Remember to invalidate the hash argument, in this case by setting the `hash` attribute to an empty string.
 
 ```nix
-{ fetchurl }:
 fetchurl {
-  name = "nixpkgs-version";
-  urls = [
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
-  ];
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.1.tar.gz";
+  hash = "";
+};
 ```
 
-After building the package, the result will have the name we specified:
+Use the resulting error message to determine the correct hash.
 
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/zczb6wl3al6jm9sm5h3pr6nqn0i5ji9z-nixpkgs-version
 ```
-:::
+error: hash mismatch in fixed-output derivation '/path/to/my.drv':
+         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
+            got:    sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=
+```
 
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version-postfetch}
-# Manipulating the content downloaded by `fetchurl`
+A similar problem arises while testing changes to a fetcher's implementation. If the output of the derivation already exists in the Nix store, test failures can go undetected. The [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function helps prevent reusing cached derivations.
 
-It might be useful to manipulate the content downloaded by `fetchurl` directly in its derivation.
-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.
+## `fetchurl` and `fetchzip` {#fetchurl}
+
+Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `hash`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `hash`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
 
 ```nix
-{ fetchurl, hello, lib }:
-fetchurl {
-  url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
+{ stdenv, fetchurl }:
 
-  nativeBuildInputs = [ hello ];
-
-  downloadToTemp = true;
-  postFetch = ''
-    ${lib.getExe hello} >> $downloadedFile
-    mv $downloadedFile $out
-  '';
-
-  hash = "sha256-ceooQQYmDx5+0nfg40uU3NNI2yKrixP7HZ/xLZUNv+w=";
+stdenv.mkDerivation {
+  name = "hello";
+  src = fetchurl {
+    url = "http://www.example.org/hello.tar.gz";
+    hash = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
+  };
 }
 ```
 
-After building the package, the resulting file will have "Hello, world!" appended to it:
+The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
 
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
-
-$ cat /nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
-23.11
-Hello, world!
-```
-
-Note that the `hash` specified in the package is different than the hash specified in [](#ex-fetchers-fetchurl-nixpkgs-version), because the contents of the output have changed (even though the actual file that was downloaded is the same).
-See [](#chap-pkgs-fetchers-caveats) for more details on how to work with the `hash` attribute when the output changes.
-:::
-
-## `fetchzip` {#sec-pkgs-fetchers-fetchzip}
-
-Returns a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary.html#gloss-fixed-output-derivation) which downloads an archive from a given URL and decompresses it.
-
-Despite its name, `fetchzip` is not limited to `.zip` files but can also be used with [various compressed tarball formats](#tar-files) by default.
-This can extended by specifying additional attributes, see [](#ex-fetchers-fetchzip-rar-archive) to understand how to do that.
-
-### Inputs {#sec-pkgs-fetchers-fetchzip-inputs}
-
-`fetchzip` requires an attribute set, and most attributes are passed to the underlying call to [`fetchurl`](#sec-pkgs-fetchers-fetchurl).
-
-The attributes below are treated differently by `fetchzip` when compared to what `fetchurl` expects:
-
-`name` (String; _optional_)
-: Works as defined in `fetchurl`, but has a different default value than `fetchurl`.
-
-  _Default value:_ `"source"`.
-
-`nativeBuildInputs` (List of Attribute Set; _optional_)
-: Works as defined in `fetchurl`, but it is also augmented by `fetchzip` to include packages to deal with additional archives (such as `.zip`).
-
-  _Default value:_ `[]`.
-
-`postFetch` (String; _optional_)
-: Works as defined in `fetchurl`, but it is also augmented with the code needed to make `fetchzip` work.
-
-  :::{.caution}
-  It is only safe to modify files in `$out` in `postFetch`.
-  Consult the implementation of `fetchzip` for anything more involved.
-  :::
-
-  _Default value:_ `""`.
-
-`stripRoot` (Boolean; _optional_)
-: If `true`, the decompressed contents are moved one level up the directory tree.
-
-  This is useful for archives that decompress into a single directory which commonly includes some values that change with time, such as version numbers.
-  When this is the case (and `stripRoot` is `true`), `fetchzip` will remove this directory and make the decompressed contents available in the top-level directory.
-
-  [](#ex-fetchers-fetchzip-simple-striproot) shows what this attribute does.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-  _Default value:_ `true`.
-
-`extension` (String or Null; _optional_)
-: If set, the archive downloaded by `fetchzip` will be renamed to a filename with the extension specified in this attribute.
-
-  This is useful when making `fetchzip` support additional types of archives, because the implementation may use the extension of an archive to determine whether they can decompress it.
-  If the URL you're using to download the contents doesn't end with the extension associated with the archive, use this attribute to fix the filename of the archive.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-  _Default value:_ `null`.
-
-`recursiveHash` (Boolean; _optional_)
-: Works [as defined in `fetchurl`](#sec-pkgs-fetchers-fetchurl-inputs-recursiveHash), but its default value is different than for `fetchurl`.
-
-  _Default value:_ `true`.
-
-`downloadToTemp` (Boolean; _optional_)
-: Works [as defined in `fetchurl`](#sec-pkgs-fetchers-fetchurl-inputs-downloadToTemp), but its default value is different than for `fetchurl`.
-
-  _Default value:_ `true`.
-
-`extraPostFetch` **DEPRECATED**
-: This attribute is deprecated.
-  Please use `postFetch` instead.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-### Examples {#sec-pkgs-fetchers-fetchzip-examples}
-
-::::{.example #ex-fetchers-fetchzip-simple-striproot}
-# Using `fetchzip` to output contents directly
-
-The following recipe shows how to use `fetchzip` to decompress a `.tar.gz` archive:
-
-```nix
-{ fetchzip }:
-fetchzip {
-  url = "https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0.tar.gz";
-  hash = "sha256-3ABYlME9R8klcpJ7MQpyFEFwHmxDDEzIYBqu/CpDYmg=";
-}
-```
-
-This archive has all its contents in a directory named `patchelf-0.18.0`.
-This means that after decompressing, you'd have to enter this directory to see the contents of the archive.
-However, `fetchzip` makes this easier through the attribute `stripRoot` (enabled by default).
-
-After building the recipe, the derivation output will show all the files in the archive at the top level:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/1b7h3fvmgrcddvs0m299hnqxlgli1yjw-source
-
-$ ls /nix/store/1b7h3fvmgrcddvs0m299hnqxlgli1yjw-source
-aclocal.m4  completions  configure.ac  m4           Makefile.in  patchelf.spec     README.md  tests
-build-aux   configure    COPYING       Makefile.am  patchelf.1   patchelf.spec.in  src        version
-```
-
-If `stripRoot` is set to `false`, the derivation output will be the decompressed archive as-is:
-
-```nix
-{ fetchzip }:
-fetchzip {
-  url = "https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0.tar.gz";
-  hash = "sha256-uv3FuKE4DqpHT3yfE0qcnq0gYjDNQNKZEZt2+PUAneg=";
-  stripRoot = false;
-}
-```
-
-:::{.caution}
-The hash changed!
-Whenever changing attributes of a Nixpkgs fetcher, [remember to invalidate the hash](#chap-pkgs-fetchers-caveats), otherwise you won't get the results you're expecting!
-:::
-
-After building the recipe:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/2hy5bxw7xgbgxkn0i4x6hjr8w3dbx16c-source
-
-$ ls /nix/store/2hy5bxw7xgbgxkn0i4x6hjr8w3dbx16c-source
-patchelf-0.18.0
-```
-::::
-
-::::{.example #ex-fetchers-fetchzip-rar-archive}
-# Using `fetchzip` to decompress a `.rar` file
-
-The `unrar` package provides a [setup hook](#ssec-setup-hooks) to decompress `.rar` archives during the [unpack phase](#ssec-unpack-phase), which can be used with `fetchzip` to decompress those archives:
-
-```nix
-{ fetchzip, unrar }:
-fetchzip {
-  url = "https://archive.org/download/SpaceCadet_Plus95/Space_Cadet.rar";
-  hash = "sha256-fC+zsR8BY6vXpUkVd6i1jF0IZZxVKVvNi6VWCKT+pA4=";
-  stripRoot = false;
-  nativeBuildInputs = [ unrar ];
-}
-```
-
-Since this particular `.rar` file doesn't put its contents in a directory inside the archive, `stripRoot` must be set to `false`.
-
-After building the recipe, the derivation output will show the decompressed files:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/zpn7knxfva6rfjja2gbb4p3l9w1f0d36-source
-
-$ ls /nix/store/zpn7knxfva6rfjja2gbb4p3l9w1f0d36-source
-FONT.DAT      PINBALL.DAT  PINBALL.EXE	PINBALL2.MID  TABLE.BMP    WMCONFIG.EXE
-MSCREATE.DIR  PINBALL.DOC  PINBALL.MID	Sounds	     WAVEMIX.INF
-```
-::::
+Additional parameters to `fetchurl`:
+- `downloadToTemp`: Defaults to `false`. If `true`, saves the source to `$downloadedFile`, to be used in conjunction with `postFetch`
+- `postFetch`: Shell code executed after the file has been fetched successfully. Use it for postprocessing, to check or transform the file.
 
 ## `fetchpatch` {#fetchpatch}
 
@@ -722,7 +123,7 @@ Here is an example of `fetchDebianPatch` in action:
 buildPythonPackage rec {
   pname = "pysimplesoap";
   version = "1.16.2";
-  src = <...>;
+  src = ...;
 
   patches = [
     (fetchDebianPatch {
@@ -733,7 +134,7 @@ buildPythonPackage rec {
     })
   ];
 
-  # ...
+  ...
 }
 ```
 
@@ -842,7 +243,7 @@ This is a useful last-resort workaround for license restrictions that prohibit r
 If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
 Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
 
-```nix
+```
 requireFile {
   name = "jdk-${version}_linux-x64_bin.tar.gz";
   url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
@@ -869,13 +270,13 @@ It produces packages that cannot be built automatically.
 
 `fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
 
-```nix
+```
 { fetchtorrent }:
 
 fetchtorrent {
   config = { peer-limit-global = 100; };
   url = "magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c";
-  hash = "";
+  sha256 = "";
 }
 ```
 

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

@@ -64,7 +64,7 @@ let
 
   src = fetchurl {
     url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
+    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
   };
 in appimageTools.wrapType2 {
   inherit pname version src;
@@ -100,7 +100,7 @@ let
 
   src = fetchurl {
     url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
+    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
   };
 
   appimageContents = appimageTools.extract {
@@ -141,7 +141,7 @@ let
 
   src = fetchurl {
     url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
+    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
   };
 
   appimageContents = appimageTools.extract {

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

@@ -50,10 +50,6 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
   If specified, the layer created by `buildImage` will be appended to the layers defined in the base image, resulting in an image with at least two layers (one or more layers from the base image, and the layer created by `buildImage`).
   Otherwise, the resulting image with contain the single layer created by `buildImage`.
 
-  :::{.note}
-  Only **Env** configuration is inherited from the base image.
-  :::
-
   _Default value:_ `null`.
 
 `fromImageName` (String or Null; _optional_)
@@ -189,26 +185,13 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
   _Default value:_ `"gz"`.\
   _Possible values:_ `"none"`, `"gz"`, `"zstd"`.
 
-`includeNixDB` (Boolean; _optional_)
-
-: Populate the nix database in the image with the dependencies of `copyToRoot`.
-  The main purpose is to be able to use nix commands in the container.
-
-  :::{.caution}
-  Be careful since this doesn't work well in combination with `fromImage`. In particular, in a multi-layered image, only the Nix paths from the lower image will be in the database.
-
-  This also neglects to register the store paths that are pulled into the image as a dependency of one of the other values, but aren't a dependency of `copyToRoot`.
-  :::
-
-  _Default value:_ `false`.
-
 `contents` **DEPRECATED**
 
 : This attribute is deprecated, and users are encouraged to use `copyToRoot` instead.
 
 ### Passthru outputs {#ssec-pkgs-dockerTools-buildImage-passthru-outputs}
 
-`buildImage` defines a few [`passthru`](#chap-passthru) attributes:
+`buildImage` defines a few [`passthru`](#var-stdenv-passthru) attributes:
 
 `buildArgs` (Attribute Set)
 
@@ -453,7 +436,7 @@ See [](#ex-dockerTools-streamLayeredImage-exploringlayers) to understand how the
 `streamLayeredImage` allows scripts to be run when creating the additional layer with symlinks, allowing custom behaviour to affect the final results of the image (see the documentation of the `extraCommands` and `fakeRootCommands` attributes).
 
 The resulting repository tarball will list a single image as specified by the `name` and `tag` attributes.
-By default, that image will use a static creation date (see documentation for the `created` and `mtime` attributes).
+By default, that image will use a static creation date (see documentation for the `created` attribute).
 This allows the function to produce reproducible images.
 
 ### Inputs {#ssec-pkgs-dockerTools-streamLayeredImage-inputs}
@@ -516,7 +499,6 @@ This allows the function to produce reproducible images.
 `created` (String; _optional_)
 
 : Specifies the time of creation of the generated image.
-  This date will be used for the image metadata.
   This should be either a date and time formatted according to [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) or `"now"`, in which case the current date will be used.
 
   :::{.caution}
@@ -525,18 +507,6 @@ This allows the function to produce reproducible images.
 
   _Default value:_ `"1970-01-01T00:00:01Z"`.
 
-`mtime` (String; _optional_)
-
-: Specifies the time used for the modification timestamp of files within the layers of the generated image.
-  This should be either a date and time formatted according to [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) or `"now"`, in which case the current date will be used.
-
-  :::{.caution}
-  Using a non-constant date will cause built layers to have a different hash each time, preventing deduplication.
-  Using `"now"` also means that the generated image will not be reproducible anymore (because the date will always change whenever it's built).
-  :::
-
-  _Default value:_ `"1970-01-01T00:00:01Z"`.
-
 `uid` (Number; _optional_) []{#dockerTools-buildLayeredImage-arg-uid}
 `gid` (Number; _optional_) []{#dockerTools-buildLayeredImage-arg-gid}
 `uname` (String; _optional_) []{#dockerTools-buildLayeredImage-arg-uname}
@@ -604,28 +574,15 @@ This allows the function to produce reproducible images.
 
   _Default value:_ `true`
 
-`includeNixDB` (Boolean; _optional_)
-
-: Populate the nix database in the image with the dependencies of `copyToRoot`.
-  The main purpose is to be able to use nix commands in the container.
-
-  :::{.caution}
-  Be careful since this doesn't work well in combination with `fromImage`. In particular, in a multi-layered image, only the Nix paths from the lower image will be in the database.
-
-  This also neglects to register the store paths that are pulled into the image as a dependency of one of the other values, but aren't a dependency of `copyToRoot`.
-  :::
-
-  _Default value:_ `false`.
-
 `passthru` (Attribute Set; _optional_)
 
-: Use this to pass any attributes as [`passthru`](#chap-passthru) for the resulting derivation.
+: Use this to pass any attributes as [passthru](#var-stdenv-passthru) for the resulting derivation.
 
   _Default value:_ `{}`
 
 ### Passthru outputs {#ssec-pkgs-dockerTools-streamLayeredImage-passthru-outputs}
 
-`streamLayeredImage` also defines its own [`passthru`](#chap-passthru) attributes:
+`streamLayeredImage` also defines its own [`passthru`](#var-stdenv-passthru) attributes:
 
 `imageTag` (String)
 
@@ -1220,7 +1177,6 @@ dockerTools.buildImage {
     hello
     dockerTools.binSh
   ];
-}
 ```
 
 After building the image and loading it in Docker, we can create a container based on it and enter a shell inside the container.

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

@@ -85,14 +85,14 @@ let
 in
   make-disk-image {
     inherit pkgs lib;
-    inherit (evalConfig {
+    config = evalConfig {
       modules = [
         {
           fileSystems."/" = { device = "/dev/vda"; fsType = "ext4"; autoFormat = true; };
           boot.grub.device = "/dev/vda";
         }
       ];
-    }) config;
+    };
     format = "qcow2";
     onlyNixStore = false;
     partitionTableType = "legacy+gpt";
@@ -104,3 +104,5 @@ in
     memSize = 2048; # Qemu VM memory size in megabytes. Defaults to 1024M.
   }
 ```
+
+

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

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

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

@@ -6,11 +6,7 @@ It uses Linux' namespaces feature to create temporary lightweight environments w
 Accepted arguments are:
 
 - `name`
-        The name of the environment, and the wrapper executable if `pname` is unset.
-- `pname`
-        The pname of the environment and the wrapper executable.
-- `version`
-        The version of the environment.
+        The name of the environment and the wrapper executable.
 - `targetPkgs`
         Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
 - `multiPkgs`
@@ -57,4 +53,4 @@ You can create a simple environment using a `shell.nix` like this:
 Running `nix-shell` on it would drop you into a shell inside an FHS env where those libraries and binaries are available in FHS-compliant paths. Applications that expect an FHS structure (i.e. proprietary binaries) can run inside this environment without modification.
 You can build a wrapper by running your binary in `runScript`, e.g. `./bin/start.sh`. Relative paths work as expected.
 
-Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGApps*` hook.
+Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.

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

@@ -9,40 +9,22 @@ pkgs.makeSetupHook {
   name = "something-hook";
   propagatedBuildInputs = [ pkgs.commandsomething ];
   depsTargetTargetPropagated = [ pkgs.libsomething ];
-} ./script.sh;
+} ./script.sh
 ```
 
 ### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash {#sec-pkgs.makeSetupHook-usage-example}
 
 ```nix
-pkgs.makeSetupHook
-  {
+pkgs.makeSetupHook {
     name = "run-hello-hook";
-    # Put dependencies here if they have hooks or necessary dependencies propagated
-    # otherwise prefer direct paths to executables.
-    propagatedBuildInputs = [
-      pkgs.hello
-      pkgs.cowsay
-    ];
-    substitutions = {
-      shell = "${pkgs.bash}/bin/bash";
-      cowsay = "${pkgs.cowsay}/bin/cowsay";
-    };
-  }
-  (
-    writeScript "run-hello-hook.sh" ''
-      #!@shell@
-      # the direct path to the executable has to be here because
-      # this will be run when the file is sourced
-      # at which point '$PATH' has not yet been populated with inputs
-      @cowsay@ cow
-
-      _printHelloHook() {
-        hello
-      }
-      preConfigureHooks+=(_printHelloHook)
-    ''
-  );
+    propagatedBuildInputs = [ pkgs.hello ];
+    substitutions = { shell = "${pkgs.bash}/bin/bash"; };
+    passthru.tests.greeting = callPackage ./test { };
+    meta.platforms = lib.platforms.linux;
+} (writeScript "run-hello-hook.sh" ''
+    #!@shell@
+    hello
+'')
 ```
 
 ## Attributes {#sec-pkgs.makeSetupHook-attributes}

doc/build-helpers/testers.chapter.md

@@ -14,13 +14,11 @@ If the `moduleNames` argument is omitted, `hasPkgConfigModules` will use `meta.p
 # Check that `pkg-config` modules are exposed using default values
 
 ```nix
-{
-  passthru.tests.pkg-config = testers.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-  };
+passthru.tests.pkg-config = testers.hasPkgConfigModules {
+  package = finalAttrs.finalPackage;
+};
 
-  meta.pkgConfigModules = [ "libfoo" ];
-}
+meta.pkgConfigModules = [ "libfoo" ];
 ```
 
 :::
@@ -30,149 +28,21 @@ If the `moduleNames` argument is omitted, `hasPkgConfigModules` will use `meta.p
 # Check that `pkg-config` modules are exposed using explicit module names
 
 ```nix
-{
-  passthru.tests.pkg-config = testers.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-    moduleNames = [ "libfoo" ];
-  };
-}
+passthru.tests.pkg-config = testers.hasPkgConfigModules {
+  package = finalAttrs.finalPackage;
+  moduleNames = [ "libfoo" ];
+};
 ```
 
 :::
 
-## `lycheeLinkCheck` {#tester-lycheeLinkCheck}
-
-Check a packaged static site's links with the [`lychee` package](https://search.nixos.org/packages?show=lychee&type=packages&query=lychee).
-
-You may use Nix to reproducibly build static websites, such as for software documentation.
-Some packages will install documentation in their `out` or `doc` outputs, or maybe you have dedicated package where you've made your static site reproducible by running a generator, such as [Hugo](https://gohugo.io/) or [mdBook](https://rust-lang.github.io/mdBook/), in a derivation.
-
-If you have a static site that can be built with Nix, you can use `lycheeLinkCheck` to check that the hyperlinks in your site are correct, and do so as part of your Nix workflow and CI.
-
-:::{.example #ex-lycheelinkcheck}
-
-# Check hyperlinks in the `nix` documentation
-
-```nix
-testers.lycheeLinkCheck {
-  site = nix.doc + "/share/doc/nix/manual";
-}
-```
-
-:::
-
-### Return value {#tester-lycheeLinkCheck-return}
-
-This tester produces a package that does not produce useful outputs, but only succeeds if the hyperlinks in your site are correct. The build log will list the broken links.
-
-It has two modes:
-
-- Build the returned derivation; its build process will check that internal hyperlinks are correct. This runs in the sandbox, so it will not check external hyperlinks, but it is quick and reliable.
-
-- Invoke the `.online` attribute with [`nix run`](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-run) ([experimental](https://nixos.org/manual/nix/stable/contributing/experimental-features#xp-feature-nix-command)). This runs outside the sandbox, and checks that both internal and external hyperlinks are correct.
-  Example:
-
-  ```shell
-  nix run nixpkgs#lychee.tests.ok.online
-  ```
-
-### Inputs {#tester-lycheeLinkCheck-inputs}
-
-`site` (path or derivation) {#tester-lycheeLinkCheck-param-site}
-
-: The path to the files to check.
-
-`remap` (attribe set, optional) {#tester-lycheeLinkCheck-param-remap}
-
-: An attribute set where the attribute names are regular expressions.
-  The values should be strings, derivations, or path values.
-
-  In the returned check's default configuration, external URLs are only checked when you run the `.online` attribute.
-
-  By adding remappings, you can check offline that URLs to external resources are correct, by providing a stand-in from the file system.
-
-  Before checking the existence of a URL, the regular expressions are matched and replaced by their corresponding values.
-
-  Example:
-
-  ```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";
-  }
-  ```
-
-  Store paths in the attribute values are automatically prefixed with `file://`, because lychee requires this for paths in the file system.
-  If this is a problem, or if you need to control the order in which replacements are performed, use `extraConfig.remap` instead.
-
-`extraConfig` (attribute set) {#tester-lycheeLinkCheck-param-extraConfig}
-
-: Extra configuration to pass to `lychee` in its [configuration file](https://github.com/lycheeverse/lychee/blob/master/lychee.example.toml).
-  It is automatically [translated](https://nixos.org/manual/nixos/stable/index.html#sec-settings-nix-representable) to TOML.
-
-  Example: `{ "include_verbatim" = true; }`
-
-`lychee` (derivation, optional) {#tester-lycheeLinkCheck-param-lychee}
-
-: The `lychee` package to use.
-
-## `shellcheck` {#tester-shellcheck}
-
-Runs files through `shellcheck`, a static analysis tool for shell scripts.
-
-:::{.example #ex-shellcheck}
-# Run `testers.shellcheck`
-
-A single script
-
-```nix
-testers.shellcheck {
-  name = "shellcheck";
-  src = ./script.sh;
-}
-```
-
-Multiple files
-
-```nix
-let
-  inherit (lib) fileset;
-in
-testers.shellcheck {
-  name = "shellcheck";
-  src = fileset.toSource {
-    root = ./.;
-    fileset = fileset.unions [
-      ./lib.sh
-      ./nixbsd-activate
-    ];
-  };
-}
-```
-
-:::
-
-### Inputs {#tester-shellcheck-inputs}
-
-[`src` (path or string)]{#tester-shellcheck-param-src}
-
-: The path to the shell script(s) to check.
-  This can be a single file or a directory containing shell files.
-  All files in `src` will be checked, so you may want to provide `fileset`-based source instead of a whole directory.
-
-### Return value {#tester-shellcheck-return}
-
-A derivation that runs `shellcheck` on the given script(s).
-The build will fail if `shellcheck` finds any issues.
-
 ## `testVersion` {#tester-testVersion}
 
 Checks that the output from running a command contains the specified version string in it as a whole word.
 
-NOTE: In most cases, [`versionCheckHook`](#versioncheckhook) should be preferred, but this function is provided and documented here anyway. The motivation for adding either tests would be:
-
-- Catch dynamic linking errors and such and missing environment variables that should be added by wrapping.
-- Probable protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
+Although simplistic, this test assures that the main program can run.
+While there's no substitute for a real test case, it does catch dynamic linking errors and such.
+It also provides some protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
 
 By default, the command to be run will be inferred from the given `package` attribute:
 it will check `meta.mainProgram` first, and fall back to `pname` or `name`.
@@ -185,9 +55,7 @@ The default argument to the command is `--version`, and the version to be checke
 This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.
 
 ```nix
-{
-  passthru.tests.version = testers.testVersion { package = hello; };
-}
+passthru.tests.version = testers.testVersion { package = hello; };
 ```
 
 :::
@@ -202,15 +70,13 @@ This means that an output like "leetcode 0.4.21" would fail the tests, and an ou
 A common usage of the `version` attribute is to specify `version = "v${version}"`.
 
 ```nix
-{
-  version = "0.4.2";
+version = "0.4.2";
 
-  passthru.tests.version = testers.testVersion {
-    package = leetcode-cli;
-    command = "leetcode -V";
-    version = "leetcode ${version}";
-  };
-}
+passthru.tests.version = testers.testVersion {
+  package = leetcode-cli;
+  command = "leetcode -V";
+  version = "leetcode ${version}";
+};
 ```
 
 :::
@@ -250,12 +116,12 @@ runCommand "example" {
   grep -F 'failing though' $failed/testBuildFailure.log
   [[ 3 = $(cat $failed/testBuildFailure.exit) ]]
   touch $out
-''
+'';
 ```
 
 :::
 
-## `testEqualContents` {#tester-testEqualContents}
+## `testEqualContents` {#tester-equalContents}
 
 Check that two paths have the same contents.
 
@@ -327,49 +193,12 @@ once to get a derivation hash, and again to produce the final fixed output deriv
 # Prevent nix from reusing the output of a fetcher
 
 ```nix
-{
-  tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
-    name = "nix-source";
-    url = "https://github.com/NixOS/nix";
-    rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
-    hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
-  };
-}
-```
-
-:::
-
-## `runCommand` {#tester-runCommand}
-
-`runCommand :: { name, script, stdenv ? stdenvNoCC, hash ? "...", ... } -> Derivation`
-
-This is a wrapper around `pkgs.runCommandWith`, which
-- produces a fixed-output derivation, enabling the command(s) to access the network ;
-- salts the derivation's name based on its inputs, ensuring the command is re-run whenever the inputs changes.
-
-It accepts the following attributes:
-- the derivation's `name` ;
-- the `script` to be executed ;
-- `stdenv`, the environment to use, defaulting to `stdenvNoCC` ;
-- the derivation's output `hash`, defaulting to the empty file's.
-  The derivation's `outputHashMode` is set by default to recursive, so the `script` can output a directory as well.
-
-All other attributes are passed through to [`mkDerivation`](#sec-using-stdenv),
-including `nativeBuildInputs` to specify dependencies available to the `script`.
-
-:::{.example #ex-tester-runCommand-nix}
-
-# Run a command with network access
-
-```nix
-testers.runCommand {
-  name = "access-the-internet";
-  command = ''
-    curl -o /dev/null https://example.com
-    touch $out
-  '';
-  nativeBuildInputs = with pkgs; [ cacert curl ];
-}
+tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
+  name = "nix-source";
+  url = "https://github.com/NixOS/nix";
+  rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
+  hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
+};
 ```
 
 :::

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

@@ -3,122 +3,32 @@
 Nixpkgs provides a variety of wrapper functions that help build commonly useful derivations.
 Like [`stdenv.mkDerivation`](#sec-using-stdenv), each of these build helpers creates a derivation, but the arguments passed are different (usually simpler) from those required by `stdenv.mkDerivation`.
 
+## `runCommand` {#trivial-builder-runCommand}
 
-## `runCommandWith` {#trivial-builder-runCommandWith}
+`runCommand :: String -> AttrSet -> String -> Derivation`
 
-The function `runCommandWith` returns a derivation built using the specified command(s), in a specified environment.
+The result of `runCommand name drvAttrs buildCommand` is a derivation that is built by running the specified shell commands.
 
-It is the underlying base function of  all [`runCommand*` variants].
-The general behavior is controlled via a single attribute set passed
-as the first argument, and allows specifying `stdenv` freely.
+By default `runCommand` runs in a stdenv with no compiler environment, whereas [`runCommandCC`](#trivial-builder-runCommandCC) uses the default stdenv, `pkgs.stdenv`.
 
-The following [`runCommand*` variants] exist: `runCommand`, `runCommandCC`, and `runCommandLocal`.
+`name :: String`
+:   The name that Nix will append to the store path in the same way that `stdenv.mkDerivation` uses its `name` attribute.
 
-[`runCommand*` variants]: #trivial-builder-runCommand
+`drvAttr :: AttrSet`
+:   Attributes to pass to the underlying call to [`stdenv.mkDerivation`](#chap-stdenv).
 
-### Type {#trivial-builder-runCommandWith-Type}
-
-```
-runCommandWith :: {
-  name :: name;
-  stdenv? :: Derivation;
-  runLocal? :: Bool;
-  derivationArgs? :: { ... };
-} -> String -> Derivation
-```
-
-### Inputs {#trivial-builder-runCommandWith-Inputs}
-
-`name` (String)
-:   The derivation's name, which Nix will append to the store path; see [`mkDerivation`](#sec-using-stdenv).
-
-`runLocal` (Boolean)
-:   If set to `true` this forces the derivation to be built locally, not using [substitutes] nor remote builds.
-    This is intended for very cheap commands (<1s execution time) which can be sped up by avoiding the network round-trip(s).
-    Its effect is to set [`preferLocalBuild = true`][preferLocalBuild] and [`allowSubstitutes = false`][allowSubstitutes].
-
-   ::: {.note}
-   This prevents the use of [substituters][substituter], so only set `runLocal` (or use `runCommandLocal`) when certain the user will
-   always have a builder for the `system` of the derivation. This should be true for most trivial use cases
-   (e.g., just copying some files to a different location or adding symlinks) because there the `system`
-   is usually the same as `builtins.currentSystem`.
-   :::
-
-`stdenv` (Derivation)
-:   The [standard environment](#chap-stdenv) to use, defaulting to `pkgs.stdenv`
-
-`derivationArgs` (Attribute set)
-:   Additional arguments for [`mkDerivation`](#sec-using-stdenv).
-
-`buildCommand` (String)
+`buildCommand :: String`
 :   Shell commands to run in the derivation builder.
 
     ::: {.note}
     You have to create a file or directory `$out` for Nix to be able to run the builder successfully.
     :::
 
-[allowSubstitutes]: https://nixos.org/nix/manual/#adv-attr-allowSubstitutes
-[preferLocalBuild]: https://nixos.org/nix/manual/#adv-attr-preferLocalBuild
-[substituter]: https://nix.dev/manual/nix/latest/glossary#gloss-substituter
-[substitutes]: https://nix.dev/manual/nix/2.23/glossary#gloss-substitute
-
-::: {.example #ex-runcommandwith}
-# Invocation of `runCommandWith`
-
-```nix
-runCommandWith {
-  name = "example";
-  derivationArgs.nativeBuildInputs = [ cowsay ];
-} ''
-  cowsay > $out <<EOMOO
-  'runCommandWith' is a bit cumbersome,
-  so we have more ergonomic wrappers.
-  EOMOO
-''
-```
-
-:::
-
-
-## `runCommand` and `runCommandCC` {#trivial-builder-runCommand}
-
-The function `runCommand` returns a derivation built using the specified command(s), in the `stdenvNoCC` environment.
-
-`runCommandCC` is similar but uses the default compiler environment. To minimize dependencies, `runCommandCC`
-should only be used when the build command needs a C compiler.
-
-`runCommandLocal` is also similar to `runCommand`, but forces the derivation to be built locally.
-See the note on [`runCommandWith`] about `runLocal`.
-
-[`runCommandWith`]: #trivial-builder-runCommandWith
-
-### Type {#trivial-builder-runCommand-Type}
-
-```
-runCommand      :: String -> AttrSet -> String -> Derivation
-runCommandCC    :: String -> AttrSet -> String -> Derivation
-runCommandLocal :: String -> AttrSet -> String -> Derivation
-```
-
-### Input {#trivial-builder-runCommand-Input}
-
-While the type signature(s) differ from [`runCommandWith`], individual arguments with the same name will have the same type and meaning:
-
-`name` (String)
-:   The derivation's name
-
-`derivationArgs` (Attribute set)
-:   Additional parameters passed to [`mkDerivation`]
-
-`buildCommand` (String)
-:   The command(s) run to build the derivation.
-
-
 ::: {.example #ex-runcommand-simple}
 # Invocation of `runCommand`
 
 ```nix
-runCommand "my-example" {} ''
+(import <nixpkgs> {}).runCommand "my-example" {} ''
   echo My example command is running
 
   mkdir $out
@@ -139,24 +49,18 @@ runCommand "my-example" {} ''
 ```
 :::
 
+## `runCommandCC` {#trivial-builder-runCommandCC}
+
+This works just like `runCommand`. The only difference is that it also provides a C compiler in `buildCommand`'s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
+
+## `runCommandLocal` {#trivial-builder-runCommandLocal}
+
+Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network round-trip and can speed up a build.
+
 ::: {.note}
-`runCommand name derivationArgs buildCommand` is equivalent to
-```nix
-runCommandWith {
-  inherit name derivationArgs;
-  stdenv = stdenvNoCC;
-} buildCommand
-```
-
-Likewise, `runCommandCC name derivationArgs buildCommand` is equivalent to
-```nix
-runCommandWith {
-  inherit name derivationArgs;
-} buildCommand
-```
+This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
 :::
 
-
 ## Writing text files {#trivial-builder-text-writing}
 
 Nixpkgs provides the following functions for producing derivations which write text files or executable scripts into the Nix store.
@@ -172,14 +76,12 @@ If you need to refer to the resulting files somewhere else in a Nix expression,
 For example, if the file destination is a directory:
 
 ```nix
-{
-  my-file = writeTextFile {
-    name = "my-file";
-    text = ''
-      Contents of File
-    '';
-    destination = "/share/my-file";
-  };
+my-file = writeTextFile {
+  name = "my-file";
+  text = ''
+    Contents of File
+  '';
+  destination = "/share/my-file";
 }
 ```
 
@@ -188,7 +90,7 @@ Remember to append "/share/my-file" to the resulting store path when using it el
 ```nix
 writeShellScript "evaluate-my-file.sh" ''
   cat ${my-file}/share/my-file
-''
+'';
 ```
 ::::
 
@@ -337,7 +239,7 @@ Write a text file to the Nix store.
 `allowSubstitutes` (Bool, _optional_)
 
 : Whether to allow substituting from a binary cache.
-  Passed through to [`allowSubstitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
+  Passed through to [`allowSubsitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
 
   It defaults to `false`, as running the derivation's simple `builder` executable locally is assumed to be faster than network operations.
   Set it to true if the `checkPhase` step is expensive.
@@ -385,7 +287,7 @@ writeTextFile {
   };
   allowSubstitutes = true;
   preferLocalBuild = false;
-}
+};
 ```
 :::
 
@@ -449,7 +351,7 @@ Write the string `Contents of File` to `/nix/store/<store path>`:
 writeText "my-file"
   ''
   Contents of File
-  ''
+  '';
 ```
 :::
 
@@ -489,7 +391,7 @@ Write the string `Contents of File` to `/nix/store/<store path>/share/my-file`:
 writeTextDir "share/my-file"
   ''
   Contents of File
-  ''
+  '';
 ```
 :::
 
@@ -501,7 +403,7 @@ writeTextFile {
   text = ''
     Contents of File
   '';
-  destination = "/share/my-file";
+  destination = "share/my-file";
 }
 ```
 
@@ -531,8 +433,9 @@ Write the string `Contents of File` to `/nix/store/<store path>` and make the fi
 writeScript "my-file"
   ''
   Contents of File
-  ''
+  '';
 ```
+:::
 
 This is equivalent to:
 
@@ -545,11 +448,10 @@ writeTextFile {
   executable = true;
 }
 ```
-:::
 
 ### `writeScriptBin` {#trivial-builder-writeScriptBin}
 
-Write a script within a `bin` subdirectory of a directory in the Nix store.
+Write a script within a `bin` subirectory of a directory in the Nix store.
 This is for consistency with the convention of software packages placing executables under `bin`.
 
 `writeScriptBin` takes the following arguments:
@@ -564,7 +466,7 @@ This is for consistency with the convention of software packages placing executa
 
 The created file is marked as executable.
 The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
-The store path will include the name, and it will be a directory.
+The store path will include the the name, and it will be a directory.
 
 ::: {.example #ex-writeScriptBin}
 # Usage of `writeScriptBin`
@@ -573,7 +475,7 @@ The store path will include the name, and it will be a directory.
 writeScriptBin "my-script"
   ''
   echo "hi"
-  ''
+  '';
 ```
 :::
 
@@ -586,7 +488,7 @@ writeTextFile {
     echo "hi"
   '';
   executable = true;
-  destination = "/bin/my-script";
+  destination = "bin/my-script";
 }
 ```
 
@@ -617,7 +519,7 @@ This function is almost exactly like [](#trivial-builder-writeScript), except th
 writeShellScript "my-script"
   ''
   echo "hi"
-  ''
+  '';
 ```
 :::
 
@@ -660,7 +562,7 @@ This function is a combination of [](#trivial-builder-writeShellScript) and [](#
 writeShellScriptBin "my-script"
   ''
   echo "hi"
-  ''
+  '';
 ```
 :::
 
@@ -674,7 +576,7 @@ writeTextFile {
     echo "hi"
   '';
   executable = true;
-  destination = "/bin/my-script";
+  destination = "bin/my-script";
 }
 ```
 
@@ -772,7 +674,7 @@ writeClosure [ (writeScriptBin "hi" ''${hello}/bin/hello'') ]
 
 produces an output path `/nix/store/<hash>-runtime-deps` containing
 
-```
+```nix
 /nix/store/<hash>-hello-2.10
 /nix/store/<hash>-hi
 /nix/store/<hash>-libidn2-2.3.0
@@ -798,7 +700,7 @@ writeDirectReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
 
 produces an output path `/nix/store/<hash>-runtime-references` containing
 
-```
+```nix
 /nix/store/<hash>-hello-2.10
 ```
 

doc/common.nix

@@ -0,0 +1,4 @@
+{
+  outputPath = "share/doc/nixpkgs";
+  indexPath = "manual.html";
+}

doc/default.nix

@@ -1,6 +1,176 @@
-{
-  pkgs ? (import ./.. { }),
-  nixpkgs ? { },
-}:
+{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
+let
+  inherit (pkgs) lib;
+  inherit (lib) hasPrefix removePrefix;
 
-pkgs.nixpkgs-manual.override { inherit nixpkgs; }
+  common = import ./common.nix;
+
+  lib-docs = import ./doc-support/lib-function-docs.nix {
+    inherit pkgs nixpkgs;
+    libsets = [
+      { name = "asserts"; description = "assertion functions"; }
+      { name = "attrsets"; description = "attribute set functions"; }
+      { name = "strings"; description = "string manipulation functions"; }
+      { name = "versions"; description = "version string functions"; }
+      { name = "trivial"; description = "miscellaneous functions"; }
+      { name = "fixedPoints"; baseName = "fixed-points"; description = "explicit recursion functions"; }
+      { name = "lists"; description = "list manipulation functions"; }
+      { name = "debug"; description = "debugging functions"; }
+      { name = "options"; description = "NixOS / nixpkgs option handling"; }
+      { name = "path"; description = "path functions"; }
+      { name = "filesystem"; description = "filesystem functions"; }
+      { name = "fileset"; description = "file set functions"; }
+      { name = "sources"; description = "source filtering functions"; }
+      { name = "cli"; description = "command-line serialization functions"; }
+      { name = "gvariant"; description = "GVariant formatted string serialization functions"; }
+      { name = "customisation"; description = "Functions to customise (derivation-related) functions, derivatons, or attribute sets"; }
+      { name = "meta"; description = "functions for derivation metadata"; }
+      { name = "derivations"; description = "miscellaneous derivation-specific functions"; }
+    ];
+  };
+
+  epub = pkgs.runCommand "manual.epub" {
+    nativeBuildInputs = with pkgs; [ libxslt zip ];
+
+    epub = ''
+      <book xmlns="http://docbook.org/ns/docbook"
+            xmlns:xlink="http://www.w3.org/1999/xlink"
+            version="5.0"
+            xml:id="nixpkgs-manual">
+        <info>
+          <title>Nixpkgs Manual</title>
+          <subtitle>Version ${pkgs.lib.version}</subtitle>
+        </info>
+        <chapter>
+          <title>Temporarily unavailable</title>
+          <para>
+            The Nixpkgs manual is currently not available in EPUB format,
+            please use the <link xlink:href="https://nixos.org/nixpkgs/manual">HTML manual</link>
+            instead.
+          </para>
+          <para>
+            If you've used the EPUB manual in the past and it has been useful to you, please
+            <link xlink:href="https://github.com/NixOS/nixpkgs/issues/237234">let us know</link>.
+          </para>
+        </chapter>
+      </book>
+    '';
+
+    passAsFile = [ "epub" ];
+  } ''
+    mkdir scratch
+    xsltproc \
+      --param chapter.autolabel 0 \
+      --nonet \
+      --output scratch/ \
+      ${pkgs.docbook_xsl_ns}/xml/xsl/docbook/epub/docbook.xsl \
+      $epubPath
+
+    echo "application/epub+zip" > mimetype
+    zip -0Xq "$out" mimetype
+    cd scratch && zip -Xr9D "$out" *
+  '';
+
+  # NB: This file describes the Nixpkgs manual, which happens to use module
+  #     docs infra originally developed for NixOS.
+  optionsDoc = pkgs.nixosOptionsDoc {
+    inherit (pkgs.lib.evalModules {
+      modules = [ ../pkgs/top-level/config.nix ];
+      class = "nixpkgsConfig";
+    }) options;
+    documentType = "none";
+    transformOptions = opt:
+      opt // {
+        declarations =
+          map
+            (decl:
+              if hasPrefix (toString ../..) (toString decl)
+              then
+                let subpath = removePrefix "/" (removePrefix (toString ../.) (toString decl));
+                in { url = "https://github.com/NixOS/nixpkgs/blob/master/${subpath}"; name = subpath; }
+              else decl)
+            opt.declarations;
+        };
+  };
+in pkgs.stdenv.mkDerivation {
+  name = "nixpkgs-manual";
+
+  nativeBuildInputs = with pkgs; [
+    nixos-render-docs
+  ];
+
+  src = ./.;
+
+  postPatch = ''
+    ln -s ${optionsDoc.optionsJSON}/share/doc/nixos/options.json ./config-options.json
+  '';
+
+  buildPhase = ''
+    cat \
+      ./functions/library.md.in \
+      ${lib-docs}/index.md \
+      > ./functions/library.md
+    substitute ./manual.md.in ./manual.md \
+      --replace '@MANUAL_VERSION@' '${pkgs.lib.version}'
+
+    mkdir -p out/media
+
+    mkdir -p out/highlightjs
+    cp -t out/highlightjs \
+      ${pkgs.documentation-highlighter}/highlight.pack.js \
+      ${pkgs.documentation-highlighter}/LICENSE \
+      ${pkgs.documentation-highlighter}/mono-blue.css \
+      ${pkgs.documentation-highlighter}/loader.js
+
+    cp -t out ./style.css ./anchor.min.js ./anchor-use.js
+
+    nixos-render-docs manual html \
+      --manpage-urls ./manpage-urls.json \
+      --revision ${pkgs.lib.trivial.revisionWithDefault (pkgs.rev or "master")} \
+      --stylesheet style.css \
+      --stylesheet highlightjs/mono-blue.css \
+      --script ./highlightjs/highlight.pack.js \
+      --script ./highlightjs/loader.js \
+      --script ./anchor.min.js \
+      --script ./anchor-use.js \
+      --toc-depth 1 \
+      --section-toc-depth 1 \
+      manual.md \
+      out/index.html
+  '';
+
+  installPhase = ''
+    dest="$out/${common.outputPath}"
+    mkdir -p "$(dirname "$dest")"
+    mv out "$dest"
+    mv "$dest/index.html" "$dest/${common.indexPath}"
+
+    cp ${epub} "$dest/nixpkgs-manual.epub"
+
+    mkdir -p $out/nix-support/
+    echo "doc manual $dest ${common.indexPath}" >> $out/nix-support/hydra-build-products
+    echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products
+  '';
+
+  passthru.tests.manpage-urls = with pkgs; testers.invalidateFetcherByDrvHash
+    ({ name ? "manual_check-manpage-urls"
+     , script
+     , urlsFile
+     }: runCommand name {
+      nativeBuildInputs = [
+        cacert
+        (python3.withPackages (p: with p; [
+          aiohttp
+          rich
+          structlog
+        ]))
+      ];
+      outputHash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=";  # Empty output
+    } ''
+      python3 ${script} ${urlsFile}
+      touch $out
+    '') {
+      script = ./tests/manpage-urls.py;
+      urlsFile = ./manpage-urls.json;
+    };
+}

doc/doc-support/epub.nix

@@ -1,54 +0,0 @@
-# To build this derivation, run `nix-build -A nixpkgs-manual.epub`
-{
-  lib,
-  runCommand,
-  docbook_xsl_ns,
-  libxslt,
-  zip,
-}:
-runCommand "manual.epub"
-  {
-    nativeBuildInputs = [
-      libxslt
-      zip
-    ];
-
-    epub = ''
-      <book xmlns="http://docbook.org/ns/docbook"
-            xmlns:xlink="http://www.w3.org/1999/xlink"
-            version="5.0"
-            xml:id="nixpkgs-manual">
-        <info>
-          <title>Nixpkgs Manual</title>
-          <subtitle>Version ${lib.version}</subtitle>
-        </info>
-        <chapter>
-          <title>Temporarily unavailable</title>
-          <para>
-            The Nixpkgs manual is currently not available in EPUB format,
-            please use the <link xlink:href="https://nixos.org/nixpkgs/manual">HTML manual</link>
-            instead.
-          </para>
-          <para>
-            If you've used the EPUB manual in the past and it has been useful to you, please
-            <link xlink:href="https://github.com/NixOS/nixpkgs/issues/237234">let us know</link>.
-          </para>
-        </chapter>
-      </book>
-    '';
-
-    passAsFile = [ "epub" ];
-  }
-  ''
-    mkdir scratch
-    xsltproc \
-      --param chapter.autolabel 0 \
-      --nonet \
-      --output scratch/ \
-      ${docbook_xsl_ns}/xml/xsl/docbook/epub/docbook.xsl \
-      $epubPath
-
-    echo "application/epub+zip" > mimetype
-    zip -0Xq -b "$TMPDIR" "$out" mimetype
-    cd scratch && zip -Xr9D -b "$TMPDIR" "$out" *
-  ''

doc/doc-support/lib-function-docs.nix

@@ -1,123 +1,27 @@
 # Generates the documentation for library functions via nixdoc.
-# To build this derivation, run `nix-build -A nixpkgs-manual.lib-docs`
-{
-  lib,
-  stdenvNoCC,
-  nixdoc,
-  nix,
-  nixpkgs ? { },
-  libsets ? [
-    {
-      name = "asserts";
-      description = "assertion functions";
-    }
-    {
-      name = "attrsets";
-      description = "attribute set functions";
-    }
-    {
-      name = "strings";
-      description = "string manipulation functions";
-    }
-    {
-      name = "versions";
-      description = "version string functions";
-    }
-    {
-      name = "trivial";
-      description = "miscellaneous functions";
-    }
-    {
-      name = "fixedPoints";
-      baseName = "fixed-points";
-      description = "explicit recursion functions";
-    }
-    {
-      name = "lists";
-      description = "list manipulation functions";
-    }
-    {
-      name = "debug";
-      description = "debugging functions";
-    }
-    {
-      name = "options";
-      description = "NixOS / nixpkgs option handling";
-    }
-    {
-      name = "path";
-      description = "path functions";
-    }
-    {
-      name = "filesystem";
-      description = "filesystem functions";
-    }
-    {
-      name = "fileset";
-      description = "file set functions";
-    }
-    {
-      name = "sources";
-      description = "source filtering functions";
-    }
-    {
-      name = "cli";
-      description = "command-line serialization functions";
-    }
-    {
-      name = "generators";
-      description = "functions that create file formats from nix data structures";
-    }
-    {
-      name = "gvariant";
-      description = "GVariant formatted string serialization functions";
-    }
-    {
-      name = "customisation";
-      description = "Functions to customise (derivation-related) functions, derivatons, or attribute sets";
-    }
-    {
-      name = "meta";
-      description = "functions for derivation metadata";
-    }
-    {
-      name = "derivations";
-      description = "miscellaneous derivation-specific functions";
-    }
-  ],
-}:
 
-stdenvNoCC.mkDerivation {
+{ pkgs, nixpkgs, libsets }:
+
+with pkgs;
+
+let
+  locationsJSON = import ./lib-function-locations.nix { inherit pkgs nixpkgs libsets; };
+in
+stdenv.mkDerivation {
   name = "nixpkgs-lib-docs";
+  src = ../../lib;
 
-  src = lib.fileset.toSource {
-    root = ../..;
-    fileset = ../../lib;
-  };
-
-  buildInputs = [
-    nixdoc
-    nix
-  ];
-
+  buildInputs = [ nixdoc ];
   installPhase = ''
-    export NIX_STATE_DIR=$(mktemp -d)
-    nix-instantiate --eval --strict --json ${./lib-function-locations.nix} \
-      --arg nixpkgsPath "./." \
-      --argstr revision ${nixpkgs.rev or "master"} \
-      --argstr libsetsJSON ${lib.escapeShellArg (builtins.toJSON libsets)} \
-      --store $(mktemp -d) \
-      > locations.json
-
     function docgen {
       name=$1
       baseName=$2
       description=$3
       # TODO: wrap lib.$name in <literal>, make nixdoc not escape it
-      if [[ -e "lib/$baseName.nix" ]]; then
-        nixdoc -c "$name" -d "lib.$name: $description" -l locations.json -f "lib/$baseName.nix" > "$out/$name.md"
+      if [[ -e "../lib/$baseName.nix" ]]; then
+        nixdoc -c "$name" -d "lib.$name: $description" -l ${locationsJSON} -f "$baseName.nix" > "$out/$name.md"
       else
-        nixdoc -c "$name" -d "lib.$name: $description" -l locations.json -f "lib/$baseName/default.nix" > "$out/$name.md"
+        nixdoc -c "$name" -d "lib.$name: $description" -l ${locationsJSON} -f "$baseName/default.nix" > "$out/$name.md"
       fi
       echo "$out/$name.md" >> "$out/index.md"
     }
@@ -128,16 +32,9 @@ stdenvNoCC.mkDerivation {
     ```{=include=} sections auto-id-prefix=auto-generated
     EOF
 
-    ${lib.concatMapStrings (
-      {
-        name,
-        baseName ? name,
-        description,
-      }:
-      ''
-        docgen ${name} ${baseName} ${lib.escapeShellArg description}
-      ''
-    ) libsets}
+    ${lib.concatMapStrings ({ name, baseName ? name, description }: ''
+      docgen ${name} ${baseName} ${lib.escapeShellArg description}
+    '') libsets}
 
     echo '```' >> "$out/index.md"
   '';

doc/doc-support/lib-function-locations.nix

@@ -1,14 +1,13 @@
-{ nixpkgsPath, revision, libsetsJSON }:
+{ pkgs, nixpkgs ? { }, libsets }:
 let
-  lib = import (nixpkgsPath + "/lib");
-  libsets = builtins.fromJSON libsetsJSON;
+  revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.rev or "master");
 
   libDefPos = prefix: set:
     builtins.concatMap
       (name: [{
         name = builtins.concatStringsSep "." (prefix ++ [name]);
         location = builtins.unsafeGetAttrPos name set;
-      }] ++ lib.optionals
+      }] ++ nixpkgsLib.optionals
         (builtins.length prefix == 0 && builtins.isAttrs set.${name})
         (libDefPos (prefix ++ [name]) set.${name})
       ) (builtins.attrNames set);
@@ -21,6 +20,8 @@ let
       })
       (builtins.map (x: x.name) libsets);
 
+  nixpkgsLib = pkgs.lib;
+
   flattenedLibSubset = { subsetname, functions }:
   builtins.map
     (fn: {
@@ -37,13 +38,13 @@ let
       substr = builtins.substring prefixLen filenameLen filename;
       in substr;
 
-  removeNixpkgs = removeFilenamePrefix (builtins.toString nixpkgsPath);
+  removeNixpkgs = removeFilenamePrefix (builtins.toString pkgs.path);
 
   liblocations =
     builtins.filter
       (elem: elem.value != null)
-      (lib.lists.flatten
-        (locatedlibsets lib));
+      (nixpkgsLib.lists.flatten
+        (locatedlibsets nixpkgsLib));
 
   fnLocationRelative = { name, value }:
     {
@@ -71,4 +72,4 @@ let
     relativeLocs);
 
 in
-jsonLocs
+pkgs.writeText "locations.json" (builtins.toJSON jsonLocs)

doc/doc-support/options-doc.nix

@@ -1,28 +0,0 @@
-# To build this derivation, run `nix-build -A nixpkgs-manual.optionsDoc`
-{ lib, nixosOptionsDoc }:
-
-let
-  modules = lib.evalModules {
-    modules = [ ../../pkgs/top-level/config.nix ];
-    class = "nixpkgsConfig";
-  };
-
-  root = toString ../..;
-
-  transformDeclaration =
-    decl:
-    let
-      declStr = toString decl;
-      subpath = lib.removePrefix "/" (lib.removePrefix root declStr);
-    in
-    assert lib.hasPrefix root declStr;
-    {
-      url = "https://github.com/NixOS/nixpkgs/blob/master/${subpath}";
-      name = subpath;
-    };
-in
-nixosOptionsDoc {
-  inherit (modules) options;
-  documentType = "none";
-  transformOptions = opt: opt // { declarations = map transformDeclaration opt.declarations; };
-}

doc/doc-support/package.nix

@@ -1,106 +0,0 @@
-# This file describes the Nixpkgs manual, which happens to use module docs infra originally
-# developed for NixOS. To build this derivation, run `nix-build -A nixpkgs-manual`.
-#
-{
-  lib,
-  stdenvNoCC,
-  callPackage,
-  documentation-highlighter,
-  nixos-render-docs,
-  nixpkgs ? { },
-}:
-
-stdenvNoCC.mkDerivation (
-  finalAttrs:
-  let
-    inherit (finalAttrs.finalPackage.optionsDoc) optionsJSON;
-    inherit (finalAttrs.finalPackage) epub lib-docs pythonInterpreterTable;
-  in
-  {
-    name = "nixpkgs-manual";
-
-    nativeBuildInputs = [ nixos-render-docs ];
-
-    src = lib.fileset.toSource {
-      root = ../.;
-      fileset = lib.fileset.unions [
-        (lib.fileset.fileFilter (file: file.hasExt "md" || file.hasExt "md.in") ../.)
-        ../style.css
-        ../anchor-use.js
-        ../anchor.min.js
-        ../manpage-urls.json
-      ];
-    };
-
-    postPatch = ''
-      ln -s ${optionsJSON}/share/doc/nixos/options.json ./config-options.json
-    '';
-
-    buildPhase = ''
-      substituteInPlace ./languages-frameworks/python.section.md \
-        --subst-var-by python-interpreter-table "$(<"${pythonInterpreterTable}")"
-
-      cat \
-        ./functions/library.md.in \
-        ${lib-docs}/index.md \
-        > ./functions/library.md
-      substitute ./manual.md.in ./manual.md \
-        --replace-fail '@MANUAL_VERSION@' '${lib.version}'
-
-      mkdir -p out/media
-
-      mkdir -p out/highlightjs
-      cp -t out/highlightjs \
-        ${documentation-highlighter}/highlight.pack.js \
-        ${documentation-highlighter}/LICENSE \
-        ${documentation-highlighter}/mono-blue.css \
-        ${documentation-highlighter}/loader.js
-
-      cp -t out ./style.css ./anchor.min.js ./anchor-use.js
-
-      nixos-render-docs manual html \
-        --manpage-urls ./manpage-urls.json \
-        --revision ${nixpkgs.rev or "master"} \
-        --stylesheet style.css \
-        --stylesheet highlightjs/mono-blue.css \
-        --script ./highlightjs/highlight.pack.js \
-        --script ./highlightjs/loader.js \
-        --script ./anchor.min.js \
-        --script ./anchor-use.js \
-        --toc-depth 1 \
-        --section-toc-depth 1 \
-        manual.md \
-        out/index.html
-    '';
-
-    installPhase = ''
-      dest="$out/share/doc/nixpkgs"
-      mkdir -p "$(dirname "$dest")"
-      mv out "$dest"
-      mv "$dest/index.html" "$dest/manual.html"
-
-      cp ${epub} "$dest/nixpkgs-manual.epub"
-
-      mkdir -p $out/nix-support/
-      echo "doc manual $dest manual.html" >> $out/nix-support/hydra-build-products
-      echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products
-    '';
-
-    passthru = {
-      lib-docs = callPackage ./lib-function-docs.nix { inherit nixpkgs; };
-
-      epub = callPackage ./epub.nix { };
-
-      optionsDoc = callPackage ./options-doc.nix { };
-
-      pythonInterpreterTable = callPackage ./python-interpreter-table.nix { };
-
-      shell = callPackage ../../pkgs/tools/nix/web-devmode.nix {
-        buildArgs = "./.";
-        open = "/share/doc/nixpkgs/manual.html";
-      };
-
-      tests.manpage-urls = callPackage ../tests/manpage-urls.nix { };
-    };
-  }
-)

doc/doc-support/python-interpreter-table.nix

@@ -1,64 +0,0 @@
-# To build this derivation, run `nix-build -A nixpkgs-manual.pythonInterpreterTable`
-{
-  lib,
-  writeText,
-  pkgs,
-  pythonInterpreters,
-}:
-let
-  isPythonInterpreter =
-    name:
-    /*
-      NB: Package names that don't follow the regular expression:
-      - `python-cosmopolitan` is not part of `pkgs.pythonInterpreters`.
-      - `_prebuilt` interpreters are used for bootstrapping internally.
-      - `python3Minimal` contains python packages, left behind conservatively.
-      - `rustpython` lacks `pythonVersion` and `implementation`.
-    */
-    (lib.strings.match "(pypy|python)([[:digit:]]*)" name) != null;
-
-  interpreterName =
-    pname:
-    let
-      cuteName = {
-        cpython = "CPython";
-        pypy = "PyPy";
-      };
-      interpreter = pkgs.${pname};
-    in
-    "${cuteName.${interpreter.implementation}} ${interpreter.pythonVersion}";
-
-  interpreters = lib.reverseList (
-    lib.naturalSort (lib.filter isPythonInterpreter (lib.attrNames pythonInterpreters))
-  );
-
-  aliases =
-    pname:
-    lib.attrNames (
-      lib.filterAttrs (
-        name: value:
-        isPythonInterpreter name && name != pname && interpreterName name == interpreterName pname
-      ) pkgs
-    );
-
-  result = map (pname: {
-    inherit pname;
-    aliases = aliases pname;
-    interpreter = interpreterName pname;
-  }) interpreters;
-
-  toMarkdown =
-    data:
-    let
-      line = package: ''
-        | ${package.pname} | ${lib.concatStringsSep ", " package.aliases or [ ]} | ${package.interpreter} |
-      '';
-    in
-    lib.concatStringsSep "" (map line data);
-
-in
-writeText "python-interpreter-table.md" ''
-  | Package | Aliases | Interpeter |
-  |---------|---------|------------|
-  ${toMarkdown result}
-''

doc/functions/generators.section.md

@@ -54,4 +54,4 @@ merge:"diff3"
 Nix store paths can be converted to strings by enclosing a derivation attribute like so: `"${drv}"`.
 :::
 
-Detailed documentation for each generator can be found [here](#sec-functions-library-generators)
+Detailed documentation for each generator can be found in `lib/generators.nix`.

doc/functions/nix-gitignore.section.md

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

doc/hooks/breakpoint.section.md

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

doc/hooks/cernlib.section.md

@@ -1,3 +0,0 @@
-# CERNLIB {#cernlib-hook}
-
-This hook sets the `CERN`, `CERN_LEVEL`, and `CERN_ROOT` environment variables. They are part of [CERNLIB's build system](https://cernlib.web.cern.ch/install/install.html), and are are needed for some programs to compile correctly.

doc/hooks/haredo.section.md

@@ -1,29 +0,0 @@
-# `haredo` {#haredo-hook}
-
-This hook uses [the `haredo` command runner](https://sr.ht/~autumnull/haredo/) to build, check, and install the package. It overrides `buildPhase`, `checkPhase`, and `installPhase` by default.
-
-The hook builds its targets in parallel if [`config.enableParallelBuilding`](#var-stdenv-enableParallelBuilding) is set to `true`.
-
-## `buildPhase` {#haredo-hook-buildPhase}
-
-This phase attempts to build the default target.
-
-[]{#haredo-hook-haredoBuildTargets} Targets can be explicitly set by adding a string to the `haredoBuildTargets` list.
-
-[]{#haredo-hook-dontUseHaredoBuild} This behavior can be disabled by setting `dontUseHaredoBuild` to `true`.
-
-## `checkPhase` {#haredo-hook-checkPhase}
-
-This phase searches for the `check.do` or `test.do` targets, running them if they exist.
-
-[]{#haredo-hook-haredoCheckTargets} Targets can be explicitly set by adding a string to the `haredoCheckTargets` list.
-
-[]{#haredo-hook-dontUseHaredoCheck} This behavior can be disabled by setting `dontUseHaredoCheck` to `true`.
-
-## `installPhase` {#haredo-hook-installPhase}
-
-This phase attempts to build the `install.do` target, if it exists.
-
-[]{#haredo-hook-haredoInstallTargets} Targets can be explicitly set by adding a string to the `haredoInstallTargets` list.
-
-[]{#haredo-hook-dontUseHaredoInstall} This behavior can be disabled by setting `dontUseHaredoInstall` to `true`.

doc/hooks/index.md

@@ -10,14 +10,11 @@ automake.section.md
 autopatchelf.section.md
 bmake.section.md
 breakpoint.section.md
-cernlib.section.md
 cmake.section.md
 gdk-pixbuf.section.md
 ghc.section.md
 gnome.section.md
-haredo.section.md
 installShellFiles.section.md
-just.section.md
 libiconv.section.md
 libxml2.section.md
 meson.section.md
@@ -27,13 +24,11 @@ patch-rc-path-hooks.section.md
 perl.section.md
 pkg-config.section.md
 postgresql-test-hook.section.md
-premake.section.md
 python.section.md
 scons.section.md
 tetex-tex-live.section.md
 unzip.section.md
 validatePkgConfig.section.md
-versionCheckHook.section.md
 waf.section.md
 zig.section.md
 xcbuild.section.md

doc/hooks/installShellFiles.section.md

@@ -1,110 +1,25 @@
 # `installShellFiles` {#installshellfiles}
 
-This hook adds helpers that install artifacts like executable files, manpages
-and shell completions.
+This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
 
-It exposes the following functions that can be used from your `postInstall`
-hook:
+The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct `share/man/man<section>/` directory, in [`outputMan`](#outputman).
 
-## `installBin` {#installshellfiles-installbin}
-
-The `installBin` function takes one or more paths to files to install as
-executable files.
-
-This function will place them into [`outputBin`](#outputbin).
-
-### Example Usage {#installshellfiles-installbin-exampleusage}
+The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
 
 ```nix
-{
-  nativeBuildInputs = [ installShellFiles ];
-
-  # Sometimes the file has an undersirable name. It should be renamed before
-  # being installed via installBin
-  postInstall = ''
-    mv a.out delmar
-    installBin foobar delmar
-  '';
-}
-```
-
-## `installManPage` {#installshellfiles-installmanpage}
-
-The `installManPage` function takes one or more paths to manpages to install.
-
-The manpages must have a section suffix, and may optionally be compressed (with
-`.gz` suffix). This function will place them into the correct
-`share/man/man<section>/` directory in [`outputMan`](#outputman).
-
-### Example Usage {#installshellfiles-installmanpage-exampleusage}
-
-```nix
-{
-  nativeBuildInputs = [ installShellFiles ];
-
-  # Sometimes the manpage file has an undersirable name; e.g. it conflicts with
-  # another software with an equal name. It should be renamed before being
-  # installed via installManPage
-  postInstall = ''
-    mv fromsea.3 delmar.3
-    installManPage foobar.1 delmar.3
-  '';
-}
-```
-
-## `installShellCompletion` {#installshellfiles-installshellcompletion}
-
-The `installShellCompletion` function takes one or more paths to shell
-completion files.
-
-By default it will autodetect the shell type from the completion file extension,
-but you may also specify it by passing one of `--bash`, `--fish`, or
-`--zsh`. These flags apply to all paths listed after them (up until another
-shell flag is given). Each path may also have a custom installation name
-provided by providing a flag `--name NAME` before the path. If this flag is not
-provided, zsh completions will be renamed automatically such that `foobar.zsh`
-becomes `_foobar`. A root name may be provided for all paths using the flag
-`--cmd NAME`; this synthesizes the appropriate name depending on the shell
-(e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for
-zsh).
-
-### Example Usage {#installshellfiles-installshellcompletion-exampleusage}
-
-```nix
-{
-  nativeBuildInputs = [ installShellFiles ];
-  postInstall = ''
-    # explicit behavior
-    installShellCompletion --bash --name foobar.bash share/completions.bash
-    installShellCompletion --fish --name foobar.fish share/completions.fish
-    installShellCompletion --zsh --name _foobar share/completions.zsh
-    # implicit behavior
-    installShellCompletion share/completions/foobar.{bash,fish,zsh}
-  '';
-}
-```
-
-The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which
-case the shell and name must be provided (see below).
-
-If the destination shell completion file is not actually present or consists of
-zero bytes after calling `installShellCompletion` this is treated as a build
-failure. In particular, if completion files are not vendored but are generated
-by running an executable, this is likely to fail in cross compilation
-scenarios. The result will be a zero byte completion file and hence a build
-failure. To prevent this, guard the completion generation commands.
-
-### Example Usage {#installshellfiles-installshellcompletion-exampleusage-guarded}
-
-```nix
-{
-  nativeBuildInputs = [ installShellFiles ];
-  postInstall = lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) ''
-    # using named fd
-    installShellCompletion --cmd foobar \
-      --bash <($out/bin/foobar --bash-completion) \
-      --fish <($out/bin/foobar --fish-completion) \
-      --zsh <($out/bin/foobar --zsh-completion)
-  '';
-}
+nativeBuildInputs = [ installShellFiles ];
+postInstall = ''
+  installManPage doc/foobar.1 doc/barfoo.3
+  # explicit behavior
+  installShellCompletion --bash --name foobar.bash share/completions.bash
+  installShellCompletion --fish --name foobar.fish share/completions.fish
+  installShellCompletion --zsh --name _foobar share/completions.zsh
+  # implicit behavior
+  installShellCompletion share/completions/foobar.{bash,fish,zsh}
+  # using named fd
+  installShellCompletion --cmd foobar \
+    --bash <($out/bin/foobar --bash-completion) \
+    --fish <($out/bin/foobar --fish-completion) \
+    --zsh <($out/bin/foobar --zsh-completion)
+'';
 ```

doc/hooks/just.section.md

@@ -1,23 +0,0 @@
-# `just` {#just-hook}
-
-This setup hook attempts to use [the `just` command runner](https://just.systems/man/en/) to build, check, and install the package. The hook overrides `buildPhase`, `checkPhase`, and `installPhase` by default.
-
-[]{#just-hook-justFlags} The `justFlags` variable can be set to a list of strings to add additional flags passed to all invocations of `just`.
-
-## `buildPhase` {#just-hook-buildPhase}
-
-This phase attempts to invoke `just` with [the default recipe](https://just.systems/man/en/chapter_23.html).
-
-[]{#just-hook-dontUseJustBuild} This behavior can be disabled by setting `dontUseJustBuild` to `true`.
-
-## `checkPhase` {#just-hook-checkPhase}
-
-This phase attempts to invoke the `just test` recipe, if it is available. This can be overrided by setting `checkTarget` to a string.
-
-[]{#just-hook-dontUseJustCheck} This behavior can be disabled by setting `dontUseJustCheck` to `true`.
-
-## `installPhase` {#just-hook-installPhase}
-
-This phase attempts to invoke the `just install` recipe.
-
-[]{#just-hook-dontUseJustInstall} This behavior can be disabled by setting `dontUseJustInstall` to `true`.

doc/hooks/mpi-check-hook.section.md

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

doc/hooks/premake.section.md

@@ -1,7 +0,0 @@
-# Premake {#premake-hook}
-
-This setup hook attempts to configure the package using [the Premake build configuration system](https://premake.github.io/). It overrides the `configurePhase` by default, if none exists.
-
-[]{#premake-hook-premakefile} The Premakefile to use can be specified by setting `premakefile` in the derivation.
-
-[]{#premake-hook-premakeFlagsArray} The flags passed to Premake can be configured by adding strings to the `premakeFlags` list.

doc/hooks/versionCheckHook.section.md

@@ -1,35 +0,0 @@
-# versionCheckHook {#versioncheckhook}
-
-This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. You use it like this:
-
-```nix
-{
-  lib,
-  stdenv,
-  versionCheckHook,
-  # ...
-}:
-
-stdenv.mkDerivation (finalAttrs: {
-  # ...
-
-  nativeInstallCheckInputs = [
-    versionCheckHook
-  ];
-  doInstallCheck = true;
-
-  # ...
-})
-```
-
-Note that for [`buildPythonPackage`](#buildpythonpackage-function) and [`buildPythonApplication`](#buildpythonapplication-function), `doInstallCheck` is enabled by default.
-
-It does so in a clean environment (using `env --ignore-environment`), and it checks for the `${version}` string in both the `stdout` and the `stderr` of the command. It will report to you in the build log the output it received and it will fail the build if it failed to find `${version}`.
-
-The variables that this phase control are:
-
-- `dontVersionCheck`: Disable adding this hook to the [`preDistPhases`](#var-stdenv-preDist). Useful if you do want to load the bash functions of the hook, but run them differently.
-- `versionCheckProgram`: The full path to the program that should print the `${version}` string. Defaults roughly to `${placeholder "out"}/bin/${pname}`. Using `$out` in the value of this variable won't work, as environment variables from this variable are not expanded by the hook. Hence using `placeholder` is unavoidable.
-- `versionCheckProgramArg`: The argument that needs to be passed to `versionCheckProgram`. If undefined the hook tries first `--help` and then `--version`. Examples: `version`, `-V`, `-v`.
-- `preVersionCheck`: A hook to run before the check is done.
-- `postVersionCheck`: A hook to run after the check is done.

doc/hooks/waf.section.md

@@ -20,6 +20,10 @@ If `wafPath` doesn't exist, then `wafHook` will copy the `waf` provided from Nix
 
 Controls the flags passed to waf tool during build and install phases. For settings specific to build or install phases, use `wafBuildFlags` or `wafInstallFlags` respectively.
 
+#### `dontAddWafCrossFlags` {#dont-add-waf-cross-flags}
+
+When set to `true`, don't add cross compilation flags during configure phase.
+
 #### `dontUseWafConfigure` {#dont-use-waf-configure}
 
 When set to true, don't use the predefined `wafConfigurePhase`.

doc/hooks/zig.section.md

@@ -9,14 +9,14 @@ In Nixpkgs, `zig.hook` overrides the default build, check and install phases.
 ```nix
 { lib
 , stdenv
-, zig
+, zig_0_11
 }:
 
 stdenv.mkDerivation {
   # . . .
 
   nativeBuildInputs = [
-    zig.hook
+    zig_0_11.hook
   ];
 
   zigBuildFlags = [ "-Dman-pages=true" ];

doc/interoperability.md

@@ -1,5 +0,0 @@
-# Interoperability Standards {#part-interoperability}
-
-```{=include=} chapters
-interoperability/cyclonedx.md
-```

doc/interoperability/cyclonedx.md

@@ -1,79 +0,0 @@
-# CycloneDX {#chap-interop-cyclonedx}
-
-[OWASP](https://owasp.org/) [CycloneDX](https://cyclonedx.org/) is a Software [Bill of Materials](https://en.wikipedia.org/wiki/Bill_of_materials) (SBOM) standard.
-The standards described here are for including Nix specific information within SBOMs in a way that is interoperable with external SBOM tooling.
-
-## `nix` Namespace Property Taxonomy  {#sec-interop.cylonedx-nix}
-
-The following tables describe namespaces for [properties](https://cyclonedx.org/docs/1.6/json/#components_items_properties) that may be attached to components within SBOMs.
-Component properties are lists of name-value-pairs where values must be strings.
-Properties with the same name may appear more than once.
-Names and values are case-sensitive.
-
-| Property         | Description |
-|------------------|-------------|
-| `nix:store_path` | A Nix store path for the given component. This property should be contextualized by additional properties that describe the production of the store path, such as those from the `nix:narinfo:` and `nix:fod` namespaces. |
-
-
-| Namespace     | Description |
-|---------------|-------------|
-| [`nix:narinfo`](#sec-interop.cylonedx-narinfo) | Namespace for properties that are specific to how a component is stored as a [Nix archive](https://nixos.org/manual/nix/stable/glossary#gloss-nar) (NAR) in a [binary cache](https://nixos.org/manual/nix/stable/glossary#gloss-binary-cache). |
-| [`nix:fod`](#sec-interop.cylonedx-fod) | Namespace for properties that describe a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation). |
-
-
-### `nix:narinfo` {#sec-interop.cylonedx-narinfo}
-
-Narinfo properties describe component archives that may be available from binary caches.
-The `nix:narinfo` properties should be accompanied by a `nix:store_path` property within the same property list.
-
-| Property                  | Description |
-|---------------------------|-------------|
-| `nix:narinfo:store_path`  | Store path for the given store component. |
-| `nix:narinfo:url`         | URL path component. |
-| `nix:narinfo:nar_hash`    | Hash of the file system object part of the component when serialized as a Nix Archive. |
-| `nix:narinfo:nar_size`    | Size of the component when serialized as a Nix Archive. |
-| `nix:narinfo:compression` | The compression format that component archive is in. |
-| `nix:narinfo:file_hash`   | A digest for the compressed component archive itself, as opposed to the data contained within. |
-| `nix:narinfo:file_size`   | The size of the compressed component archive itself. |
-| `nix:narinfo:deriver`     | The path to the derivation from which this component is produced. |
-| `nix:narinfo:system`      | The hardware and software platform on which this component is produced. |
-| `nix:narinfo:sig`         | Signatures claiming that this component is what it claims to be. |
-| `nix:narinfo:ca`          | Content address of this store object's file system object, used to compute its store path. |
-| `nix:narinfo:references`  | A whitespace separated array of store paths that this component references. |
-
-### `nix:fod` {#sec-interop.cylonedx-fod}
-
-FOD properties describe a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation).
-The `nix:fod:method` property is required and must be accompanied by a `nix:store_path` property within the same property list.
-All other properties in this namespace are method-specific.
-To reproduce the build of a component the `nix:fod:method` value is resolved to an [appropriate function](#chap-pkgs-fetchers) within Nixpkgs whose arguments intersect with the given properties.
-When generating `nix:fod` properties the method selected should be a stable function with a minimal number arguments.
-For example, the `fetchFromGitHub` is commonly used within Nixpkgs but should be reduced to a call to the function by which it is implemented, `fetchzip`.
-
-| Property         | Description |
-|------------------|-------------|
-| `nix:fod:method` | Nixpkg function that produces this FOD. Required. Examples: `"fetchzip"`, `"fetchgit"` |
-| `nix:fod:name`   | Derivation name, present when method is `"fetchzip"` |
-| `nix:fod:ref`    | [Git ref](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrefaref), present when method is `"fetchgit"` |
-| `nix:fod:rev`    | [Git rev](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrevisionarevision), present when method is `"fetchgit"` |
-| `nix:fod:sha256` | FOD hash |
-| `nix:fod:url`    | URL to fetch |
-
-
-`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 }:
-let
-  fodProps = filterPropertiesToAttrs "nix:fod:" properties;
-
-  methods = {
-    fetchzip =
-      { name, url, sha256, ... }:
-      pkgs.fetchzip {
-        inherit name url sha256;
-      };
-  };
-
-in methods.${fodProps.method} fodProps
-```

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,7 +180,6 @@ 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
@@ -194,7 +193,7 @@ mkDerivation {
   version = "1.5.0";
   pname = "iowa-stdlib";
 
-  src = <...>;
+  src = ...
 
   libraryFile = "";
   libraryName = "IAL-1.3";

doc/languages-frameworks/android.section.md

@@ -3,36 +3,10 @@
 The Android build environment provides three major features and a number of
 supporting features.
 
-## Using androidenv with Android Studio {#using-androidenv-with-android-studio}
-
-Use the `android-studio-full` attribute for a very complete Android SDK, including system images:
-
-```nix
-buildInputs = [ android-studio-full ];
-```
-
-This is identical to:
-
-```nix
-buildInputs = [ androidStudioPackages.stable.full ];
-```
-
-Alternatively, you can pass composeAndroidPackages to the `withSdk` passthru:
-
-```nix
-buildInputs = [
-  (android-studio.withSdk (androidenv.composeAndroidPackages {
-    includeNDK = true;
-  }).androidsdk)
-];
-```
-
-These will export ANDROID_SDK_ROOT and ANDROID_NDK_ROOT to the SDK and NDK directories
-in the specified Android build environment.
-
 ## Deploying an Android SDK installation with plugins {#deploying-an-android-sdk-installation-with-plugins}
 
-Alternatively, you can deploy the SDK separately with a desired set of plugins, or subsets of an SDK.
+The first use case is deploying the SDK with a desired set of plugins or subsets
+of an SDK.
 
 ```nix
 with import <nixpkgs> {};
@@ -130,20 +104,18 @@ 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:
@@ -171,14 +143,16 @@ androidComposition.platform-tools
 ## Using predefined Android package compositions {#using-predefined-android-package-compositions}
 
 In addition to composing an Android package set manually, it is also possible
-to use a predefined composition that contains a fairly complete set of Android packages:
+to use a predefined composition that contains all basic packages for a specific
+Android version, such as version 9.0 (API-level 28).
 
-The following Nix expression can be used to deploy the entire SDK:
+The following Nix expression can be used to deploy the entire SDK with all basic
+plugins:
 
 ```nix
 with import <nixpkgs> {};
 
-androidenv.androidPkgs.androidsdk
+androidenv.androidPkgs_9_0.androidsdk
 ```
 
 It is also possible to use one plugin only:
@@ -186,9 +160,50 @@ It is also possible to use one plugin only:
 ```nix
 with import <nixpkgs> {};
 
-androidenv.androidPkgs.platform-tools
+androidenv.androidPkgs_9_0.platform-tools
 ```
 
+## Building an Android application {#building-an-android-application}
+
+In addition to the SDK, it is also possible to build an Ant-based Android
+project and automatically deploy all the Android plugins that a project
+requires.
+
+
+```nix
+with import <nixpkgs> {};
+
+androidenv.buildApp {
+  name = "MyAndroidApp";
+  src = ./myappsources;
+  release = true;
+
+  # If release is set to true, you need to specify the following parameters
+  keyStore = ./keystore;
+  keyAlias = "myfirstapp";
+  keyStorePassword = "mykeystore";
+  keyAliasPassword = "myfirstapp";
+
+  # Any Android SDK parameters that install all the relevant plugins that a
+  # build requires
+  platformVersions = [ "24" ];
+
+  # When we include the NDK, then ndk-build is invoked before Ant gets invoked
+  includeNDK = true;
+}
+```
+
+Aside from the app-specific build parameters (`name`, `src`, `release` and
+keystore parameters), the `buildApp {}` function supports all the function
+parameters that the SDK composition function (the function shown in the
+previous section) supports.
+
+This build function is particularly useful when it is desired to use
+[Hydra](https://nixos.org/hydra): the Nix-based continuous integration solution
+to build Android apps. An Android APK gets exposed as a build product and can be
+installed on any Android device with a web browser by navigating to the build
+result page.
+
 ## Spawning emulator instances {#spawning-emulator-instances}
 
 For testing purposes, it can also be quite convenient to automatically generate
@@ -232,11 +247,11 @@ In addition to prebuilt APKs, you can also bind the APK parameter to a
 
 ## Notes on environment variables in Android projects {#notes-on-environment-variables-in-android-projects}
 
-* `ANDROID_HOME` should point to the Android SDK. In your Nix expressions, this should be
-  `${androidComposition.androidsdk}/libexec/android-sdk`. Note that `ANDROID_SDK_ROOT` is deprecated,
+* `ANDROID_SDK_ROOT` should point to the Android SDK. In your Nix expressions, this should be
+  `${androidComposition.androidsdk}/libexec/android-sdk`. Note that `ANDROID_HOME` is deprecated,
   but if you rely on tools that need it, you can export it too.
 * `ANDROID_NDK_ROOT` should point to the Android NDK, if you're doing NDK development.
-  In your Nix expressions, this should be `${ANDROID_HOME}/ndk-bundle`.
+  In your Nix expressions, this should be `${ANDROID_SDK_ROOT}/ndk-bundle`.
 
 If you are running the Android Gradle plugin, you need to export GRADLE_OPTS to override aapt2
 to point to the aapt2 binary in the Nix store as well, or use a FHS environment so the packaged
@@ -250,11 +265,11 @@ let
   androidComposition = <...>;
 in
 pkgs.mkShell rec {
-  ANDROID_HOME = "${androidComposition.androidsdk}/libexec/android-sdk";
-  ANDROID_NDK_ROOT = "${ANDROID_HOME}/ndk-bundle";
+  ANDROID_SDK_ROOT = "${androidComposition.androidsdk}/libexec/android-sdk";
+  ANDROID_NDK_ROOT = "${ANDROID_SDK_ROOT}/ndk-bundle";
 
   # Use the same buildToolsVersion here
-  GRADLE_OPTS = "-Dorg.gradle.project.android.aapt2FromMavenOverride=${ANDROID_HOME}/build-tools/${buildToolsVersion}/aapt2";
+  GRADLE_OPTS = "-Dorg.gradle.project.android.aapt2FromMavenOverride=${ANDROID_SDK_ROOT}/build-tools/${buildToolsVersion}/aapt2";
 }
 ```
 
@@ -270,18 +285,18 @@ let
   androidComposition = <...>;
 in
 pkgs.mkShell rec {
-  ANDROID_HOME = "${androidComposition.androidsdk}/libexec/android-sdk";
-  ANDROID_NDK_ROOT = "${ANDROID_HOME}/ndk-bundle";
+  ANDROID_SDK_ROOT = "${androidComposition.androidsdk}/libexec/android-sdk";
+  ANDROID_NDK_ROOT = "${ANDROID_SDK_ROOT}/ndk-bundle";
 
   # Use the same cmakeVersion here
   shellHook = ''
-    export PATH="$(echo "$ANDROID_HOME/cmake/${cmakeVersion}".*/bin):$PATH"
+    export PATH="$(echo "$ANDROID_SDK_ROOT/cmake/${cmakeVersion}".*/bin):$PATH"
   '';
 }
 ```
 
-Note that running Android Studio with ANDROID_HOME set will automatically write a
-`local.properties` file with `sdk.dir` set to $ANDROID_HOME if one does not already
+Note that running Android Studio with ANDROID_SDK_ROOT set will automatically write a
+`local.properties` file with `sdk.dir` set to $ANDROID_SDK_ROOT if one does not already
 exist. If you are using the NDK as well, you may have to add `ndk.dir` to this file.
 
 An example shell.nix that does all this for you is provided in examples/shell.nix.
@@ -332,44 +347,3 @@ To update the expressions run the `generate.sh` script that is stored in the
 ```bash
 ./generate.sh
 ```
-
-## Building an Android application with Ant {#building-an-android-application-with-ant}
-
-In addition to the SDK, it is also possible to build an Ant-based Android
-project and automatically deploy all the Android plugins that a project
-requires. Most newer Android projects use Gradle, and this is included for historical
-purposes.
-
-```nix
-with import <nixpkgs> {};
-
-androidenv.buildApp {
-  name = "MyAndroidApp";
-  src = ./myappsources;
-  release = true;
-
-  # If release is set to true, you need to specify the following parameters
-  keyStore = ./keystore;
-  keyAlias = "myfirstapp";
-  keyStorePassword = "mykeystore";
-  keyAliasPassword = "myfirstapp";
-
-  # Any Android SDK parameters that install all the relevant plugins that a
-  # build requires
-  platformVersions = [ "24" ];
-
-  # When we include the NDK, then ndk-build is invoked before Ant gets invoked
-  includeNDK = true;
-}
-```
-
-Aside from the app-specific build parameters (`name`, `src`, `release` and
-keystore parameters), the `buildApp {}` function supports all the function
-parameters that the SDK composition function (the function shown in the
-previous section) supports.
-
-This build function is particularly useful when it is desired to use
-[Hydra](https://nixos.org/hydra): the Nix-based continuous integration solution
-to build Android apps. An Android APK gets exposed as a build product and can be
-installed on any Android device with a web browser by navigating to the build
-result page.

doc/languages-frameworks/beam.section.md

@@ -117,7 +117,6 @@ 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: {
@@ -139,9 +138,8 @@ 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.
@@ -155,13 +153,11 @@ 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.

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,13 +42,11 @@ 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:

doc/languages-frameworks/chicken.section.md

@@ -13,12 +13,10 @@ 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
@@ -69,12 +67,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`.
-<...>
+# ...
 ```

doc/languages-frameworks/coq.section.md

@@ -23,13 +23,12 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
   * if it is a string of the form `owner:branch` then it tries to download the `branch` of owner `owner` for a project of the same name using the same vcs, and the `version` attribute of the resulting derivation is set to `"dev"`, additionally if the owner is not provided (i.e. if the `owner:` prefix is missing), it defaults to the original owner of the package (see below),
   * if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
 * `defaultVersion` (optional). Coq libraries may be compatible with some specific versions of Coq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `coq` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `coqPackages` attribute set.
-* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `hash` attribute (you may put the empty string `""` in order to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
+* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `sha256` attribute (you may put the empty string `""` in order to automatically insert a fake sha256, this will trigger an error which will allow you to find the correct sha256), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
 * `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `hash` and returns an attribute set with a `version` and `src`.
 * `repo` (optional, defaults to the value of `pname`),
 * `owner` (optional, defaults to `"coq-community"`).
 * `domain` (optional, defaults to `"github.com"`), domains including the strings `"github"` or `"gitlab"` in their names are automatically supported, otherwise, one must change the `fetcher` argument to support them (cf `pkgs/development/coq-modules/heq/default.nix` for an example),
 * `releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
-* `releaseArtifact` (optional, defaults to `(v: null)`), provides a default mapping from release names to artifact names (only works for github artifact for now),
 * `displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
 * `namePrefix` (optional, defaults to `[ "coq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
 * `nativeBuildInputs` (optional), is a list of executables that are required to build the current derivation, in addition to the default ones (namely `which`, `dune` and `ocaml` depending on whether `useDune`, `useDuneifVersion` and `mlPlugin` are set).
@@ -57,36 +56,41 @@ Here is a simple package example. It is a pure Coq library, thus it depends on C
 { lib, mkCoqDerivation, version ? null
 , coq, mathcomp, mathcomp-finmap, mathcomp-bigenough }:
 
+let
+  inherit (lib) licenses maintainers switch;
+  inherit (lib.versions) range;
+in
+
 mkCoqDerivation {
   /* namePrefix leads to e.g. `name = coq8.11-mathcomp1.11-multinomials-1.5.2` */
   namePrefix = [ "coq" "mathcomp" ];
   pname = "multinomials";
   owner = "math-comp";
   inherit version;
-  defaultVersion = with lib.versions; lib.switch [ coq.version mathcomp.version ] [
-      { 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"; }
+  defaultVersion =  with versions; switch [ coq.version mathcomp.version ] [
+      { cases = [ (range "8.7" "8.12")  "1.11.0" ];             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 = [ "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=";
-    "1.5.0".hash = "sha256-HIK0f21G69oEW8JG46gSBde/Q2LR3GiBCv680gHbmRg=";
-    "1.5.0".rev  = "1.5";
-    "1.4".hash   = "sha256-F9g3MSIr3B6UZ3p8QWjz3/Jpw9sudJ+KRlvjiHSO024=";
-    "1.3".hash   = "sha256-BPJTlAL0ETHvLMBslE0KFVt3DNoaGuMrHt2SBGyJe1A=";
-    "1.2".hash   = "sha256-mHXBXSLYO4BN+jfN50y/+XCx0Qq5g4Ac2Y/qlsbgAdY=";
-    "1.1".hash   = "sha256-ejAsMQbB/LtU9j+g160VdGXULrCe9s0gBWzyhKqmCuE=";
-    "1.0".hash   = "sha256-tZTOltEBBKWciDxDMs/Ye4Jnq/33CANrHJ4FBMPtq+I=";
+    "1.5.2".sha256 = "15aspf3jfykp1xgsxf8knqkxv8aav2p39c2fyirw7pwsfbsv2c4s";
+    "1.5.1".sha256 = "13nlfm2wqripaq671gakz5mn4r0xwm0646araxv0nh455p9ndjs3";
+    "1.5.0".sha256 = "064rvc0x5g7y1a0nip6ic91vzmq52alf6in2bc2dmss6dmzv90hw";
+    "1.5.0".rev    = "1.5";
+    "1.4".sha256   = "0vnkirs8iqsv8s59yx1fvg1nkwnzydl42z3scya1xp1b48qkgn0p";
+    "1.3".sha256   = "0l3vi5n094nx3qmy66hsv867fnqm196r8v605kpk24gl0aa57wh4";
+    "1.2".sha256   = "1mh1w339dslgv4f810xr1b8v2w7rpx6fgk9pz96q0fyq49fw2xcq";
+    "1.1".sha256   = "1q8alsm89wkc0lhcvxlyn0pd8rbl2nnxg81zyrabpz610qqjqc3s";
+    "1.0".sha256   = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
   };
 
   propagatedBuildInputs =
     [ mathcomp.ssreflect mathcomp.algebra mathcomp-finmap mathcomp-bigenough ];
 
   meta = {
-    description = "Coq/SSReflect Library for Monoidal Rings and Multinomials";
-    license = lib.licenses.cecill-c;
+    description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
+    license = licenses.cecill-c;
   };
 }
 ```
@@ -127,7 +131,7 @@ For example, here is how you could locally add a new release of the `multinomial
 coqPackages.lib.overrideCoqDerivation
   {
     defaultVersion = "2.0";
-    release."2.0".hash = "sha256-czoP11rtrIM7+OLdMisv2EF7n/IbGuwFxHiPtg3qCNM=";
+    release."2.0".sha256 = "1lq8x86vd3vqqh2yq6hvyagpnhfq5wmk5pg2z0xq7b7dbbbhyfkk";
   }
   coqPackages.multinomials
 ```

doc/languages-frameworks/crystal.section.md

@@ -33,26 +33,22 @@ 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:

doc/languages-frameworks/cuda.section.md

@@ -16,28 +16,24 @@ 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
@@ -148,4 +144,4 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
 | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files |
 | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries |
 
-In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary.
+In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary.

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:

doc/languages-frameworks/dart.section.md

@@ -98,12 +98,10 @@ The function `buildFlutterApplication` builds Flutter applications.
 
 See the [Dart documentation](#ssec-dart-applications) for more details on required files and arguments.
 
-`flutter` in Nixpkgs always points to `flutterPackages.stable`, which is the latest packaged version. To avoid unforeseen breakage during upgrade, packages in Nixpkgs should use a specific flutter version, such as `flutter319` and `flutter322`, instead of using `flutter` directly.
-
 ```nix
-{  flutter322, fetchFromGitHub }:
+{  flutter, fetchFromGitHub }:
 
-flutter322.buildFlutterApplication {
+flutter.buildFlutterApplication {
   pname = "firmware-updater";
   version = "0-unstable-2023-04-30";
 
@@ -114,7 +112,7 @@ flutter322.buildFlutterApplication {
     owner = "canonical";
     repo = "firmware-updater";
     rev = "6e7dbdb64e344633ea62874b54ff3990bd3b8440";
-    hash = "sha256-s5mwtr5MSPqLMN+k851+pFIFFPa0N1hqz97ys050tFA=";
+    sha256 = "sha256-s5mwtr5MSPqLMN+k851+pFIFFPa0N1hqz97ys050tFA=";
     fetchSubmodules = true;
   };
 

doc/languages-frameworks/dhall.section.md

@@ -187,7 +187,6 @@ 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 =
@@ -195,7 +194,6 @@ Dhall overlay like this:
 
     true = self.callPackage ./true.nix { };
   };
-}
 ```
 
 … and now the Prelude will contain the fully decoded result of interpreting
@@ -431,26 +429,22 @@ $ 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}
@@ -460,13 +454,11 @@ 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

doc/languages-frameworks/dlang.section.md

@@ -1,69 +0,0 @@
-# D (Dlang) {#dlang}
-
-Nixpkgs provides multiple D compilers such as `ldc`, `dmd` and `gdc`.
-These can be used like any other package during build time.
-
-However, Nixpkgs provides a build helper for compiling packages using the `dub` package manager.
-
-Here's an example:
-```nix
-{
-  lib,
-  buildDubPackage,
-  fetchFromGitHub,
-  ncurses,
-  zlib,
-}:
-
-buildDubPackage rec {
-  pname = "btdu";
-  version = "0.5.1";
-
-  src = fetchFromGitHub {
-    owner = "CyberShadow";
-    repo = "btdu";
-    rev = "v${version}";
-    hash = "sha256-3sSZq+5UJH02IO0Y1yL3BLHDb4lk8k6awb5ZysBQciE=";
-  };
-
-  # generated by dub-to-nix, see below
-  dubLock = ./dub-lock.json;
-
-  buildInputs = [
-    ncurses
-    zlib
-  ];
-
-  installPhase = ''
-    runHook preInstall
-    install -Dm755 btdu -t $out/bin
-    runHook postInstall
-  '';
-}
-```
-
-Note that you need to define `installPhase` because `dub` doesn't know where files should go in `$out`.
-
-Also note that running `dub test` is disabled by default. You can enable it by setting `doCheck = true`.
-
-## Lockfiles {#dub-lockfiles}
-Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash based.
-
-A lockfile can be generated using the `dub-to-nix` helper package.
-* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`
-* Then navigate to the root of the source of the program you want to package
-* Finally, run `dub-to-nix` and it will print the lockfile to stdout. You could pipe stdout into a text file or just copy the output manually into a file.
-
-## `buildDubPackage` parameters {#builddubpackage-parameters}
-
-The `buildDubPackage` function takes an attrset of parameters that are passed on to `stdenv.mkDerivation`.
-
-The following parameters are specific to `buildDubPackage`:
-
-* `dubLock`: A lockfile generated by `dub-to-nix` from the source of the package. Can be either a path to the file, or an attrset already parsed with `lib.importJSON`.
-  The latter useful if the package uses `dub` dependencies not already in the lockfile. (e.g. if the package calls `dub run some-dub-package` manually)
-* `dubBuildType ? "release"`: The build type to pass to `dub build` as a value for the `--build=` flag.
-* `dubFlags ? []`: The flags to pass to `dub build` and `dub test`.
-* `dubBuildFlags ? []`: The flags to pass to `dub build`.
-* `dubTestFlags ? []`: The flags to pass to `dub test`.
-* `compiler ? ldc`: The D compiler to be used by `dub`.

doc/languages-frameworks/dotnet.section.md

@@ -93,18 +93,18 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
 To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
 
 * `projectFile` is used for specifying the dotnet project file, relative to the source root. These have `.sln` (entire solution) or `.csproj` (single project) file extensions. This can be a list of multiple projects as well. When omitted, will attempt to find and build the solution (`.sln`). If running into problems, make sure to set it to a file (or a list of files) with the `.csproj` extension - building applications as entire solutions is not fully supported by the .NET CLI.
-* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. For compatibility, if the argument is a list of derivations, they will be added to `buildInputs`.
+* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
 ::: {.note}
 For more detail about managing the `deps.nix` file, see [Generating and updating NuGet dependencies](#generating-and-updating-nuget-dependencies)
 :::
 
-* `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `buildInputs`.
-* `buildInputs` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `buildInputs`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
+* `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
+* `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
  For example, your project has a local dependency:
  ```xml
      <ProjectReference Include="../foo/bar.fsproj" />
  ```
- To enable discovery through `buildInputs` you would need to add:
+ To enable discovery through `projectReferences` you would need to add:
  ```xml
      <ProjectReference Include="../foo/bar.fsproj" />
      <PackageReference Include="bar" Version="*" Condition=" '$(ContinuousIntegrationBuild)'=='true' "/>
@@ -117,8 +117,8 @@ For more detail about managing the `deps.nix` file, see [Generating and updating
 * `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the users' .NET runtime.
 * `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used. You can also set this to the result of `dotnetSdkPackages.combinePackages`, if the project uses multiple SDKs to build.
 * `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
+* `dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.
 * `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this. Note that if set, only tests from this project are executed.
-* `testFilters` is used to disable running unit tests based on various [filters](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-test#filter-option-details). This gets passed as: `dotnet test --filter "{}"`, with each filter being concatenated using `"&"`.
 * `disabledTests` is used to disable running specific unit tests. This gets passed as: `dotnet test --filter "FullyQualifiedName!={}"`, to ensure compatibility with all unit test frameworks.
 * `dotnetRestoreFlags` can be used to pass flags to `dotnet restore`.
 * `dotnetBuildFlags` can be used to pass flags to `dotnet build`.
@@ -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";
@@ -142,9 +142,11 @@ in buildDotnetModule rec {
   src = ./.;
 
   projectFile = "src/project.sln";
-  nugetDeps = ./deps.nix; # see "Generating and updating NuGet dependencies" section for details
+  # File generated with `nix-build -A package.passthru.fetch-deps`.
+  # To run fetch-deps when this file does not yet exist, set nugetDeps to null
+  nugetDeps = ./deps.nix;
 
-  buildInputs = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
+  projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
 
   dotnet-sdk = dotnetCorePackages.sdk_6_0;
   dotnet-runtime = dotnetCorePackages.runtime_6_0;
@@ -195,7 +197,7 @@ This helper has the same arguments as `buildDotnetModule`, with a few difference
 
 * `pname` and `version` are required, and will be used to find the NuGet package of the tool
 * `nugetName` can be used to override the NuGet package name that will be downloaded, if it's different from `pname`
-* `nugetHash` is the hash of the fetched NuGet package. `nugetSha256` is also supported, but not recommended. Set this to `lib.fakeHash` for the first build, and it will error out, giving you the proper hash. Also remember to update it during version updates (it will not error out if you just change the version while having a fetched package in `/nix/store`)
+* `nugetSha256` is the hash of the fetched NuGet package. Set this to `lib.fakeHash256` for the first build, and it will error out, giving you the proper hash. Also remember to update it during version updates (it will not error out if you just change the version while having a fetched package in `/nix/store`)
 * `dotnet-runtime` is set to `dotnet-sdk` by default. When changing this, remember that .NET tools fetched from NuGet require an SDK.
 
 Here is an example of packaging `pbm`, an unfree binary without source available:
@@ -206,7 +208,7 @@ buildDotnetGlobalTool {
   pname = "pbm";
   version = "1.3.1";
 
-  nugetHash = "sha256-ZG2HFyKYhVNVYd2kRlkbAjZJq88OADe3yjxmLuxXDUo=";
+  nugetSha256 = "sha256-ZG2HFyKYhVNVYd2kRlkbAjZJq88OADe3yjxmLuxXDUo=";
 
   meta = {
     homepage = "https://cmd.petabridge.com/index.html";
@@ -218,12 +220,6 @@ buildDotnetGlobalTool {
 ```
 ## Generating and updating NuGet dependencies {#generating-and-updating-nuget-dependencies}
 
-When writing a new expression, you can use the generated `fetch-deps` script to initialise the lockfile.
-After setting `nugetDeps` to the desired location of the lockfile (e.g. `./deps.nix`),
-build the script with `nix-build -A package.fetch-deps` and then run the result.
-(When the root attr is your package, it's simply `nix-build -A fetch-deps`.)
-
-There is also a manual method:
 First, restore the packages to the `out` directory, ensure you have cloned
 the upstream repository and you are inside it.
 
@@ -240,17 +236,17 @@ 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"; hash = "sha256-lM6eYgOGjl1fx6WFD7rnRi/YAQieM0mx60h0p5dr+l8="; })
-  (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; hash = "sha256-QbUQXjCzr8j8u/5X0af9jE++EugdoxMhT08F49MZX74="; })
-  (fetchNuGet { pname = "Microsoft.NET.ILLink.Tasks"; version = "8.0.1"; hash = "sha256-SopZpGaZ48/8dpUwDFDM3ix+g1rP4Yqs1PGuzRp+K7c="; })
-  (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-x64"; version = "8.0.1"; hash = "sha256-jajBI5GqG2IIcsIMgxTHfXbMapoXrZGl/EEhShwYq7w="; })
-  (fetchNuGet { pname = "SharpGLTF.Core"; version = "1.0.0-alpha0031"; hash = "sha256-Bs4baD5wNIH6wAbGK4Xaem0i3luQkOQs37izBWdFx1I="; })
-  (fetchNuGet { pname = "SharpGLTF.Runtime"; version = "1.0.0-alpha0031"; hash = "sha256-TwJO6b8ubmwBQh6NyHha8+JT5zHDJ4dROBbsEbUaa1M="; })
-  (fetchNuGet { pname = "Sledge.Formats"; version = "1.2.2"; hash = "sha256-0Ddhuwpu3wwIzA4NuPaEVdMkx6tUukh8uKD6nKoxFPg="; })
-  (fetchNuGet { pname = "Sledge.Formats.Map"; version = "1.1.5"; hash = "sha256-hkYJ2iWIz7vhPWlDOw2fvTenlh+4/D/37Z71tCEwnK8="; })
-  (fetchNuGet { pname = "System.Numerics.Vectors"; version = "4.5.0"; hash = "sha256-qdSTIFgf2htPS+YhLGjAGiLN8igCYJnCCo6r78+Q+c8="; })
+  (fetchNuGet { pname = "FosterFramework"; version = "0.1.15-alpha"; sha256 = "0pzsdfbsfx28xfqljcwy100xhbs6wyx0z1d5qxgmv3l60di9xkll"; })
+  (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1gjz379y61ag9whi78qxx09bwkwcznkx2mzypgycibxk61g11da1"; })
+  (fetchNuGet { pname = "Microsoft.NET.ILLink.Tasks"; version = "8.0.1"; sha256 = "1drbgqdcvbpisjn8mqfgba1pwb6yri80qc4mfvyczqwrcsj5k2ja"; })
+  (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1g5b30f4l8a1zjjr3b8pk9mcqxkxqwa86362f84646xaj4iw3a4d"; })
+  (fetchNuGet { pname = "SharpGLTF.Core"; version = "1.0.0-alpha0031"; sha256 = "0ln78mkhbcxqvwnf944hbgg24vbsva2jpih6q3x82d3h7rl1pkh6"; })
+  (fetchNuGet { pname = "SharpGLTF.Runtime"; version = "1.0.0-alpha0031"; sha256 = "0lvb3asi3v0n718qf9y367km7qpkb9wci38y880nqvifpzllw0jg"; })
+  (fetchNuGet { pname = "Sledge.Formats"; version = "1.2.2"; sha256 = "1y0l66m9rym0p1y4ifjlmg3j9lsmhkvbh38frh40rpvf1axn2dyh"; })
+  (fetchNuGet { pname = "Sledge.Formats.Map"; version = "1.1.5"; sha256 = "1bww60hv9xcyxpvkzz5q3ybafdxxkw6knhv97phvpkw84pd0jil6"; })
+  (fetchNuGet { pname = "System.Numerics.Vectors"; version = "4.5.0"; sha256 = "1kzrj37yzawf1b19jq0253rcs8hsq1l2q8g69d7ipnhzb0h97m59"; })
 ]
 ```
 
@@ -259,5 +255,6 @@ Finally, you move the `deps.nix` file to the appropriate location to be used by
 If you ever need to update the dependencies of a package, you instead do
 
 * `nix-build -A package.fetch-deps` to generate the update script for `package`
-* Run `./result` to regenerate the lockfile to the path passed for `nugetDeps` (keep in mind if it can't be resolved to a local path, the script will write to `$1` or a temporary path instead)
-* Finally, ensure the correct file was written and the derivation can be built.
+* Run `./result deps.nix` to regenerate the lockfile to `deps.nix`, keep in mind if a location isn't provided, it will write to a temporary path instead
+* Finally, move the file where needed and look at its contents to confirm it has updated the dependencies.
+

doc/languages-frameworks/gnome.section.md

@@ -8,7 +8,7 @@ Programs in the GNOME universe are written in various languages but they all use
 
 [GSettings](https://developer.gnome.org/gio/stable/GSettings.html) API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for `glib-2.0/schemas/gschemas.compiled` files inside the directories of `XDG_DATA_DIRS`.
 
-On Linux, GSettings API is implemented using [dconf](https://gitlab.gnome.org/GNOME/dconf) backend. You will need to add `dconf` [GIO module](#ssec-gnome-gio-modules) to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
+On Linux, GSettings API is implemented using [dconf](https://wiki.gnome.org/Projects/dconf) backend. You will need to add `dconf` [GIO module](#ssec-gnome-gio-modules) to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
 
 Last you will need the dconf database D-Bus service itself. You can enable it using `programs.dconf.enable`.
 
@@ -47,7 +47,6 @@ 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
   ];
@@ -57,7 +56,6 @@ 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.
@@ -76,88 +74,80 @@ Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer neces
 
 ### GObject introspection typelibs {#ssec-gnome-typelibs}
 
-[GObject introspection](https://gitlab.gnome.org/GNOME/gobject-introspection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
+[GObject introspection](https://wiki.gnome.org/Projects/GObjectIntrospection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
 
 ### Various plug-ins {#ssec-gnome-plugins}
 
-If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://gitlab.gnome.org/GNOME/grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
+If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://wiki.gnome.org/Projects/Grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
 
-## Onto `wrapGApps*` hooks {#ssec-gnome-hooks}
+## Onto `wrapGAppsHook` {#ssec-gnome-hooks}
 
 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, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables.
+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.
 
-- [`wrapGAppsHook3`]{#ssec-gnome-hooks-wrapgappshook3} for GTK 3 apps. For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure.
-- [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4} for GTK 4 apps. Same as `wrapGAppsHook3` but replaces `gtk3` with `gtk4`.
-- [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook} for programs without a graphical interface. Same as the above but does not bring `gtk3` and `librsvg` into the closure.
+For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure. There is also [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4}, which replaces GTK 3 with GTK 4. And in case you are packaging a program without a graphical interface, you might want to use [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook}, which runs the same script as `wrapGAppsHook` but does not bring `gtk3` and `librsvg` into the closure.
 
-The hooks do the the following:
+- `wrapGAppsHook` itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
 
-- `wrapGApps*` hook itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
+- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
 
-- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGApps*` hook will prepend it to `XDG_DATA_DIRS`.
-
-- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGApps*` hook copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
+- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
 
 - []{#ssec-gnome-hooks-gtk-drop-icon-theme-cache} One of `gtk3`’s setup hooks will remove `icon-theme.cache` files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with `dontDropIconThemeCache = true;`.
 
-- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGApps*` hook, which then also adds it to the `GIO_EXTRA_MODULES` variable.
+- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGAppsHook`, which then also adds it to the `GIO_EXTRA_MODULES` variable.
 
 - []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS`.
 
-- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGApps*` hook. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGApps*` hook.
+- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
 
-- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGApps*` hook.
+- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGAppsHook`.
 
 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}
 
-Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome`. Read the package’s `NEWS` file to see what changed.
+Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package gnome.nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome`. Read the package’s `NEWS` file to see what changed.
 
 ## Frequently encountered issues {#ssec-gnome-common-issues}
 
 ### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
 
-There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGApps*`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
+There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGAppsHook`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
 
 ### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
 
 Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
 
-### When using `wrapGApps*` hook with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
+### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
 
-This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGApps*` hook automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
+This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
 
 In the case of a Python application it could look like:
 
@@ -167,9 +157,9 @@ python3.pkgs.buildPythonApplication {
   version = "3.32.2";
 
   nativeBuildInputs = [
-    wrapGAppsHook3
+    wrapGAppsHook
     gobject-introspection
-    # ...
+    ...
   ];
 
   dontWrapGApps = true;
@@ -189,9 +179,9 @@ mkDerivation {
   version = "3.47.0";
 
   nativeBuildInputs = [
-    wrapGAppsHook3
+    wrapGAppsHook
     qmake
-    # ...
+    ...
   ];
 
   dontWrapGApps = true;

doc/languages-frameworks/go.section.md

@@ -2,7 +2,7 @@
 
 ## Building Go modules with `buildGoModule` {#ssec-language-go}
 
-The function `buildGoModule` builds Go programs managed with Go modules. It builds [Go Modules](https://go.dev/wiki/Modules) through a two phase build:
+The function `buildGoModule` builds Go programs managed with Go modules. It builds [Go Modules](https://github.com/golang/go/wiki/Modules) through a two phase build:
 
 - An intermediate fetcher derivation called `goModules`. This derivation will be used to fetch all the dependencies of the Go module.
 - A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
@@ -38,86 +38,25 @@ The `buildGoModule` function accepts the following parameters in addition to the
 The following is an example expression using `buildGoModule`:
 
 ```nix
-{
-  pet = buildGoModule rec {
-    pname = "pet";
-    version = "0.3.4";
+pet = buildGoModule rec {
+  pname = "pet";
+  version = "0.3.4";
 
-    src = fetchFromGitHub {
-      owner = "knqyf263";
-      repo = "pet";
-      rev = "v${version}";
-      hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
-    };
-
-    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 ];
-    };
+  src = fetchFromGitHub {
+    owner = "knqyf263";
+    repo = "pet";
+    rev = "v${version}";
+    hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
   };
-}
-```
 
-### Obtaining and overriding `vendorHash` for `buildGoModule` {#buildGoModule-vendorHash}
+  vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
 
-We can use `nix-prefetch` to obtain the actual hash. The following command gets the value of `vendorHash` for package `pet`:
-
-```sh
-cd path/to/nixpkgs
-nix-prefetch -E "{ sha256 }: ((import ./. { }).my-package.overrideAttrs { vendorHash = sha256; }).goModules"
-```
-
-To obtain the hash without external tools, set `vendorHash = lib.fakeHash;` and run the build. ([more details here](#sec-source-hashes)).
-
-`vendorHash` can be overridden with `overrideAttrs`. Override the above example like this:
-
-```nix
-{
-  pet_0_4_0 = pet.overrideAttrs (
-    finalAttrs: previousAttrs: {
-      version = "0.4.0";
-      src = fetchFromGitHub {
-        inherit (previousAttrs.src) owner repo;
-        rev = "v${finalAttrs.version}";
-        hash = "sha256-gVTpzmXekQxGMucDKskGi+e+34nJwwsXwvQTjRO6Gdg=";
-      };
-      vendorHash = "sha256-dUvp7FEW09V0xMuhewPGw3TuAic/sD7xyXEYviZ2Ivs=";
-    }
-  );
-}
-```
-
-### Overriding `goModules` {#buildGoModule-goModules-override}
-
-Overriding `<pkg>.goModules` by calling `goModules.overrideAttrs` is unsupported. Still, it is possible to override the `vendorHash` (`goModules`'s `outputHash`) and the `pre`/`post` hooks for both the build and patch phases of the primary and `goModules` derivation. Alternatively, the primary derivation provides an overridable `passthru.overrideModAttrs` function to store the attribute overlay implicitly taken by `goModules.overrideAttrs`. Here's an example usage of `overrideModAttrs`:
-
-```nix
-{
-  pet-overridden = pet.overrideAttrs (
-    finalAttrs: previousAttrs: {
-      passthru = previousAttrs.passthru // {
-        # If the original package has an `overrideModAttrs` attribute set, you'd
-        # want to extend it, and not replace it. Hence we use
-        # `lib.composeExtensions`. If you are sure the `overrideModAttrs` of the
-        # original package trivially does nothing, you can safely replace it
-        # with your own by not using `lib.composeExtensions`.
-        overrideModAttrs = lib.composeExtensions previousAttrs.passthru.overrideModAttrs (
-          finalModAttrs: previousModAttrs: {
-            # goModules-specific overriding goes here
-            postBuild = ''
-              # Here you have access to the `vendor` directory.
-              substituteInPlace vendor/github.com/example/repo/file.go \
-                --replace-fail "panic(err)" ""
-            '';
-          }
-        );
-      };
-    }
-  );
+  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 ];
+  };
 }
 ```
 
@@ -125,25 +64,6 @@ Overriding `<pkg>.goModules` by calling `goModules.overrideAttrs` is unsupported
 
 The function `buildGoPackage` builds legacy Go programs, not supporting Go modules.
 
-::: {.warning}
-`buildGoPackage` is deprecated and will be removed for the 25.05 release.
-:::
-
-### Migrating from `buildGoPackage` to `buildGoModule` {#buildGoPackage-migration}
-
-Go modules, released 6y ago, are now widely adopted in the ecosystem.
-Most upstream projects are using Go modules, and the tooling previously used for dependency management in Go is mostly deprecated, archived or at least unmaintained at this point.
-
-In case a project doesn't have external dependencies or dependencies are vendored in a way understood by `go mod init`, migration can be done with a few changes in the package.
-
-- Switch the builder from `buildGoPackage` to `buildGoModule`
-- Remove `goPackagePath` and other attributes specific to `buildGoPackage`
-- Set `vendorHash = null;`
-- Run `go mod init <module name>` in `postPatch`
-
-In case the package has external dependencies that aren't vendored or the build setup is more complex the upstream source might need to be patched.
-Examples for the migration can be found in the [issue tracking migration withing nixpkgs](https://github.com/NixOS/nixpkgs/issues/318069).
-
 ### Example for `buildGoPackage` {#example-for-buildgopackage}
 
 In the following is an example expression using `buildGoPackage`, the following arguments are of special significance to the function:
@@ -152,22 +72,20 @@ In the following is an example expression using `buildGoPackage`, the following
 - `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
 
 ```nix
-{
-  deis = buildGoPackage rec {
-    pname = "deis";
-    version = "1.13.0";
+deis = buildGoPackage rec {
+  pname = "deis";
+  version = "1.13.0";
 
-    goPackagePath = "github.com/deis/deis";
+  goPackagePath = "github.com/deis/deis";
 
-    src = fetchFromGitHub {
-      owner = "deis";
-      repo = "deis";
-      rev = "v${version}";
-      hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
-    };
-
-    goDeps = ./deps.nix;
+  src = fetchFromGitHub {
+    owner = "deis";
+    repo = "deis";
+    rev = "v${version}";
+    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
   };
+
+  goDeps = ./deps.nix;
 }
 ```
 
@@ -220,7 +138,6 @@ Many attributes [controlling the build phase](#variables-controlling-the-build-p
 - [`patchFlags`](#var-stdenv-patchFlags)
 - [`postPatch`](#var-stdenv-postPatch)
 - [`preBuild`](#var-stdenv-preBuild)
-- `env`: useful for passing down variables such as `GOWORK`.
 
 To control test execution of the build derivation, the following attributes are of interest:
 
@@ -236,12 +153,10 @@ 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}
@@ -249,20 +164,16 @@ 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}
@@ -277,12 +188,10 @@ 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}
@@ -304,12 +213,10 @@ 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`.
@@ -338,18 +245,15 @@ 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
@@ -360,7 +264,6 @@ 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;`.

doc/languages-frameworks/gradle.section.md

@@ -1,189 +0,0 @@
-# Gradle {#gradle}
-
-Gradle is a popular build tool for Java/Kotlin. Gradle itself doesn't
-currently provide tools to make dependency resolution reproducible, so
-nixpkgs has a proxy designed for intercepting Gradle web requests to
-record dependencies so they can be restored in a reproducible fashion.
-
-## Building a Gradle package {#building-a-gradle-package}
-
-Here's how a typical derivation will look like:
-
-```nix
-stdenv.mkDerivation (finalAttrs: {
-  pname = "pdftk";
-  version = "3.3.3";
-
-  src = fetchFromGitLab {
-    owner = "pdftk-java";
-    repo = "pdftk";
-    rev = "v${finalAttrs.version}";
-    hash = "sha256-ciKotTHSEcITfQYKFZ6sY2LZnXGChBJy0+eno8B3YHY=";
-  };
-
-  nativeBuildInputs = [ gradle ];
-
-  # if the package has dependencies, mitmCache must be set
-  mitmCache = gradle.fetchDeps {
-    inherit (finalAttrs) pname;
-    data = ./deps.json;
-  };
-
-  # this is required for using mitm-cache on Darwin
-  __darwinAllowLocalNetworking = true;
-
-  gradleFlags = [ "-Dfile.encoding=utf-8" ];
-
-  # defaults to "assemble"
-  gradleBuildTask = "shadowJar";
-
-  # will run the gradleCheckTask (defaults to "test")
-  doCheck = true;
-
-  installPhase = ''
-    mkdir -p $out/{bin,share/pdftk}
-    cp build/libs/pdftk-all.jar $out/share/pdftk
-
-    makeWrapper ${jre}/bin/java $out/bin/pdftk \
-      --add-flags "-jar $out/share/pdftk/pdftk-all.jar"
-
-    cp ${finalAttrs.src}/pdftk.1 $out/share/man/man1
-  '';
-
-  meta.sourceProvenance = with lib.sourceTypes; [
-    fromSource
-    binaryBytecode # mitm cache
-  ];
-})
-```
-
-To update (or initialize) dependencies, run the update script via
-something like `$(nix-build -A <pname>.mitmCache.updateScript)`
-(`nix-build` builds the `updateScript`, `$(...)` runs the script at the
-path printed by `nix-build`).
-
-If your package can't be evaluated using a simple `pkgs.<pname>`
-expression (for example, if your package isn't located in nixpkgs, or if
-you want to override some of its attributes), you will usually have to
-pass `pkg` instead of `pname` to `gradle.fetchDeps`. There are two ways
-of doing it.
-
-The first is to add the derivation arguments required for getting the
-package. Using the pdftk example above:
-
-```nix
-{ lib
-, stdenv
-# ...
-, pdftk
-}:
-
-stdenv.mkDerivation (finalAttrs: {
-  # ...
-  mitmCache = gradle.fetchDeps {
-    pkg = pdftk;
-    data = ./deps.json;
-  };
-})
-```
-
-This allows you to `override` any arguments of the `pkg` used for
-the update script (for example, `pkg = pdftk.override { enableSomeFlag =
-true };`), so this is the preferred way.
-
-The second is to create a `let` binding for the package, like this:
-
-```nix
-let self = stdenv.mkDerivation {
-  # ...
-  mitmCache = gradle.fetchDeps {
-    pkg = self;
-    data = ./deps.json;
-  };
-}; in self
-```
-
-This is useful if you can't easily pass the derivation as its own
-argument, or if your `mkDerivation` call is responsible for building
-multiple packages.
-
-In the former case, the update script will stay the same even if the
-derivation is called with different arguments. In the latter case, the
-update script will change depending on the derivation arguments. It's up
-to you to decide which one would work best for your derivation.
-
-## Update Script {#gradle-update-script}
-
-The update script does the following:
-
-- Build the derivation's source via `pkgs.srcOnly`
-- Enter a `nix-shell` for the derivation in a `bwrap` sandbox (the
-  sandbox is only used on Linux)
-- Set the `IN_GRADLE_UPDATE_DEPS` environment variable to `1`
-- Run the derivation's `unpackPhase`, `patchPhase`, `configurePhase`
-- Run the derivation's `gradleUpdateScript` (the Gradle setup hook sets
-  a default value for it, which runs `preBuild`, `preGradleUpdate`
-  hooks, fetches the dependencies using `gradleUpdateTask`, and finally
-  runs the `postGradleUpdate` hook)
-- Finally, store all of the fetched files' hashes in the lockfile. They
-  may be `.jar`/`.pom` files from Maven repositories, or they may be
-  files otherwise used for building the package.
-
-`fetchDeps` takes the following arguments:
-
-- `attrPath` - the path to the package in nixpkgs (for example,
-  `"javaPackages.openjfx22"`). Used for update script metadata.
-- `pname` - an alias for `attrPath` for convenience. This is what you
-  will generally use instead of `pkg` or `attrPath`.
-- `pkg` - the package to be used for fetching the dependencies. Defaults
-  to `getAttrFromPath (splitString "." attrPath) pkgs`.
-- `bwrapFlags` - allows you to override bwrap flags (only relevant for
-  downstream, non-nixpkgs projects)
-- `data` - path to the dependencies lockfile (can be relative to the
-  package, can be absolute). In nixpkgs, it's discouraged to have the
-  lockfiles be named anything other `deps.json`, consider creating
-  subdirectories if your package requires multiple `deps.json` files.
-
-## Environment {#gradle-environment}
-
-The Gradle setup hook accepts the following environment variables:
-
-- `mitmCache` - the MITM proxy cache imported using `gradle.fetchDeps`
-- `gradleFlags` - command-line flags to be used for every Gradle
-  invocation (this simply registers a function that uses the necessary
-  flags).
-  - You can't use `gradleFlags` for flags that contain spaces, in that
-    case you must add `gradleFlagsArray+=("-flag with spaces")` to the
-    derivation's bash code instead.
-  - If you want to build the package using a specific Java version, you
-    can pass `"-Dorg.gradle.java.home=${jdk}"` as one of the flags.
-- `gradleBuildTask` - the Gradle task (or tasks) to be used for building
-  the package. Defaults to `assemble`.
-- `gradleCheckTask` - the Gradle task (or tasks) to be used for checking
-  the package if `doCheck` is set to `true`. Defaults to `test`.
-- `gradleUpdateTask` - the Gradle task (or tasks) to be used for
-  fetching all of the package's dependencies in
-  `mitmCache.updateScript`. Defaults to `nixDownloadDeps`.
-- `gradleUpdateScript` - the code to run for fetching all of the
-  package's dependencies in `mitmCache.updateScript`. Defaults to
-  running the `preBuild` and `preGradleUpdate` hooks, running the
-  `gradleUpdateTask`, and finally running the `postGradleUpdate` hook.
-- `gradleInitScript` - path to the `--init-script` to pass to Gradle. By
-  default, a simple init script that enables reproducible archive
-  creation is used.
-  - Note that reproducible archives might break some builds. One example
-    of an error caused by it is `Could not create task ':jar'. Replacing
-    an existing task that may have already been used by other plugins is
-    not supported`. If you get such an error, the easiest "fix" is
-    disabling reproducible archives altogether by setting
-    `gradleInitScript` to something like `writeText
-    "empty-init-script.gradle" ""`
-- `enableParallelBuilding` / `enableParallelChecking` /
-  `enableParallelUpdating` - pass `--parallel` to Gradle in the
-  build/check phase or in the update script. Defaults to true. If the
-  build fails for mysterious reasons, consider setting this to false.
-- `dontUseGradleConfigure` / `dontUseGradleBuild` / `dontUseGradleCheck`
-  \- force disable the Gradle setup hook for certain phases.
-  - Note that if you disable the configure hook, you may face issues
-    such as `Failed to load native library 'libnative-platform.so'`,
-    because the configure hook is responsible for initializing Gradle.

doc/languages-frameworks/hare.section.md

@@ -1,53 +0,0 @@
-# Hare {#sec-language-hare}
-
-## Building Hare programs with `hareHook` {#ssec-language-hare}
-
-The `hareHook` package sets up the environment for building Hare programs by
-doing the following:
-
-1. Setting the `HARECACHE`, `HAREPATH` and `NIX_HAREFLAGS` environment variables;
-1. Propagating `harec`, `qbe` and two wrapper scripts  for the hare binary.
-
-It is not a function as is the case for some other languages --- *e. g.*, Go or
-Rust ---, but a package to be added to `nativeBuildInputs`.
-
-## Attributes of `hareHook` {#hareHook-attributes}
-
-The following attributes are accepted by `hareHook`:
-
-1. `hareBuildType`: Either `release` (default) or `debug`. It controls if the
-   `-R` flag is added to `NIX_HAREFLAGS`.
-
-## Example for `hareHook` {#ex-hareHook}
-
-```nix
-{
-  hareHook,
-  lib,
-  stdenv,
-}: stdenv.mkDerivation {
-  pname = "<name>";
-  version = "<version>";
-  src = "<src>";
-
-  nativeBuildInputs = [ hareHook ];
-
-  meta = {
-    description = "<description>";
-    inherit (hareHook) badPlatforms platforms;
-  };
-}
-```
-
-## Cross Compilation {#hareHook-cross-compilation}
-
-`hareHook` should handle cross compilation out of the box. This is the main
-purpose of `NIX_HAREFLAGS`: In it, the `-a` flag is passed with the architecture
-of the `hostPlatform`.
-
-However, manual intervention may be needed when a binary compiled by the build
-process must be run for the build to complete --- *e. g.*, when using Hare's
-`hare` module for code generation.
-
-In those cases, `hareHook` provides the `hare-native` script, which is a wrapper
-around the hare binary for using the native (`buildPlatform`) toolchain.

doc/languages-frameworks/haskell.section.md

@@ -21,14 +21,25 @@ Many “normal” user facing packages written in Haskell, like `niv` or `cachix
 are also exposed at the top level, and there is nothing Haskell specific to
 installing and using them.
 
-All of these packages are originally defined in the `haskellPackages` package set.
-The same packages are re-exposed with a reduced dependency closure for convenience (see `justStaticExecutables` or `separateBinOutput` below).
+All of these packages are originally defined in the `haskellPackages` package
+set and are re-exposed with a reduced dependency closure for convenience.
+(see `justStaticExecutables` or `separateBinOutput` below)
 
-:::{.note}
-See [](#chap-language-support) for techniques to explore package sets.
-:::
+The `haskellPackages` set includes at least one version of every package from
+Hackage as well as some manually injected packages. This amounts to a lot of
+packages, so it is hidden from `nix-env -qa` by default for performance reasons.
+You can still list all packages in the set like this:
 
-The `haskellPackages` set includes at least one version of every package from [Hackage](https://hackage.haskell.org/) as well as some manually injected packages.
+```console
+$ nix-env -f '<nixpkgs>' -qaP -A haskellPackages
+haskellPackages.a50                                                         a50-0.5
+haskellPackages.AAI                                                         AAI-0.2.0.1
+haskellPackages.aasam                                                       aasam-0.2.0.0
+haskellPackages.abacate                                                     abacate-0.0.0.0
+haskellPackages.abc-puzzle                                                  abc-puzzle-0.2.1
+…
+```
+Also, the `haskellPackages` set is included on [search.nixos.org].
 
 The attribute names in `haskellPackages` always correspond with their name on
 Hackage. Since Hackage allows names that are not valid Nix without escaping,
@@ -38,7 +49,8 @@ For packages that are part of [Stackage] (a curated set of known to be
 compatible packages), we use the version prescribed by a Stackage snapshot
 (usually the current LTS one) as the default version. For all other packages we
 use the latest version from [Hackage](https://hackage.org) (the repository of
-basically all open source Haskell packages). See [below](#haskell-available-versions) for a few more details on this.
+basically all open source Haskell packages). See [below](#haskell-available-
+versions) for a few more details on this.
 
 Roughly half of the 16K packages contained in `haskellPackages` don’t actually
 build and are [marked as broken semi-automatically](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/broken.yaml).
@@ -51,15 +63,68 @@ How you can help with that is
 described in [Fixing a broken package](#haskell-fixing-a-broken-package).
 -->
 
-`haskellPackages` is built with our default compiler, but we also provide other releases of GHC and package sets built with them.
-Available compilers are collected under `haskell.compiler`.
+`haskellPackages` is built with our default compiler, but we also provide other
+releases of GHC and package sets built with them. You can list all available
+compilers like this:
 
-Each of those compiler versions has a corresponding attribute set `packages` built with
+```console
+$ nix-env -f '<nixpkgs>' -qaP -A haskell.compiler
+haskell.compiler.ghc810                  ghc-8.10.7
+haskell.compiler.ghc90                   ghc-9.0.2
+haskell.compiler.ghc925                  ghc-9.2.5
+haskell.compiler.ghc926                  ghc-9.2.6
+haskell.compiler.ghc927                  ghc-9.2.7
+haskell.compiler.ghc92                   ghc-9.2.8
+haskell.compiler.ghc945                  ghc-9.4.5
+haskell.compiler.ghc946                  ghc-9.4.6
+haskell.compiler.ghc947                  ghc-9.4.7
+haskell.compiler.ghc94                   ghc-9.4.8
+haskell.compiler.ghc963                  ghc-9.6.3
+haskell.compiler.ghc96                   ghc-9.6.4
+haskell.compiler.ghc98                   ghc-9.8.1
+haskell.compiler.ghcHEAD                 ghc-9.9.20231121
+haskell.compiler.ghc8107Binary           ghc-binary-8.10.7
+haskell.compiler.ghc865Binary            ghc-binary-8.6.5
+haskell.compiler.ghc924Binary            ghc-binary-9.2.4
+haskell.compiler.integer-simple.ghc8107  ghc-integer-simple-8.10.7
+haskell.compiler.integer-simple.ghc810   ghc-integer-simple-8.10.7
+haskell.compiler.native-bignum.ghc90     ghc-native-bignum-9.0.2
+haskell.compiler.native-bignum.ghc902    ghc-native-bignum-9.0.2
+haskell.compiler.native-bignum.ghc925    ghc-native-bignum-9.2.5
+haskell.compiler.native-bignum.ghc926    ghc-native-bignum-9.2.6
+haskell.compiler.native-bignum.ghc927    ghc-native-bignum-9.2.7
+haskell.compiler.native-bignum.ghc92     ghc-native-bignum-9.2.8
+haskell.compiler.native-bignum.ghc928    ghc-native-bignum-9.2.8
+haskell.compiler.native-bignum.ghc945    ghc-native-bignum-9.4.5
+haskell.compiler.native-bignum.ghc946    ghc-native-bignum-9.4.6
+haskell.compiler.native-bignum.ghc947    ghc-native-bignum-9.4.7
+haskell.compiler.native-bignum.ghc94     ghc-native-bignum-9.4.8
+haskell.compiler.native-bignum.ghc948    ghc-native-bignum-9.4.8
+haskell.compiler.native-bignum.ghc963    ghc-native-bignum-9.6.3
+haskell.compiler.native-bignum.ghc96     ghc-native-bignum-9.6.4
+haskell.compiler.native-bignum.ghc964    ghc-native-bignum-9.6.4
+haskell.compiler.native-bignum.ghc98     ghc-native-bignum-9.8.1
+haskell.compiler.native-bignum.ghc981    ghc-native-bignum-9.8.1
+haskell.compiler.native-bignum.ghcHEAD   ghc-native-bignum-9.9.20231121
+haskell.compiler.ghcjs                   ghcjs-8.10.7
+```
+
+Each of those compiler versions has a corresponding attribute set built using
 it. However, the non-standard package sets are not tested regularly and, as a
 result, contain fewer working packages. The corresponding package set for GHC
 9.4.5 is `haskell.packages.ghc945`. In fact `haskellPackages` is just an alias
 for `haskell.packages.ghc964`:
 
+```console
+$ nix-env -f '<nixpkgs>' -qaP -A haskell.packages.ghc927
+haskell.packages.ghc927.a50                                                         a50-0.5
+haskell.packages.ghc927.AAI                                                         AAI-0.2.0.1
+haskell.packages.ghc927.aasam                                                       aasam-0.2.0.0
+haskell.packages.ghc927.abacate                                                     abacate-0.0.0.0
+haskell.packages.ghc927.abc-puzzle                                                  abc-puzzle-0.2.1
+…
+```
+
 Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
 
 ### Available package versions {#haskell-available-versions}
@@ -165,7 +230,7 @@ completely incompatible with packages from `haskellPackages`.
 
 Every haskell package set has its own haskell-aware `mkDerivation` which is used
 to build its packages. Generally you won't have to interact with this builder
-since [cabal2nix](#haskell-cabal2nix) can generate packages
+since [cabal2nix][cabal2nix] can generate packages
 using it for an arbitrary cabal package definition. Still it is useful to know
 the parameters it takes when you need to
 [override](#haskell-overriding-haskell-packages) a generated Nix expression.
@@ -858,61 +923,14 @@ for this to work.
 
 `justStaticExecutables drv`
 : Only build and install the executables produced by `drv`, removing everything
-  that may refer to other Haskell packages' store paths (like libraries and
-  documentation). This dramatically reduces the closure size of the resulting
-  derivation. Note that the executables are only statically linked against their
-  Haskell dependencies, but will still link dynamically against libc, GMP and
-  other system library dependencies.
-
-  If a library or its dependencies use their Cabal-generated
-  `Paths_*` module, this may not work as well if GHC's dead code elimination is
-  unable to remove the references to the dependency's store path that module
-  contains.
-  As a consequence, an unused reference may be created from the static binary to such a _library_ store path.
-  (See [nixpkgs#164630][164630] for more information.)
-
-  Importing the `Paths_*` module may cause builds to fail with this message:
-
-  ```
-  error: output '/nix/store/64k8iw0ryz76qpijsnl9v87fb26v28z8-my-haskell-package-1.0.0.0' is not allowed to refer to the following paths:
-           /nix/store/5q5s4a07gaz50h04zpfbda8xjs8wrnhg-ghc-9.6.3
-  ```
-
-  If that happens, first disable the check for GHC references and rebuild the
-  derivation:
-
-  ```nix
-  pkgs.haskell.lib.overrideCabal
-    (pkgs.haskell.lib.justStaticExecutables my-haskell-package)
-    (drv: {
-      disallowGhcReference = false;
-    })
-  ```
-
-  Then use `strings` to determine which libraries are responsible:
-
-  ```
-  $ nix-build ...
-  $ strings result/bin/my-haskell-binary | grep /nix/store/
-  ...
-  /nix/store/n7ciwdlg8yyxdhbrgd6yc2d8ypnwpmgq-hs-opentelemetry-sdk-0.0.3.6/bin
-  ...
-  ```
-
-  Finally, use `remove-references-to` to delete those store paths from the produced output:
-
-  ```nix
-  pkgs.haskell.lib.overrideCabal
-    (pkgs.haskell.lib.justStaticExecutables my-haskell-package)
-    (drv: {
-      postInstall = ''
-        ${drv.postInstall or ""}
-        remove-references-to -t ${pkgs.haskellPackages.hs-opentelemetry-sdk}
-      '';
-    })
-  ```
-
-[164630]: https://github.com/NixOS/nixpkgs/issues/164630
+that may refer to other Haskell packages' store paths (like libraries and
+documentation). This dramatically reduces the closure size of the resulting
+derivation. Note that the executables are only statically linked against their
+Haskell dependencies, but will still link dynamically against libc, GMP and
+other system library dependencies. If dependencies use their Cabal-generated
+`Paths_*` module, this may not work as well if GHC's dead code elimination
+is unable to remove the references to the dependency's store path that module
+contains.
 
 `enableSeparateBinOutput drv`
 : Install executables produced by `drv` to a separate `bin` output. This
@@ -1105,75 +1123,18 @@ for [this to work][optparse-applicative-completions].
 Note that this feature is automatically disabled when cross-compiling, since it
 requires executing the binaries in question.
 
-## Import-from-Derivation helpers {#haskell-import-from-derivation}
-
-### cabal2nix {#haskell-cabal2nix}
-
-[`cabal2nix`][cabal2nix] can generate Nix package definitions for arbitrary
-Haskell packages using [import from derivation][import-from-derivation].
-`cabal2nix` will generate Nix expressions that look like this:
-
-```nix
-# cabal get mtl-2.2.1 && cd mtl-2.2.1 && cabal2nix .
-{ mkDerivation, base, lib, transformers }:
-mkDerivation {
-  pname = "mtl";
-  version = "2.2.1";
-  src = ./.;
-  libraryHaskellDepends = [ base transformers ];
-  homepage = "http://github.com/ekmett/mtl";
-  description = "Monad classes, using functional dependencies";
-  license = lib.licenses.bsd3;
-}
-```
-
-This expression should be called with `haskellPackages.callPackage`, which will
-supply [`haskellPackages.mkDerivation`](#haskell-mkderivation) and the Haskell
-dependencies as arguments.
-
-`callCabal2nix name src args`
-: Create a package named `name` from the source derivation `src` using
-  `cabal2nix`.
-
-  `args` are extra arguments provided to `haskellPackages.callPackage`.
-
-`callCabal2nixWithOptions name src opts args`
-: Create a package named `name` from the source derivation `src` using
-  `cabal2nix`.
-
-  `opts` are extra options for calling `cabal2nix`. If `opts` is a string, it
-  will be used as extra command line arguments for `cabal2nix`, e.g. `--subpath
-  path/to/dir/containing/cabal-file`. Otherwise, `opts` should be an AttrSet
-  which can contain the following attributes:
-
-  `extraCabal2nixOptions`
-  : Extra command line arguments for `cabal2nix`.
-
-  `srcModifier`
-  : A function which is used to modify the given `src` instead of the default
-    filter.
-
-    The default source filter will remove all files from `src` except for
-    `.cabal` files and `package.yaml` files.
-
-<!--
-
-`callHackage`
-: TODO
-
-`callHackageDirect`
-: TODO
-
-`developPackage`
-: TODO
-
--->
-
 <!--
 
 TODO(@NixOS/haskell): finish these planned sections
 ### Overriding the entire package set
 
+
+## Import-from-Derivation helpers
+
+* `callCabal2nix`
+* `callHackage`, `callHackageDirect`
+* `developPackage`
+
 ## Contributing {#haskell-contributing}
 
 ### Fixing a broken package {#haskell-fixing-a-broken-package}
@@ -1348,4 +1309,3 @@ relevant.
 [profiling]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html
 [search.nixos.org]: https://search.nixos.org
 [turtle]: https://hackage.haskell.org/package/turtle
-[import-from-derivation]: https://nixos.org/manual/nix/stable/language/import-from-derivation

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" ]
 
-  # ...
+  ...
 }
 ```
 

doc/languages-frameworks/idris2.section.md

@@ -19,7 +19,7 @@ let lspLibPkg = idris2Packages.buildIdris {
   };
   idrisLibraries = [ ];
 };
-in lspLibPkg.library { withSource = true; }
+in lspLibPkg.library
 ```
 
 The above results in a derivation with the installed library results (with sourcecode).
@@ -30,7 +30,6 @@ A slightly more involved example of a fully packaged executable would be the [`i
 
 # Assuming the previous example lives in `lsp-lib.nix`:
 let lspLib = callPackage ./lsp-lib.nix { };
-    inherit (idris2Packages) idris2Api;
     lspPkg = idris2Packages.buildIdris {
       ipkgName = "idris2-lsp";
       src = fetchFromGitHub {
@@ -39,9 +38,10 @@ let lspLib = callPackage ./lsp-lib.nix { };
          rev = "main";
          hash = "sha256-vQTzEltkx7uelDtXOHc6QRWZ4cSlhhm5ziOqWA+aujk=";
       };
-      idrisLibraries = [idris2Api lspLib];
+      idrisLibraries = [(idris2Packages.idris2Api { }) (lspLib { })];
     };
 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.
+The above uses the default value of `withSource = false` for both of the two required Idris libraries that the `idris2-lsp` executable depends on. `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/index.md

@@ -2,54 +2,6 @@
 
 The [standard build environment](#chap-stdenv) makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of `stdenv`. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
 
-Each supported language or software ecosystem has its own package set named `<language or ecosystem>Packages`, which can be explored in various ways:
-
-- Search on [search.nixos.org](https://search.nixos.org/packages)
-
-  For example, search for [`haskellPackages`](https://search.nixos.org/packages?query=haskellPackages) or [`rubyPackages`](https://search.nixos.org/packages?query=rubyPackages).
-
-- Navigate attribute sets with [`nix repl`](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-repl).
-
-  This technique is generally useful to inspect Nix language data structures.
-
-  :::{.example #example-navigte-nix-repl}
-
-  # Navigate Java compiler variants in `javaPackages` with `nix repl`
-
-  ```shell-session
-  $ nix repl '<nixpkgs>' -I nixpkgs=channel:nixpkgs-unstable
-  nix-repl> javaPackages.<tab>
-  javaPackages.compiler               javaPackages.openjfx15              javaPackages.openjfx21              javaPackages.recurseForDerivations
-  javaPackages.jogl_2_4_0             javaPackages.openjfx17              javaPackages.openjfx22
-  javaPackages.mavenfod               javaPackages.openjfx19              javaPackages.override
-  javaPackages.openjfx11              javaPackages.openjfx20              javaPackages.overrideDerivation
-  ```
-  :::
-
-- List all derivations on the command line with [`nix-env --query`](https://nixos.org/manual/nix/stable/command-ref/nix-env/query).
-
-  `nix-env` is the only convenient way to do that, as it will skip attributes that fail [assertions](https://nixos.org/manual/nix/stable/language/constructs#assertions), such as when a package is [marked as broken](#var-meta-broken), rather than failing the entire evaluation.
-
-  :::{.example #example-list-haskellPackages}
-
-  # List all Python packages in Nixpkgs
-
-  The following command lists all [derivations names](https://nixos.org/manual/nix/stable/language/derivations#attr-name) with their attribute path from the latest Nixpkgs rolling release (`nixpkgs-unstable`).
-
-  ```shell-session
-  $ nix-env -qaP -f '<nixpkgs>' -A pythonPackages -I nixpkgs=channel:nixpkgs-unstable
-  ```
-
-  ```console
-  pythonPackages.avahi                                                  avahi-0.8
-  pythonPackages.boost                                                  boost-1.81.0
-  pythonPackages.caffe                                                  caffe-1.0
-  pythonPackages.caffeWithCuda                                          caffe-1.0
-  pythonPackages.cbeams                                                 cbeams-1.0.3
-  …
-  ```
-  :::
-
 ```{=include=} sections
 agda.section.md
 android.section.md
@@ -62,13 +14,10 @@ cuda.section.md
 cuelang.section.md
 dart.section.md
 dhall.section.md
-dlang.section.md
 dotnet.section.md
 emscripten.section.md
 gnome.section.md
 go.section.md
-gradle.section.md
-hare.section.md
 haskell.section.md
 hy.section.md
 idris.section.md
@@ -91,7 +40,6 @@ qt.section.md
 r.section.md
 ruby.section.md
 rust.section.md
-scheme.section.md
 swift.section.md
 texlive.section.md
 titanium.section.md

doc/languages-frameworks/java.section.md

@@ -7,7 +7,7 @@ stdenv.mkDerivation {
   pname = "...";
   version = "...";
 
-  src = fetchurl { /* ... */ };
+  src = fetchurl { ... };
 
   nativeBuildInputs = [
     ant
@@ -48,10 +48,8 @@ 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
@@ -64,15 +62,13 @@ 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,
@@ -96,18 +92,16 @@ 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
@@ -122,9 +116,7 @@ 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

doc/languages-frameworks/javascript.section.md

@@ -46,7 +46,7 @@ If a particular lock file is present, it is a strong indication of which package
 It's better to try to use a Nix tool that understand the lock file.
 Using a different tool might give you hard to understand error because different packages have been installed.
 An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).
-Upstream use npm, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
+Upstream use NPM, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
 
 Using a different tool forces to commit a lock file to the repository.
 Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
@@ -54,8 +54,8 @@ Those files are fairly large, so when packaging for nixpkgs, this approach does
 Exceptions to this rule are:
 
 - When you encounter one of the bugs from a Nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general `yarn2nix` has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed.
-- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
-- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
+- Some lock files contain particular version of a package that has been pulled off NPM for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
+- The only tool that supports workspaces (a feature of NPM that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
 
 ### Try to use upstream package.json {#javascript-upstream-package-json}
 
@@ -76,13 +76,11 @@ 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.
@@ -97,12 +95,12 @@ Then when building the frontend you can just symlink the node_modules directory.
 
 ## Javascript packages inside nixpkgs {#javascript-packages-nixpkgs}
 
-The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [npm packages](https://npmjs.com/) that can be installed with the Nix package manager.
+The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [NPM packages](https://npmjs.com/) that can be installed with the Nix package manager.
 
 As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities.
-Libraries should only be added to the package set if there is a non-npm package that requires it.
+Libraries should only be added to the package set if there is a non-NPM package that requires it.
 
-When it is desired to use npm libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
+When it is desired to use NPM libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
 
 The package set provides support for the official stable Node.js versions.
 The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
@@ -117,17 +115,15 @@ 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}
 
-To add a package from npm to nixpkgs:
+To add a package from NPM to nixpkgs:
 
 1. Modify [pkgs/development/node-packages/node-packages.json](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/node-packages.json) to add, update or remove package entries to have it included in `nodePackages` and `nodePackages_latest`.
 2. Run the script:
@@ -154,7 +150,7 @@ To add a package from npm to nixpkgs:
 
 For more information about the generation process, consult the [README.md](https://github.com/svanderburg/node2nix) file of the `node2nix` tool.
 
-To update npm packages in nixpkgs, run the same `generate.sh` script:
+To update NPM packages in nixpkgs, run the same `generate.sh` script:
 
 ```sh
 ./pkgs/development/node-packages/generate.sh
@@ -206,7 +202,7 @@ buildNpmPackage rec {
   NODE_OPTIONS = "--openssl-legacy-provider";
 
   meta = {
-    description = "Modern web UI for various torrent clients with a Node.js backend and React frontend";
+    description = "A modern web UI for various torrent clients with a Node.js backend and React frontend";
     homepage = "https://flood.js.org";
     license = lib.licenses.gpl3Only;
     maintainers = with lib.maintainers; [ winter ];
@@ -233,7 +229,7 @@ If these are not defined, `npm pack` may miss some files, and no binaries will b
 * `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`.
 * `makeWrapperArgs`: Flags to pass to `makeWrapper`, added to executable calling the generated `.js` with `node` as an interpreter. These scripts are defined in `package.json`.
 * `nodejs`: The `nodejs` package to build against, using the corresponding `npm` shipped with that version of `node`. Defaults to `pkgs.nodejs`.
-* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace dependencies.
+* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace depedencies.
 
 #### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
 
@@ -258,39 +254,26 @@ It returns a derivation with all `package-lock.json` dependencies downloaded int
 
 #### importNpmLock {#javascript-buildNpmPackage-importNpmLock}
 
-This function replaces the npm dependency references in `package.json` and `package-lock.json` with paths to the Nix store.
-How each dependency is fetched can be customized with the `fetcherOpts` argument.
+`importNpmLock` is a Nix function that requires the following optional arguments:
 
-This is a simpler and more convenient alternative to [`fetchNpmDeps`](#javascript-buildNpmPackage-fetchNpmDeps) for managing npm dependencies in Nixpkgs.
-There is no need to specify a `hash`, since it relies entirely on the integrity hashes already present in the `package-lock.json` file.
-
-##### Inputs {#javascript-buildNpmPackage-inputs}
-
-- `npmRoot`: Path to package directory containing the source tree.
-  If this is omitted, the `package` and `packageLock` arguments must be specified instead.
+- `npmRoot`: Path to package directory containing the source tree
 - `package`: Parsed contents of `package.json`
 - `packageLock`: Parsed contents of `package-lock.json`
 - `pname`: Package name
 - `version`: Package version
-- `fetcherOpts`: An attribute set of arguments forwarded to the underlying fetcher.
 
 It returns a derivation with a patched `package.json` & `package-lock.json` with all dependencies resolved to Nix store paths.
 
-:::{.note}
-`npmHooks.npmConfigHook` cannot be used with `importNpmLock`.
-Use `importNpmLock.npmConfigHook` instead.
-:::
+This function is analogous to using `fetchNpmDeps`, but instead of specifying `hash` it uses metadata from `package.json` & `package-lock.json`.
 
-:::{.example}
+Note that `npmHooks.npmConfigHook` cannot be used with `importNpmLock`. You will instead need to use `importNpmLock.npmConfigHook`:
 
-##### `pkgs.importNpmLock` usage example {#javascript-buildNpmPackage-example}
 ```nix
 { buildNpmPackage, importNpmLock }:
 
 buildNpmPackage {
   pname = "hello";
   version = "0.1.0";
-  src = ./.;
 
   npmDeps = importNpmLock {
     npmRoot = ./.;
@@ -299,75 +282,6 @@ buildNpmPackage {
   npmConfigHook = importNpmLock.npmConfigHook;
 }
 ```
-:::
-
-:::{.example}
-##### `pkgs.importNpmLock` usage example with `fetcherOpts` {#javascript-buildNpmPackage-example-fetcherOpts}
-
-`importNpmLock` uses the following fetchers:
-
-- `pkgs.fetchurl` for `http(s)` dependencies
-- `builtins.fetchGit` for `git` dependencies
-
-It is possible to provide additional arguments to individual fetchers as needed:
-
-```nix
-{ buildNpmPackage, importNpmLock }:
-
-buildNpmPackage {
-  pname = "hello";
-  version = "0.1.0";
-  src = ./.;
-
-  npmDeps = importNpmLock {
-    npmRoot = ./.;
-    fetcherOpts = {
-      # Pass 'curlOptsList' to 'pkgs.fetchurl' while fetching 'axios'
-      { "node_modules/axios" = { curlOptsList = [ "--verbose" ]; }; }
-    };
-  };
-
-  npmConfigHook = importNpmLock.npmConfigHook;
-}
-```
-:::
-
-#### importNpmLock.buildNodeModules {#javascript-buildNpmPackage-importNpmLock.buildNodeModules}
-
-`importNpmLock.buildNodeModules` returns a derivation with a pre-built `node_modules` directory, as imported by `importNpmLock`.
-
-This is to be used together with `importNpmLock.hooks.linkNodeModulesHook` to facilitate `nix-shell`/`nix develop` based development workflows.
-
-It accepts an argument with the following attributes:
-
-`npmRoot` (Path; optional)
-: Path to package directory containing the source tree. If not specified, the `package` and `packageLock` arguments must both be specified.
-
-`package` (Attrset; optional)
-: Parsed contents of `package.json`, as returned by `lib.importJSON ./my-package.json`. If not specified, the `package.json` in `npmRoot` is used.
-
-`packageLock` (Attrset; optional)
-: Parsed contents of `package-lock.json`, as returned `lib.importJSON ./my-package-lock.json`. If not specified, the `package-lock.json` in `npmRoot` is used.
-
-`derivationArgs` (`mkDerivation` attrset; optional)
-: Arguments passed to `stdenv.mkDerivation`
-
-For example:
-
-```nix
-pkgs.mkShell {
-  packages = [
-    importNpmLock.hooks.linkNodeModulesHook
-    nodejs
-  ];
-
-  npmDeps = importNpmLock.buildNodeModules {
-    npmRoot = ./.;
-    inherit nodejs;
-  };
-}
-```
-will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
 
 ### corepack {#javascript-corepack}
 
@@ -389,196 +303,11 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
 #### Pitfalls {#javascript-node2nix-pitfalls}
 
 - If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
-- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from npm distributed with `nodejs_16`.
-- `node2nix` does not like missing packages from npm. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of npm.
-
-### pnpm {#javascript-pnpm}
-
-Pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8` and `pnpm_9`, which support different sets of lock file versions.
-
-When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The functions `pnpm_8.fetchDeps` and `pnpm_9.fetchDeps` can create this pnpm store derivation. In conjunction, the setup hooks `pnpm_8.configHook` and `pnpm_9.configHook` will prepare the build environment to install the prefetched dependencies store. Here is an example for a package that contains a `package.json` and a `pnpm-lock.yaml` files using the above `pnpm_` attributes:
-
-```nix
-{
-  stdenv,
-  nodejs,
-  # This is pinned as { pnpm = pnpm_9; }
-  pnpm
-}:
-
-stdenv.mkDerivation (finalAttrs: {
-  pname = "foo";
-  version = "0-unstable-1980-01-01";
-
-  src = ...;
-
-  nativeBuildInputs = [
-    nodejs
-    pnpm.configHook
-  ];
-
-  pnpmDeps = pnpm.fetchDeps {
-    inherit (finalAttrs) pname version src;
-    hash = "...";
-  };
-})
-```
-
-NOTE: It is highly recommended to use a pinned version of pnpm (i.e. `pnpm_8` or `pnpm_9`), to increase future reproducibility. It might also be required to use an older version, if the package needs support for a certain lock file version.
-
-In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e. `inherit (finalAttrs) patches`.
-
-`pnpm.configHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array.
-
-#### Dealing with `sourceRoot` {#javascript-pnpm-sourceRoot}
-
-If the pnpm project is in a subdirectory, you can just define `sourceRoot` or `setSourceRoot` for `fetchDeps`.
-If `sourceRoot` is different between the parent derivation and `fetchDeps`, you will have to set `pnpmRoot` to effectively be the same location as it is in `fetchDeps`.
-
-Assuming the following directory structure, we can define `sourceRoot` and `pnpmRoot` as follows:
-
-```
-.
-├── frontend
-│   ├── ...
-│   ├── package.json
-│   └── pnpm-lock.yaml
-└── ...
-```
-
-```nix
-  ...
-  pnpmDeps = pnpm.fetchDeps {
-    ...
-    sourceRoot = "${finalAttrs.src.name}/frontend";
-  };
-
-  # by default the working directory is the extracted source
-  pnpmRoot = "frontend";
-```
-
-#### PNPM Workspaces {#javascript-pnpm-workspaces}
-
-If you need to use a PNPM workspace for your project, then set `pnpmWorkspace = "<workspace project name>"` in your `pnpm.fetchDeps` call,
-which will make PNPM only install dependencies for that workspace package.
-
-For example:
-
-```nix
-...
-pnpmWorkspace = "@astrojs/language-server";
-pnpmDeps = pnpm.fetchDeps {
-  inherit (finalAttrs) pnpmWorkspace;
-  ...
-}
-```
-
-The above would make `pnpm.fetchDeps` call only install dependencies for the `@astrojs/language-server` workspace package.
-Note that you do not need to set `sourceRoot` to make this work.
-
-Usually in such cases, you'd want to use `pnpm --filter=$pnpmWorkspace build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
-
-```nix
-buildPhase = ''
-  runHook preBuild
-
-  pnpm --filter=@astrojs/language-server build
-
-  runHook postBuild
-'';
-```
-
-#### Additional PNPM Commands and settings {#javascript-pnpm-extraCommands}
-
-If you require setting an additional PNPM configuration setting (such as `dedupe-peer-dependents` or similar),
-set `prePnpmInstall` to the right commands to run. For example:
-
-```nix
-prePnpmInstall = ''
-  pnpm config set dedupe-peer-dependants false
-'';
-pnpmDeps = pnpm.fetchDeps {
-  inherit (finalAttrs) prePnpmInstall;
-  ...
-};
-```
-
-In this example, `prePnpmInstall` will be run by both `pnpm.configHook` and by the `pnpm.fetchDeps` builder.
-
-
-### Yarn {#javascript-yarn}
-
-Yarn based projects use a `yarn.lock` file instead of a `package-lock.json` to pin dependencies. Nixpkgs provides the Nix function `fetchYarnDeps` which fetches an offline cache suitable for running `yarn install` before building the project. In addition, Nixpkgs provides the hooks:
-
-- `yarnConfigHook`: Fetches the dependencies from the offline cache and installs them into `node_modules`.
-- `yarnBuildHook`: Runs `yarn build` or a specified `yarn` command that builds the project.
-- `yarnInstallHook`: Runs `yarn install --production` to prune dependencies and installs the project into `$out`.
-
-An example usage of the above attributes is:
-
-```nix
-{
-  lib,
-  stdenv,
-  fetchFromGitHub,
-  fetchYarnDeps,
-  yarnConfigHook,
-  yarnBuildHook,
-  yarnInstallHook,
-  nodejs,
-}:
-
-stdenv.mkDerivation (finalAttrs: {
-  pname = "...";
-  version = "...";
-
-  src = fetchFromGitHub {
-    owner = "...";
-    repo = "...";
-    rev = "v${finalAttrs.version}";
-    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
-  };
-
-  yarnOfflineCache = fetchYarnDeps {
-    yarnLock = finalAttrs.src + "/yarn.lock";
-    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
-  };
-
-  nativeBuildInputs = [
-    yarnConfigHook
-    yarnBuildHook
-    yarnInstallHook
-    # Needed for executing package.json scripts
-    nodejs
-  ];
-
-  meta = {
-    # ...
-  };
-})
-```
-
-#### `yarnConfigHook` arguments {#javascript-yarnconfighook}
-
-By default, `yarnConfigHook` relies upon the attribute `${yarnOfflineCache}` (or `${offlineCache}` if the former is not set) to find the location of the offline cache produced by `fetchYarnDeps`. To disable this phase, you can set `dontYarnInstallDeps = true` or override the `configurePhase`.
-
-#### `yarnBuildHook` arguments {#javascript-yarnbuildhook}
-
-This script by default runs `yarn --offline build`, and it relies upon the project's dependencies installed at `node_modules`. Below is a list of additional `mkDerivation` arguments read by this hook:
-
-- `yarnBuildScript`: Sets a different `yarn --offline` subcommand (defaults to `build`).
-- `yarnBuildFlags`: Single string list of additional flags to pass the above command, or a Nix list of such additional flags.
-
-#### `yarnInstallHook` arguments {#javascript-yarninstallhook}
-
-To install the package `yarnInstallHook` uses both `npm` and `yarn` to cleanup project files and dependencies. To disable this phase, you can set `dontYarnInstall = true` or override the `installPhase`. Below is a list of additional `mkDerivation` arguments read by this hook:
-
-- `yarnKeepDevDeps`: Disables the removal of devDependencies from `node_modules` before installation.
+- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs_16`.
+- `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
 
 ### yarn2nix {#javascript-yarn2nix}
 
-WARNING: The `yarn2nix` functions have been deprecated in favor of the new `yarnConfigHook`, `yarnBuildHook` and `yarnInstallHook`. Documentation for them still appears here for the sake of the packages that still use them. See also a tracking issue [#324246](https://github.com/NixOS/nixpkgs/issues/324246).
-
 #### Preparation {#javascript-yarn2nix-preparation}
 
 You will need at least a `yarn.lock` file. If upstream does not have one you need to generate it and reference it in your package definition.
@@ -586,12 +315,10 @@ 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}
@@ -601,41 +328,33 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
 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}
@@ -675,14 +394,12 @@ 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>

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,12 +55,10 @@ in mkShell {
 
 Such a Lisp can be now used e.g. to compile your sources:
 
-```nix
-{
-  buildPhase = ''
-    ${sbcl'}/bin/sbcl --load my-build-file.lisp
-  '';
-}
+```
+buildPhase = ''
+  ${sbcl'}/bin/sbcl --load my-build-file.lisp
+''
 ```
 
 ## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
@@ -175,7 +173,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";
@@ -201,7 +199,7 @@ new package with different parameters.
 
 Example of overriding `alexandria`:
 
-```nix
+```
 sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
   version = "1.4";
   src = fetchFromGitLab {
@@ -227,7 +225,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 ];
@@ -292,7 +290,7 @@ derivation.
 
 This example wraps CLISP:
 
-```nix
+```
 wrapLisp {
   pkg = clisp;
   faslExt = "fas";

doc/languages-frameworks/lua.section.md

@@ -17,9 +17,6 @@ The main package set contains aliases to these package sets, e.g.
 `luaPackages` refers to `lua5_1.pkgs` and `lua52Packages` to
 `lua5_2.pkgs`.
 
-Note that nixpkgs patches the non-luajit interpreters to avoid referring to
-`/usr` and have `;;` (a [placeholder](https://www.lua.org/manual/5.1/manual.html#pdf-package.path) replaced with the default LUA_PATH) work correctly.
-
 ### Installing Lua and packages {#installing-lua-and-packages}
 
 #### Lua environment defined in separate `.nix` file {#lua-environment-defined-in-separate-.nix-file}
@@ -90,7 +87,6 @@ final: prev:
         pname = "luarocks-nix";
         src = /home/my_luarocks/repository;
       });
-    };
   };
 
   luaPackages = lua.pkgs;
@@ -158,9 +154,7 @@ 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
@@ -188,26 +182,24 @@ Each interpreter has the following attributes:
 The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
 The following is an example:
 ```nix
-{
-  luaposix = buildLuarocksPackage {
-    pname = "luaposix";
-    version = "34.0.4-1";
+luaposix = buildLuarocksPackage {
+  pname = "luaposix";
+  version = "34.0.4-1";
 
-    src = fetchurl {
-      url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
-      hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
-    };
-    disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
-    propagatedBuildInputs = [ bit32 lua std_normalize ];
-
-    meta = {
-      homepage = "https://github.com/luaposix/luaposix/";
-      description = "Lua bindings for POSIX";
-      maintainers = with lib.maintainers; [ vyp lblasc ];
-      license.fullName = "MIT/X11";
-    };
+  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:

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.
@@ -219,10 +219,10 @@ stdenv.mkDerivation {
 
   # don't do any fixup
   dontFixup = true;
-  outputHashAlgo = null;
+  outputHashAlgo = "sha256";
   outputHashMode = "recursive";
   # replace this with the correct SHA256
-  outputHash = lib.fakeHash;
+  outputHash = lib.fakeSha256;
 }
 ```
 

doc/languages-frameworks/nim.section.md

@@ -7,7 +7,7 @@ The following example shows a Nim program that depends only on Nim libraries:
 ```nix
 { lib, buildNimPackage, fetchFromGitHub }:
 
-buildNimPackage (finalAttrs: {
+buildNimPackage { } (finalAttrs: {
   pname = "ttop";
   version = "1.2.7";
 
@@ -80,6 +80,7 @@ For example, to propagate a dependency on SDL2 for lockfiles that select the Nim
   /* … */
   sdl2 =
     lockAttrs:
+    finalAttrs:
     { buildInputs ? [ ], ... }:
     {
       buildInputs = buildInputs ++ [ SDL2 ];
@@ -88,8 +89,9 @@ For example, to propagate a dependency on SDL2 for lockfiles that select the Nim
 }
 ```
 
-The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlaid on the package being built.
+The annotations in the `nim-overrides.nix` set are functions that take three arguments and return a new attrset to be overlayed on the package being built.
 - lockAttrs: the attrset for this library from within a lockfile. This can be used to implement library version constraints, such as marking libraries as broken or insecure.
+- finalAttrs: the final attrset passed by `buildNimPackage` to `stdenv.mkDerivation`.
 - prevAttrs: the attrset produced by initial arguments to `buildNimPackage` and any preceding lockfile overlays.
 
 ### Overriding an Nim library override {#nim-lock-overrides-overrides}

doc/languages-frameworks/ocaml.section.md

@@ -92,7 +92,6 @@ 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.
@@ -113,13 +112,21 @@ buildDunePackage rec {
 
   meta = {
     homepage = "https://github.com/flowtype/ocaml-wtf8";
-    description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates";
+    description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
     license = lib.licenses.mit;
     maintainers = [ lib.maintainers.eqyiel ];
   };
 }
 ```
 
+Note about `minimalOCamlVersion`.  A deprecated version of this argument was
+spelled `minimumOCamlVersion`; setting the old attribute wrongly modifies the
+derivation hash and is therefore inappropriate. As a technical dept, currently
+packaged libraries may still use the old spelling: maintainers are invited to
+fix this when updating packages. Massive renaming is strongly discouraged as it
+would be challenging to review, difficult to test, and will cause unnecessary
+rebuild.
+
 The build will automatically fail if two distinct versions of the same library
 are added to `buildInputs` (which usually happens transitively because of
 `propagatedBuildInputs`). Set `dontDetectOcamlConflicts` to true to disable this

doc/languages-frameworks/perl.section.md

@@ -34,27 +34,23 @@ 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:
@@ -95,19 +91,17 @@ 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=";
-    };
-    propagatedBuildInputs = [
-      ClassC3 ClassInspector TestException MROCompat
-    ];
+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
+  ];
+};
 ```
 
 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:
@@ -115,22 +109,20 @@ 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=";
-    };
-
-    nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
-    postInstall = lib.optionalString stdenv.isDarwin ''
-      shortenPerlShebang $out/bin/exiftool
-    '';
+  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
+  '';
+};
 ```
 
 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.
@@ -158,7 +150,7 @@ $ nix-generate-from-cpan XML::Simple
     };
     propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
     meta = {
-      description = "API for simple XML files";
+      description = "An API for simple XML files";
       license = with lib.licenses; [ artistic1 gpl1Plus ];
     };
   };

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 [] ++ [
-          # ...
+          …
         ];
       });
     };
@@ -283,10 +283,7 @@ in {
   ];
 
   composerRepository = php.mkComposerRepository {
-    inherit (finalAttrs) pname version src;
-    composerNoDev = true;
-    composerNoPlugins = true;
-    composerNoScripts = true;
+    inherit (finalAttrs) src;
     # Specifying a custom composer.lock since it is not present in the sources.
     composerLock = ./composer.lock;
     # The composer vendor hash

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

@@ -7,28 +7,24 @@ Nixpkgs provides a couple of facilities for working with this tool.
 ## Writing packages providing pkg-config modules {#pkg-config-writing-packages}
 
 Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
-They should also use `testers.hasPkgConfigModules` to check that the final built package matches that list,
-and optionally check that the pkgconf modules' version metadata matches the derivation's.
+They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list.
 Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig), will do extra checks on to-be-installed pkg-config modules.
 
-A good example of all these things is miniz:
+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.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-    versionCheck = true;
-  };
+  passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
 
   meta = {
-    /* ... */
-    pkgConfigModules = [ "miniz" ];
+    ...
+    pkgConfigModules = [ "zlib" ];
   };
 })
 ```