kscreenlocker: and libkscreen dependency

Fix build with Qt 5.15.8

.editorconfig

@@ -95,13 +95,3 @@ trim_trailing_whitespace = unset
 
 [pkgs/tools/misc/timidity/timidity.cfg]
 trim_trailing_whitespace = unset
-
-[pkgs/tools/virtualization/ovftool/*.ova]
-end_of_line = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-charset = unset
-
-[lib/tests/*.plist]
-indent_style = tab
-insert_final_newline = unset

.gitattributes

@@ -1,6 +1,5 @@
 **/deps.nix linguist-generated
 **/deps.json linguist-generated
-**/deps.toml lingust-generated
 **/node-packages.nix linguist-generated
 
 pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated

.github/CODEOWNERS

@@ -45,7 +45,6 @@
 /pkgs/build-support/setup-hooks                  @Ericson2314
 /pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
 /pkgs/build-support/setup-hooks/auto-patchelf.py @layus
-/pkgs/pkgs-lib                                   @infinisil
 
 # Nixpkgs build-support
 /pkgs/build-support/writers @lassulus @Profpatsch
@@ -90,9 +89,6 @@
 # NixOS integration test driver
 /nixos/lib/test-driver  @tfc
 
-# NixOS QEMU virtualisation
-/nixos/virtualisation/qemu-vm.nix           @raitobezarius
-
 # Systemd
 /nixos/modules/system/boot/systemd.nix      @NixOS/systemd
 /nixos/modules/system/boot/systemd          @NixOS/systemd
@@ -108,7 +104,9 @@
 
 # Python-related code and docs
 /maintainers/scripts/update-python-libraries	              @FRidh
+/pkgs/top-level/python-packages.nix                         @FRidh @jonringer
 /pkgs/development/interpreters/python                       @FRidh
+/pkgs/development/python-modules                            @FRidh @jonringer
 /doc/languages-frameworks/python.section.md                 @FRidh @mweinelt
 /pkgs/development/tools/poetry2nix                          @adisbladis
 /pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
@@ -136,13 +134,11 @@
 /pkgs/development/ruby-modules      @marsam
 
 # Rust
-/pkgs/development/compilers/rust @Mic92 @zowoq @winterqt @figsoda
-/pkgs/build-support/rust @zowoq @winterqt @figsoda
-/doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda
+/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
 
 # C compilers
 /pkgs/development/compilers/gcc @matthewbauer
-/pkgs/development/compilers/llvm @matthewbauer @RaitoBezarius
+/pkgs/development/compilers/llvm @matthewbauer
 
 # Compatibility stuff
 /pkgs/top-level/unix-tools.nix @matthewbauer
@@ -313,8 +309,3 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /pkgs/build-support/node/build-npm-package      @winterqt
 /pkgs/build-support/node/fetch-npm-deps         @winterqt
 /doc/languages-frameworks/javascript.section.md @winterqt
-
-# OCaml
-/pkgs/build-support/ocaml           @romildo @ulrikstrid
-/pkgs/development/compilers/ocaml   @romildo @ulrikstrid
-/pkgs/development/ocaml-modules     @romildo @ulrikstrid

.github/ISSUE_TEMPLATE/bug_report.md

@@ -26,7 +26,6 @@ If applicable, add screenshots to help explain your problem.
 Add any other context about the problem here.
 
 ### Notify maintainers
-
 <!--
 Please @ people who are in the `meta.maintainers` list of the offending package or module.
 If in doubt, check `git blame` for whoever last touched something.

.github/ISSUE_TEMPLATE/build_failure.md

@@ -1,36 +1,31 @@
 ---
 name: Build failure
 about: Create a report to help us improve
-title: 'Build failure: PACKAGENAME'
+title: ''
 labels: '0.kind: build failure'
 assignees: ''
 
 ---
 
 ### Steps To Reproduce
-
 Steps to reproduce the behavior:
 1. build *X*
 
 ### Build log
-
 ```
 log here if short otherwise a link to a gist
 ```
 
 ### Additional context
-
 Add any other context about the problem here.
 
 ### Notify maintainers
-
 <!--
 Please @ people who are in the `meta.maintainers` list of the offending package or module.
 If in doubt, check `git blame` for whoever last touched something.
 -->
 
 ### Metadata
-
 Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
 
 ```console

.github/ISSUE_TEMPLATE/missing_documentation.md

@@ -1,7 +1,7 @@
 ---
 name: Missing or incorrect documentation
 about: Help us improve the Nixpkgs and NixOS reference manuals
-title: 'Documentation: '
+title: ''
 labels: '9.needs: documentation'
 assignees: ''
 
@@ -11,10 +11,6 @@ assignees: ''
 
 <!-- describe your problem -->
 
-## Proposal
-
-<!-- propose a solution (optional) -->
-
 ## Checklist
 
 <!-- make sure this issue is not redundant or obsolete -->
@@ -30,3 +26,7 @@ assignees: ''
 [open documentation issues]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22
 [open documentation pull requests]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+documentation%22%2C%226.topic%3A+documentation%22
 
+## Proposal
+
+<!-- propose a solution -->
+

.github/ISSUE_TEMPLATE/out_of_date_package_report.md

@@ -1,17 +1,24 @@
 ---
 name: Out-of-date package reports
 about: For packages that are out-of-date
-title: 'Update request: PACKAGENAME OLDVERSION → NEWVERSION'
+title: ''
 labels: '9.needs: package (update)'
 assignees: ''
 
 ---
 
-- Package name:
-- Latest released version:
-<!-- Search your package here: https://search.nixos.org/packages?channel=unstable -->
-- Current version on the unstable channel:
-- Current version on the stable/release channel:
+
+###### Checklist
+
+<!-- Note that these are hard requirements -->
+
+<!--
+You can use the "Go to file" functionality on GitHub to find the package
+Then you can go to the history for this package
+Find the latest "package_name: old_version -> new_version" commit
+The "new_version" is the current version of the package
+-->
+- [ ] Checked the [nixpkgs master branch](https://github.com/NixOS/nixpkgs)
 <!--
 Type the name of your package and try to find an open pull request for the package
 If you find an open pull request, you can review it!
@@ -19,10 +26,23 @@ There's a high chance that you'll have the new version right away while helping
 -->
 - [ ] Checked the [nixpkgs pull requests](https://github.com/NixOS/nixpkgs/pulls)
 
-**Notify maintainers**
+###### Project name
+`nix search` name:
+<!--
+The current version can be found easily with the same process as above for checking the master branch
+If an open PR is present for the package, take this version as the current one and link to the PR
+-->
+current version:
+desired version:
 
-<!-- If the search.nixos.org result shows no maintainers, tag the person that last updated the package. -->
+###### Notify maintainers
+<!--
+Search your package here: https://search.nixos.org/packages?channel=unstable
+If no maintainer is listed for your package, tag the person that last updated the package
+-->
 
------
+maintainers:
 
-Note for maintainers: Please tag this issue in your PR.
+###### Note for maintainers
+
+Please tag this issue in your PR.

.github/ISSUE_TEMPLATE/packaging_request.md

@@ -1,15 +1,14 @@
 ---
 name: Packaging requests
 about: For packages that are missing
-title: 'Package request: PACKAGENAME'
+title: ''
 labels: '0.kind: packaging request'
 assignees: ''
 
 ---
 
 **Project description**
-
-<!-- Describe the project a little: -->
+_describe the project a little_
 
 **Metadata**
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -26,6 +26,7 @@ For new packages please briefly describe the package or provide a link to its ho
   - [ ] (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
+  - [ ] (Release notes changes) Ran `nixos/doc/manual/md-to-db.sh` to update generated release notes
 - [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
 
 <!--

.github/workflows/backport.yml

@@ -24,10 +24,9 @@ jobs:
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - name: Create backport PRs
-        uses: korthout/backport-action@v1.2.0
+        uses: korthout/backport-action@v1.0.1
         with:
           # Config README: https://github.com/korthout/backport-action#backport-action
-          copy_labels_pattern: 'severity:\ssecurity'
           pull_description: |-
             Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
 

.github/workflows/basic-eval.yml

@@ -19,7 +19,7 @@ jobs:
     # we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
     steps:
     - uses: actions/checkout@v3
-    - uses: cachix/install-nix-action@v20
+    - uses: cachix/install-nix-action@v18
     - uses: cachix/cachix-action@v12
       with:
         # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.

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

@@ -1,24 +0,0 @@
-name: "Check that maintainer list is sorted"
-
-on:
-  pull_request_target:
-    paths:
-      - 'maintainers/maintainer-list.nix'
-permissions:
-  contents: read
-
-jobs:
-  nixos:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-      - uses: actions/checkout@v3
-        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@v20
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-      - name: Check that maintainer-list.nix is sorted
-        run: nix-instantiate --eval maintainers/scripts/check-maintainers-sorted.nix

.github/workflows/editorconfig.yml

@@ -11,7 +11,7 @@ on:
 jobs:
   tests:
     runs-on: ubuntu-latest
-    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
+    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip editorconfig]')"
     steps:
     - name: Get list of changed files from PR
       env:
@@ -28,14 +28,16 @@ jobs:
       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@v20
+    - uses: cachix/install-nix-action@v18
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0
         nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
+    - name: install editorconfig-checker
+      run: nix-env -iA editorconfig-checker -f '<nixpkgs>'
     - name: Checking EditorConfig
       run: |
-        cat "$HOME/changed_files" | nix-shell -p editorconfig-checker --run 'xargs -r editorconfig-checker -disable-indent-size'
+        cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
     - if: ${{ failure() }}
       run: |
         echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."

.github/workflows/labels.yml

@@ -16,7 +16,7 @@ permissions:
 jobs:
   labels:
     runs-on: ubuntu-latest
-    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
+    if: github.repository_owner == 'NixOS'
     steps:
     - uses: actions/labeler@v4
       with:

.github/workflows/manual-nixos.yml

@@ -18,7 +18,7 @@ jobs:
         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@v20
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/manual-nixpkgs.yml

@@ -8,7 +8,6 @@ on:
       - master
     paths:
       - 'doc/**'
-      - 'lib/**'
 
 jobs:
   nixpkgs:
@@ -19,7 +18,7 @@ jobs:
         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@v20
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/manual-rendering.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v20
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
@@ -54,7 +54,7 @@ jobs:
       # less noisy until all nixpkgs pull requests have stopped using
       # docbook for option docs.
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() && steps.check.conclusion == 'failure' }}
         with:
           issue-number: 189318

.github/workflows/nixos-manual.yml

@@ -0,0 +1,34 @@
+name: NixOS manual checks
+
+permissions: read-all
+
+on:
+  pull_request_target:
+    branches-ignore:
+      - 'release-**'
+    paths:
+      - 'nixos/**/*.xml'
+      - 'nixos/**/*.md'
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    if: github.repository_owner == 'NixOS'
+    steps:
+    - uses: actions/checkout@v3
+      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@v18
+    - name: Check DocBook files generated from Markdown are consistent
+      run: |
+        nixos/doc/manual/md-to-db.sh
+        git diff --exit-code || {
+          echo
+          echo 'Generated manual files are out of date.'
+          echo 'Please run'
+          echo
+          echo '    nixos/doc/manual/md-to-db.sh'
+          echo
+          exit 1
+        }

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

@@ -51,7 +51,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() }}
         with:
           issue-number: 105153

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

@@ -49,7 +49,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() }}
         with:
           issue-number: 105153

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

@@ -12,12 +12,12 @@ jobs:
   tf-providers:
     permissions:
       contents: write # for peter-evans/create-pull-request to create branch
-      pull-requests: write # for peter-evans/create-pull-request to create a PR
+      pull-requests: write # for peter-evans/create-pull-request to create a PR, for peter-evans/create-or-update-comment to create or update comment
     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@v3
-      - uses: cachix/install-nix-action@v20
+      - uses: cachix/install-nix-action@v18
         with:
           nix_path: nixpkgs=channel:nixpkgs-unstable
       - name: setup
@@ -36,33 +36,21 @@ jobs:
             --argstr keep-going true \
             --argstr max-workers 2 \
             --argstr path terraform-providers
-      - name: get failed updates
-        run: |
-          echo 'FAILED<<EOF' >> $GITHUB_ENV
-          git ls-files --others >> $GITHUB_ENV
-          echo 'EOF' >> $GITHUB_ENV
-      # cleanup logs of failed updates so they aren't included in the PR
       - name: clean repo
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@v5
+        uses: peter-evans/create-pull-request@v4
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
 
             https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}
 
-            These providers failed to update:
-            ```
-            ${{ env.FAILED }}
-            ```
-
             Check that all providers build with:
             ```
             @ofborg build terraform.full
             ```
-            If there is more than ten commits in the PR `ofborg` won't build it automatically and you will need to use the above command.
           branch: terraform-providers-update
           delete-branch: false
           title: ${{ steps.setup.outputs.title }}

CONTRIBUTING.md

@@ -43,7 +43,6 @@ Below is a short excerpt of some points in there:
   * Not start with the package name.
     * More generally, it should not refer to the package name.
   * Not end with a period (or any punctuation for that matter).
-  * Aim to inform while avoiding subjective language.
 * `meta.license` must be set and fit the upstream license.
   * If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
   * If in doubt, try to contact the upstream developers for clarification.
@@ -129,17 +128,14 @@ Anything that does not cause user or downstream dependency regressions can be ba
 - Security critical applications (E.g. `firefox`)
 
 ## Generating 23.05 Release Notes
-<!--
-note: title unchanged even though we don't need regeneration because extant
-PRs will link here. definitely change the title for 23.11 though.
--->
 
-Documentation in nixpkgs is transitioning to a markdown-centric workflow. In the past release notes required a translation step to convert from markdown to a compatible docbook document, but this is no longer necessary.
+Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
 
 Steps for updating 23.05 Release notes:
 
 1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
-2. Commit changes to `rl-2305.section.md`.
+2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2305.section.xml`
+3. Include changes to `rl-2305.section.md` and `rl-2305.section.xml` in the same commit.
 
 ## Reviewing contributions
 

doc/.gitignore

@@ -6,6 +6,3 @@ functions/library/locations.xml
 highlightjs
 manual-full.xml
 out
-result
-result-*
-media

doc/Makefile

@@ -3,7 +3,7 @@ MD_TARGETS=$(addsuffix .xml, $(basename $(shell find . -type f -regex '.*\.md$$'
 PANDOC ?= pandoc
 
 pandoc_media_dir = media
-# NOTE: Keep in sync with conversion script (/maintainers/scripts/db-to-md.sh).
+# NOTE: Keep in sync with NixOS manual (/nixos/doc/manual/md-to-db.sh) and conversion script (/maintainers/scripts/db-to-md.sh).
 # TODO: Remove raw-attribute when we can get rid of DocBook altogether.
 pandoc_commonmark_enabled_extensions = +attributes+fenced_divs+footnotes+bracketed_spans+definition_lists+pipe_tables+raw_attribute
 # Not needed:
@@ -19,9 +19,6 @@ pandoc_flags = --extract-media=$(pandoc_media_dir) \
 .PHONY: all
 all: validate format out/html/index.html out/epub/manual.epub
 
-.PHONY: render-md
-render-md: ${MD_TARGETS}
-
 .PHONY: debug
 debug:
 	nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"

doc/build-aux/pandoc-filters/docbook-writer/html-elements.lua

@@ -0,0 +1,11 @@
+--[[
+Converts some HTML elements commonly used in Markdown to corresponding DocBook elements.
+]]
+
+function RawInline(elem)
+  if elem.format == 'html' and elem.text == '<kbd>' then
+    return pandoc.RawInline('docbook', '<keycap>')
+  elseif elem.format == 'html' and elem.text == '</kbd>' then
+    return pandoc.RawInline('docbook', '</keycap>')
+  end
+end

doc/build-aux/pandoc-filters/link-manpages.nix

@@ -1,7 +1,7 @@
 { pkgs ? import ../../.. {} }:
 let
   inherit (pkgs) lib;
-  manpageURLs = lib.importJSON (pkgs.path + "/doc/manpage-urls.json");
+  manpageURLs = builtins.fromJSON (builtins.readFile (pkgs.path + "/doc/manpage-urls.json"));
 in pkgs.writeText "link-manpages.lua" ''
   --[[
   Adds links to known man pages that aren't already in a link.

doc/builders/fetchers.chapter.md

@@ -3,7 +3,7 @@
 Building software with Nix often requires downloading source code and other files from the internet.
 `nixpkgs` provides *fetchers* for different protocols and services. Fetchers are functions that simplify downloading files.
 
-## Caveats {#chap-pkgs-fetchers-caveats}
+## Caveats
 
 Fetchers create [fixed output derivations](https://nixos.org/manual/nix/stable/#fixed-output-drvs) from downloaded files.
 Nix can reuse the downloaded files via the hash of the resulting derivation.
@@ -71,7 +71,6 @@ The main difference between `fetchurl` and `fetchzip` is in how they store the c
 
 - `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
 - `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
-- `decode`: Pipe the downloaded data through this command before processing it as a patch.
 - `extraPrefix`: Prefix pathnames by this string.
 - `excludes`: Exclude files matching these patterns (applies after the above arguments).
 - `includes`: Include only files matching these patterns (applies after the above arguments).
@@ -164,30 +163,3 @@ or "hg"), `domain` and `fetchSubmodules`.
 If `fetchSubmodules` is `true`, `fetchFromSourcehut` uses `fetchgit`
 or `fetchhg` with `fetchSubmodules` or `fetchSubrepos` set to `true`,
 respectively. Otherwise, the fetcher uses `fetchzip`.
-
-## `requireFile` {#requirefile}
-
-`requireFile` allows requesting files that cannot be fetched automatically, but whose content is known.
-This is a useful last-resort workaround for license restrictions that prohibit redistribution, or for downloads that are only accessible after authenticating interactively in a browser.
-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:
-
-```
-requireFile {
-  name = "jdk-${version}_linux-x64_bin.tar.gz";
-  url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
-  sha256 = "94bd34f85ee38d3ef59e5289ec7450b9443b924c55625661fffe66b03f2c8de2";
-}
-```
-results in this error message:
-```
-***
-Unfortunately, we cannot download file jdk-11.0.10_linux-x64_bin.tar.gz automatically.
-Please go to https://www.oracle.com/java/technologies/javase-jdk11-downloads.html to download it yourself, and add it to the Nix store
-using either
-  nix-store --add-fixed sha256 jdk-11.0.10_linux-x64_bin.tar.gz
-or
-  nix-prefetch-url --type sha256 file:///path/to/jdk-11.0.10_linux-x64_bin.tar.gz
-
-***
-```

doc/builders/images.xml

@@ -11,5 +11,4 @@
  <xi:include href="images/snaptools.section.xml" />
  <xi:include href="images/portableservice.section.xml" />
  <xi:include href="images/makediskimage.section.xml" />
- <xi:include href="images/binarycache.section.xml" />
 </chapter>

doc/builders/images/binarycache.section.md

@@ -1,49 +0,0 @@
-# pkgs.mkBinaryCache {#sec-pkgs-binary-cache}
-
-`pkgs.mkBinaryCache` is a function for creating Nix flat-file binary caches. Such a cache exists as a directory on disk, and can be used as a Nix substituter by passing `--substituter file:///path/to/cache` to Nix commands.
-
-Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](https://nixos.org/manual/nix/stable/package-management/sharing-packages.html), but a flat-file binary cache can still be useful in some situations. For example, you can copy it directly to another machine, or make it available on a network file system. It can also be a convenient way to make some Nix packages available inside a container via bind-mounting.
-
-Note that this function is meant for advanced use-cases. The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command. You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs.
-
-## Example {#sec-pkgs-binary-cache-example}
-
-The following derivation will construct a flat-file binary cache containing the closure of `hello`.
-
-```nix
-mkBinaryCache {
-  rootPaths = [hello];
-}
-```
-
-- `rootPaths` specifies a list of root derivations. The transitive closure of these derivations' outputs will be copied into the cache.
-
-Here's an example of building and using the cache.
-
-Build the cache on one machine, `host1`:
-
-```shellSession
-nix-build -E 'with import <nixpkgs> {}; mkBinaryCache { rootPaths = [hello]; }'
-```
-
-```shellSession
-/nix/store/cc0562q828rnjqjyfj23d5q162gb424g-binary-cache
-```
-
-Copy the resulting directory to the other machine, `host2`:
-
-```shellSession
-scp result host2:/tmp/hello-cache
-```
-
-Substitute the derivation using the flat-file binary cache on the other machine, `host2`:
-```shellSession
-nix-build -A hello '<nixpkgs>' \
-  --option require-sigs false \
-  --option trusted-substituters file:///tmp/hello-cache \
-  --option substituters file:///tmp/hello-cache
-```
-
-```shellSession
-/nix/store/gl5a41azbpsadfkfmbilh9yk40dh5dl0-hello-2.12.1
-```

doc/builders/images/dockertools.section.md

@@ -145,7 +145,7 @@ Create a Docker image with many of the store paths being on their own layer to i
 
 `architecture` is _optional_ and used to specify the image architecture, this is useful for multi-architecture builds that don't need cross compiling. If not specified it will default to `hostPlatform`.
 
-: Run-time configuration of the container. A full list of the options available is in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
+: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
 
     *Default:* `{}`
 
@@ -410,7 +410,7 @@ If the derivation is fully buildable (i.e. `nix-build` can be used on it), runni
 The behavior doesn't match `nix-shell` or `nix-build` exactly and this function is known not to work correctly for e.g. fixed-output derivations, content-addressed derivations, impure derivations and other special types of derivations.
 :::
 
-### Arguments {#ssec-pkgs-dockerTools-buildNixShellImage-arguments}
+### Arguments
 
 `drv`
 
@@ -473,7 +473,7 @@ The behavior doesn't match `nix-shell` or `nix-build` exactly and this function
 
     *Default:* (none)
 
-### Example {#ssec-pkgs-dockerTools-buildNixShellImage-example}
+### Example
 
 The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`.
 

doc/builders/images/makediskimage.section.md

@@ -12,12 +12,12 @@ Whereas for many web servers, applications, it is possible to work with a Nix st
 
 NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used.
 
-## Features {#sec-make-disk-image-features}
+## Features
 
 For reference, read the function signature source code for documentation on arguments: <https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-disk-image.nix>.
 Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image.
 
-### Common {#sec-make-disk-image-features-common}
+### Common
 
 - arbitrary NixOS configuration
 - automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space
@@ -29,7 +29,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto
 - the current nixpkgs can be realized as a channel in the disk image, which will change the hash of the image when the sources are updated
 - additional store paths can be provided through `additionalPaths`
 
-### Full NixOS image {#sec-make-disk-image-features-full-image}
+### Full NixOS image
 
 - arbitrary contents with permissions can be placed in the target filesystem using `contents`
 - a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile`
@@ -37,7 +37,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto
 - EFI variables can be mutated during image production and the result is exposed in `$out`
 - boot partition size when partition table is `efi` or `hybrid`
 
-### On bit-to-bit reproducibility {#sec-make-disk-image-features-reproducibility}
+### On bit-to-bit reproducibility
 
 Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
 
@@ -47,7 +47,7 @@ Images are **NOT** deterministic, please do not hesitate to try to fix this, sou
 
 A `deterministic` flag is available for best efforts determinism.
 
-## Usage {#sec-make-disk-image-usage}
+## Usage
 
 To produce a Nix-store only image:
 ```nix
@@ -101,7 +101,6 @@ in
     diskSize = "auto";
     additionalSpace = "0M"; # Defaults to 512M.
     copyChannel = false;
-    memSize = 2048; # Qemu VM memory size in megabytes. Defaults to 1024M.
   }
 ```
 

doc/builders/packages/citrix.section.md

@@ -4,7 +4,7 @@ The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a
 
 ## Basic usage {#sec-citrix-base}
 
-The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
+The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
 
 ## Citrix Self-service {#sec-citrix-selfservice}
 
@@ -19,7 +19,7 @@ $ selfservice
 
 ## Custom certificates {#sec-citrix-custom-certs}
 
-The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
+The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
 
 ```nix
 with import <nixpkgs> { config.allowUnfree = true; };

doc/builders/packages/ibus.section.md

@@ -4,7 +4,7 @@ This package is an ibus-based completion method to speed up typing.
 
 ## Activating the engine {#sec-ibus-typing-booster-activate}
 
-IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/).
+IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/documentation.html).
 
 On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
 

doc/builders/special.xml

@@ -6,8 +6,6 @@
   This chapter describes several special builders.
  </para>
  <xi:include href="special/fhs-environments.section.xml" />
- <xi:include href="special/makesetuphook.section.xml" />
  <xi:include href="special/mkshell.section.xml" />
  <xi:include href="special/darwin-builder.section.xml" />
- <xi:include href="special/vm-tools.section.xml" />
 </chapter>

doc/builders/special/darwin-builder.section.md

@@ -61,89 +61,3 @@ builders-use-substitutes = true
 ```ShellSession
 $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
 ```
-
-## Example flake usage
-
-```
-{
-  inputs = {
-    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-22.11-darwin";
-    darwin.url = "github:lnl7/nix-darwin/master";
-    darwin.inputs.nixpkgs.follows = "nixpkgs";
-  };
-
-  outputs = { self, darwin, nixpkgs, ... }@inputs:
-  let
-
-    inherit (darwin.lib) darwinSystem;
-    system = "aarch64-darwin";
-    pkgs = nixpkgs.legacyPackages."${system}";
-    linuxSystem = builtins.replaceStrings [ "darwin" ] [ "linux" ] system;
-
-    darwin-builder = nixpkgs.lib.nixosSystem {
-      system = linuxSystem;
-      modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
-        { virtualisation.host.pkgs = pkgs; }
-      ];
-    };
-  in {
-
-    darwinConfigurations = {
-      machine1 = darwinSystem {
-        inherit system;
-        modules = [
-          {
-            nix.distributedBuilds = true;
-            nix.buildMachines = [{
-              hostName = "ssh://builder@localhost";
-              system = linuxSystem;
-              maxJobs = 4;
-              supportedFeatures = [ "kvm" "benchmark" "big-parallel" ];
-            }];
-
-            launchd.daemons.darwin-builder = {
-              command = "${darwin-builder.config.system.build.macos-builder-installer}/bin/create-builder";
-              serviceConfig = {
-                KeepAlive = true;
-                RunAtLoad = true;
-                StandardOutPath = "/var/log/darwin-builder.log";
-                StandardErrorPath = "/var/log/darwin-builder.log";
-              };
-            };
-          }
-        ];
-      };
-    };
-
-  };
-}
-```
-
-## Reconfiguring the builder
-
-Initially you should not change the builder configuration else you will not be
-able to use the binary cache. However, after you have the builder running locally
-you may use it to build a modified builder with additional storage or memory.
-
-To do this, you just need to set the `virtualisation.darwin-builder.*` parameters as
-in the example below and rebuild.
-
-```
-    darwin-builder = nixpkgs.lib.nixosSystem {
-      system = linuxSystem;
-      modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
-        {
-          virtualisation.host.pkgs = pkgs;
-          virtualisation.darwin-builder.diskSize = 5120;
-          virtualisation.darwin-builder.memorySize = 1024;
-          virtualisation.darwin-builder.hostPort = 33022;
-          virtualisation.darwin-builder.workingDirectory = "/var/lib/darwin-builder";
-        }
-      ];
-```
-
-You may make any other changes to your VM in this attribute set. For example,
-you could enable Docker or X11 forwarding to your Darwin host.
-

doc/builders/special/fhs-environments.section.md

@@ -1,6 +1,6 @@
-# buildFHSEnv {#sec-fhs-environments}
+# buildFHSUserEnv {#sec-fhs-environments}
 
-`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
+`buildFHSUserEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
 
 - `name`
         Environment name.
@@ -26,7 +26,7 @@ One can create a simple environment using a `shell.nix` like that:
 ```nix
 { pkgs ? import <nixpkgs> {} }:
 
-(pkgs.buildFHSEnv {
+(pkgs.buildFHSUserEnv {
   name = "simple-x11-env";
   targetPkgs = pkgs: (with pkgs;
     [ udev

doc/builders/special/makesetuphook.section.md

@@ -1,37 +0,0 @@
-# pkgs.makeSetupHook {#sec-pkgs.makeSetupHook}
-
-`pkgs.makeSetupHook` is a builder that produces hooks that go in to `nativeBuildInputs`
-
-## Usage {#sec-pkgs.makeSetupHook-usage}
-
-```nix
-pkgs.makeSetupHook {
-  name = "something-hook";
-  propagatedBuildInputs = [ pkgs.commandsomething ];
-  depsTargetTargetPropagated = [ pkgs.libsomething ];
-} ./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 {
-    name = "run-hello-hook";
-    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}
-
-* `name` Set the name of the hook.
-* `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook.
-* `depsTargetTargetPropagated` Non-binary dependencies.
-* `meta`
-* `passthru`
-* `substitutions` Variables for `substituteAll`

doc/builders/special/mkshell.section.md

@@ -20,7 +20,7 @@ pkgs.mkShell {
 }
 ```
 
-## Attributes {#sec-pkgs-mkShell-attributes}
+## Attributes
 
 * `name` (default: `nix-shell`). Set the name of the derivation.
 * `packages` (default: `[]`). Add executable packages to the `nix-shell` environment.
@@ -29,7 +29,7 @@ pkgs.mkShell {
 
 ... all the attributes of `stdenv.mkDerivation`.
 
-## Building the shell {#sec-pkgs-mkShell-building}
+## Building the shell
 
 This derivation output will contain a text file that contains a reference to
 all the build inputs. This is useful in CI where we want to make sure that

doc/builders/special/vm-tools.section.md

@@ -1,148 +0,0 @@
-# vmTools {#sec-vm-tools}
-
-A set of VM related utilities, that help in building some packages in more advanced scenarios.
-
-## `vmTools.createEmptyImage` {#vm-tools-createEmptyImage}
-
-A bash script fragment that produces a disk image at `destination`.
-
-### Attributes
-
-* `size`. The disk size, in MiB.
-* `fullName`. Name that will be written to `${destination}/nix-support/full-name`.
-* `destination` (optional, default `$out`). Where to write the image files.
-
-## `vmTools.runInLinuxVM` {#vm-tools-runInLinuxVM}
-
-Run a derivation in a Linux virtual machine (using Qemu/KVM).
-By default, there is no disk image; the root filesystem is a `tmpfs`, and the Nix store is shared with the host (via the [9P protocol](https://wiki.qemu.org/Documentation/9p#9p_Protocol)).
-Thus, any pure Nix derivation should run unmodified.
-
-If the build fails and Nix is run with the `-K/--keep-failed` option, a script `run-vm` will be left behind in the temporary build directory that allows you to boot into the VM and debug it interactively.
-
-### Attributes
-
-* `preVM` (optional). Shell command to be evaluated *before* the VM is started (i.e., on the host).
-* `memSize` (optional, default `512`). The memory size of the VM in MiB.
-* `diskImage` (optional). A file system image to be attached to `/dev/sda`.
-  Note that currently we expect the image to contain a filesystem, not a full disk image with a partition table etc.
-
-### Examples
-
-Build the derivation hello inside a VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM hello
-```
-
-Build inside a VM with extra memory:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM (hello.overrideAttrs (_: { memSize = 1024; }))
-```
-
-Use VM with a disk image (implicitly sets `diskImage`, see [`vmTools.createEmptyImage`](#vm-tools-createEmptyImage)):
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM (hello.overrideAttrs (_: {
-  preVM = createEmptyImage {
-    size = 1024;
-    fullName = "vm-image";
-  };
-}))
-```
-
-## `vmTools.extractFs` {#vm-tools-extractFs}
-
-Takes a file, such as an ISO, and extracts its contents into the store.
-
-### Attributes
-
-* `file`. Path to the file to be extracted.
-  Note that currently we expect the image to contain a filesystem, not a full disk image with a partition table etc.
-* `fs` (optional). Filesystem of the contents of the file.
-
-### Examples
-
-Extract the contents of an ISO file:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-extractFs { file = ./image.iso; }
-```
-
-## `vmTools.extractMTDfs` {#vm-tools-extractMTDfs}
-
-Like [](#vm-tools-extractFs), but it makes use of a [Memory Technology Device (MTD)](https://en.wikipedia.org/wiki/Memory_Technology_Device).
-
-## `vmTools.runInLinuxImage` {#vm-tools-runInLinuxImage}
-
-Like [](#vm-tools-runInLinuxVM), but instead of using `stdenv` from the Nix store, run the build using the tools provided by `/bin`, `/usr/bin`, etc. from the specified filesystem image, which typically is a filesystem containing a [FHS](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)-based Linux distribution.
-
-## `vmTools.makeImageTestScript` {#vm-tools-makeImageTestScript}
-
-Generate a script that can be used to run an interactive session in the given image.
-
-### Examples
-
-Create a script for running a Fedora 27 VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-makeImageTestScript diskImages.fedora27x86_64
-```
-
-Create a script for running an Ubuntu 20.04 VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-makeImageTestScript diskImages.ubuntu2004x86_64
-```
-
-## `vmTools.diskImageFuns` {#vm-tools-diskImageFuns}
-
-A set of functions that build a predefined set of minimal Linux distributions images.
-
-### Images
-
-* Fedora
-  * `fedora26x86_64`
-  * `fedora27x86_64`
-* CentOS
-  * `centos6i386`
-  * `centos6x86_64`
-  * `centos7x86_64`
-* Ubuntu
-  * `ubuntu1404i386`
-  * `ubuntu1404x86_64`
-  * `ubuntu1604i386`
-  * `ubuntu1604x86_64`
-  * `ubuntu1804i386`
-  * `ubuntu1804x86_64`
-  * `ubuntu2004i386`
-  * `ubuntu2004x86_64`
-  * `ubuntu2204i386`
-  * `ubuntu2204x86_64`
-* Debian
-  * `debian10i386`
-  * `debian10x86_64`
-  * `debian11i386`
-  * `debian11x86_64`
-
-### Attributes
-
-* `size` (optional, defaults to `4096`). The size of the image, in MiB.
-* `extraPackages` (optional). A list names of additional packages from the distribution that should be included in the image.
-
-### Examples
-
-8GiB image containing Firefox in addition to the default packages:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-diskImageFuns.ubuntu2004x86_64 { extraPackages = [ "firefox" ]; size = 8192; }
-```
-
-## `vmTools.diskImageExtraFuns` {#vm-tools-diskImageExtraFuns}
-
-Shorthand for `vmTools.diskImageFuns.<attr> { extraPackages = ... }`.
-
-## `vmTools.diskImages` {#vm-tools-diskImages}
-
-Shorthand for `vmTools.diskImageFuns.<attr> { }`.

doc/builders/testers.chapter.md

@@ -1,19 +1,6 @@
 # Testers {#chap-testers}
 This chapter describes several testing builders which are available in the <literal>testers</literal> namespace.
 
-## `hasPkgConfigModule` {#tester-hasPkgConfigModule}
-
-Checks whether a package exposes a certain `pkg-config` module.
-
-Example:
-
-```nix
-passthru.tests.pkg-config = testers.hasPkgConfigModule {
-  package = finalAttrs.finalPackage;
-  moduleName = "libfoo";
-}
-```
-
 ## `testVersion` {#tester-testVersion}
 
 Checks the command output contains the specified version
@@ -178,7 +165,7 @@ letting NixOS invoke Nixpkgs anew.
 If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
 `nixpkgs.pkgs` option.
 
-### Parameter {#tester-nixosTest-parameter}
+### Parameter
 
 A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example:
 
@@ -200,7 +187,7 @@ A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-te
 }
 ```
 
-### Result {#tester-nixosTest-result}
+### Result
 
 A derivation that runs the VM test.
 

doc/contributing/coding-conventions.chapter.md

@@ -204,13 +204,13 @@ The key words _must_, _must not_, _required_, _shall_, _shall not_, _should_, _s
 
 In Nixpkgs, there are generally three different names associated with a package:
 
-- The `pname` attribute of the derivation. This is what most users see, in particular when using `nix-env`.
+- The `name` attribute of the derivation (excluding the version part). This is what most users see, in particular when using `nix-env`.
 
 - The variable name used for the instantiated package in `all-packages.nix`, and when passing it as a dependency to other functions. Typically this is called the _package attribute name_. This is what Nix expression authors see. It can also be used when installing using `nix-env -iA`.
 
 - The filename for (the directory containing) the Nix expression.
 
-Most of the time, these are the same. For instance, the package `e2fsprogs` has a `pname` attribute `"e2fsprogs"`, is bound to the variable name `e2fsprogs` in `all-packages.nix`, and the Nix expression is in `pkgs/os-specific/linux/e2fsprogs/default.nix`.
+Most of the time, these are the same. For instance, the package `e2fsprogs` has a `name` attribute `"e2fsprogs-version"`, is bound to the variable name `e2fsprogs` in `all-packages.nix`, and the Nix expression is in `pkgs/os-specific/linux/e2fsprogs/default.nix`.
 
 There are a few naming guidelines:
 
@@ -454,7 +454,7 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
     owner = "NixOS";
     repo = "nix";
     rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
-    hash = "ha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
+    hash = "ha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=;
   }
   ```
 

doc/contributing/contributing-to-documentation.chapter.md

@@ -27,7 +27,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
 
 As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
 
-Additional syntax extensions are available, all of which can be used in NixOS option documentation. The following extensions are currently used:
+Additional syntax extensions are available, though not all extensions can be used in NixOS option documentation. The following extensions are currently used:
 
 - []{#ssec-contributing-markup-anchors}
   Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
@@ -38,10 +38,6 @@ Additional syntax extensions are available, all of which can be used in NixOS op
   ## Syntax {#sec-contributing-markup}
   ```
 
-  ::: {.note}
-  NixOS option documentation does not support headings in general.
-  :::
-
 - []{#ssec-contributing-markup-anchors-inline}
   **Inline anchors**, which allow linking arbitrary place in the text (e.g. individual list items, sentences…).
 
@@ -71,6 +67,10 @@ Additional syntax extensions are available, all of which can be used in NixOS op
 
   This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
 
+  ::: {.note}
+  Inline roles are available for option documentation.
+  :::
+
 - []{#ssec-contributing-markup-admonitions}
   **Admonitions**, set off from the text to bring attention to something.
 
@@ -96,6 +96,10 @@ Additional syntax extensions are available, all of which can be used in NixOS op
     - [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
     - [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
 
+  ::: {.note}
+  Admonitions are available for option documentation.
+  :::
+
 - []{#ssec-contributing-markup-definition-lists}
   [**Definition lists**](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md), for defining a group of terms:
 

doc/contributing/submitting-changes.chapter.md

@@ -290,7 +290,7 @@ Other examples of reasons are:
 - The previous download links were all broken
 - Crash when starting on some X11 systems
 
-#### Acceptable backport criteria {#acceptable-backport-criteria}
+#### Acceptable backport criteria
 
 The stable branch does have some changes which cannot be backported. Most notable are breaking changes. The desire is to have stable users be uninterrupted when updating packages.
 

doc/default.nix

@@ -1,5 +1,6 @@
 { pkgs ? (import ./.. { }), nixpkgs ? { }}:
 let
+  lib = pkgs.lib;
   doc-support = import ./doc-support { inherit pkgs nixpkgs; };
 in pkgs.stdenv.mkDerivation {
   name = "nixpkgs-manual";
@@ -14,16 +15,12 @@ in pkgs.stdenv.mkDerivation {
     xmlformat
   ];
 
-  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
+  src = lib.cleanSource ./.;
 
   postPatch = ''
     ln -s ${doc-support} ./doc-support/result
   '';
 
-  preBuild = ''
-    make -j$NIX_BUILD_CORES render-md
-  '';
-
   installPhase = ''
     dest="$out/share/doc/nixpkgs"
     mkdir -p "$(dirname "$dest")"

doc/doc-support/default.nix

@@ -45,10 +45,7 @@ let
   # 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;
+    inherit (pkgs.lib.evalModules { modules = [ ../../pkgs/top-level/config.nix ]; }) options;
     documentType = "none";
     transformOptions = opt:
       opt // {
@@ -78,7 +75,7 @@ in pkgs.runCommand "doc-support" {}
     ln -s ${epub-xsl} ./epub.xsl
     ln -s ${xhtml-xsl} ./xhtml.xsl
 
-    ln -s ${./xmlformat.conf} ./xmlformat.conf
+    ln -s ${../../nixos/doc/xmlformat.conf} ./xmlformat.conf
     ln -s ${pkgs.documentation-highlighter} ./highlightjs
 
     echo -n "${version}" > ./version

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

@@ -1,6 +1,6 @@
 { pkgs, nixpkgs ? { }, libsets }:
 let
-  revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.rev or "master");
+  revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
 
   libDefPos = prefix: set:
     builtins.concatMap

doc/hooks/breakpoint.section.md

@@ -10,7 +10,9 @@ nativeBuildInputs = [ breakpointHook ];
 When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
 
 ::: {.note}
+::: {.title}
 Caution with remote builds
+:::
 
 This won’t work with remote builds as the build environment is on a different machine and can’t be accessed by `cntr`. Remote builds can be turned off by setting `--option builders ''` for `nix-build` or `--builders ''` for `nix build`.
 :::

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

@@ -9,7 +9,7 @@ stdenv.mkDerivation {
 
   # ...
 
-  nativeCheckInputs = [
+  checkInputs = [
     postgresql
     postgresqlTestHook
   ];
@@ -46,12 +46,6 @@ Bash-only variables:
  - `postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended.
  - `postgresqlStartCommands`: defaults to `pg_ctl start`.
 
-## Hooks {#sec-postgresqlTestHook-hooks}
-
-A number of additional hooks are ran in postgresqlTestHook
-
- - `postgresqlTestSetupPost`: ran after postgresql has been set up.
-
 ## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp}
 
 `postgresqlEnableTCP` relies on network sandboxing, which is not available on macOS and some custom Nix installations, resulting in flaky tests.

doc/languages-frameworks/agda.section.md

@@ -216,7 +216,7 @@ you can test whether it builds correctly by writing in a comment:
 @ofborg build agdaPackages.iowa-stdlib
 ```
 
-### Maintaining Agda packages {#agda-maintaining-packages}
+### Maintaining Agda packages
 
 As mentioned before, the aim is to have a compatible, and up-to-date package set.
 These two conditions sometimes exclude each other:

doc/languages-frameworks/android.section.md

@@ -13,7 +13,6 @@ with import <nixpkgs> {};
 
 let
   androidComposition = androidenv.composeAndroidPackages {
-    cmdLineToolsVersion = "8.0";
     toolsVersion = "26.1.1";
     platformToolsVersion = "30.0.5";
     buildToolsVersions = [ "30.0.3" ];
@@ -43,10 +42,7 @@ exceptions are the tools, platform-tools and build-tools sub packages.
 
 The following parameters are supported:
 
-* `cmdLineToolsVersion `, specifies the version of the `cmdline-tools` package to use
-* `toolsVersion`, specifies the version of the `tools` package. Notice `tools` is
-  obsolete, and currently only `26.1.1` is available, so there's not a lot of
-  options here, however, you can set it as `null` if you don't want it.
+* `toolsVersion`, specifies the version of the tools package to use
 * `platformsToolsVersion` specifies the version of the `platform-tools` plugin
 * `buildToolsVersions` specifies the versions of the `build-tools` plugins to
   use.

doc/languages-frameworks/beam.section.md

@@ -14,7 +14,7 @@ nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/el
 
 All BEAM-related expressions are available via the top-level `beam` attribute, which includes:
 
-- `interpreters`: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (`beam.interpreters.erlang_22`, etc), Elixir (`beam.interpreters.elixir`) and LFE (Lisp Flavoured Erlang) (`beam.interpreters.lfe`).
+- `interpreters`: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (`beam.interpreters.erlangR22`, etc), Elixir (`beam.interpreters.elixir`) and LFE (Lisp Flavoured Erlang) (`beam.interpreters.lfe`).
 
 - `packages`: a set of package builders (Mix and rebar3), each compiled with a specific Erlang/OTP version, e.g. `beam.packages.erlang22`.
 
@@ -22,7 +22,7 @@ The default Erlang compiler, defined by `beam.interpreters.erlang`, is aliased a
 
 To create a package builder built with a custom Erlang version, use the lambda, `beam.packagesWith`, which accepts an Erlang/OTP derivation and produces a package builder similar to `beam.packages.erlang`.
 
-Many Erlang/OTP distributions available in `beam.interpreters` have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's `beam.interpreters.erlang_22_odbc_javac`, which corresponds to `beam.interpreters.erlang_22` and `beam.interpreters.erlang_22_nox`, which corresponds to `beam.interpreters.erlang_22`.
+Many Erlang/OTP distributions available in `beam.interpreters` have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's `beam.interpreters.erlangR22_odbc_javac`, which corresponds to `beam.interpreters.erlangR22` and `beam.interpreters.erlangR22_nox`, which corresponds to `beam.interpreters.erlangR22`.
 
 ## Build Tools {#build-tools}
 
@@ -128,7 +128,7 @@ You will need to run the build process once to fix the hash to correspond to you
 
 ###### FOD {#fixed-output-derivation}
 
-A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [elixir-ls](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/beam-modules/elixir-ls/default.nix) for a usage example of FOD.
+A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [elixir_ls](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/beam-modules/elixir_ls.nix) for a usage example of FOD.
 
 Practical steps
 
@@ -154,7 +154,7 @@ Here is how your `default.nix` file would look for a phoenix project.
 with import <nixpkgs> { };
 
 let
-  # beam.interpreters.erlang_23 is available if you need a particular version
+  # beam.interpreters.erlangR23 is available if you need a particular version
   packages = beam.packagesWith beam.interpreters.erlang;
 
   pname = "your_project";
@@ -171,7 +171,6 @@ let
     inherit src version;
     # nix will complain and tell you the right value to replace this with
     hash = lib.fakeHash;
-    mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".
     # if you have build time environment variables add them here
     MY_ENV_VAR="my_value";
   };
@@ -274,18 +273,18 @@ Usually, we need to create a `shell.nix` file and do our development inside of t
 
 with pkgs;
 let
-  elixir = beam.packages.erlang_24.elixir_1_12;
+  elixir = beam.packages.erlangR24.elixir_1_12;
 in
 mkShell {
   buildInputs = [ elixir ];
 }
 ```
 
-### Using an overlay {#beam-using-overlays}
+### Using an overlay
 
 If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:
 
-#### `shell.nix` {#beam-using-overlays-shell.nix}
+#### `shell.nix`
 
 ```nix
 let

doc/languages-frameworks/chicken.section.md

@@ -4,7 +4,7 @@
 [R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme
 compiler. It includes an interactive mode and a custom package format, "eggs".
 
-## Using Eggs {#sec-chicken-using}
+## Using Eggs
 
 Eggs described in nixpkgs are available inside the
 `chickenPackages.chickenEggs` attrset. Including an egg as a build input is
@@ -22,7 +22,7 @@ might write:
 Both `chicken` and its eggs have a setup hook which configures the environment
 variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
 
-## Updating Eggs {#sec-chicken-updating-eggs}
+## Updating Eggs
 
 nixpkgs only knows about a subset of all published eggs. It uses
 [egg2nix](https://github.com/the-kenny/egg2nix) to generate a
@@ -36,7 +36,7 @@ $ cd pkgs/development/compilers/chicken/5/
 $ egg2nix eggs.scm > eggs.nix
 ```
 
-## Adding Eggs {#sec-chicken-adding-eggs}
+## Adding Eggs
 
 When we run `egg2nix`, we obtain one collection of eggs with
 mutually-compatible versions. This means that when we add new eggs, we may

doc/languages-frameworks/coq.section.md

@@ -37,7 +37,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
 * `buildInputs` (optional), is a list of libraries and dependencies that are required to build and run the current derivation, in addition to the default one `[ coq ]`,
 * `extraBuildInputs` (optional, deprecated), an additional list of derivation to add to `buildInputs`,
 * `overrideBuildInputs` (optional) replaces the default list of derivation to which `buildInputs` and `extraBuildInputs` adds extras elements,
-* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Coq libraries and Coq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environments of subsequent derivation, which is necessary for Coq packages to work correctly,
+* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Coq libraries and Coq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environements of subsequent derivation, which is necessary for Coq packages to work correctly,
 * `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `nativeBuildInputs`, `buildInputs`, and `propagatedBuildInputs` to depend on the same package set Coq was built against.
 * `useDuneifVersion` (optional, default to `(x: false)` uses Dune to build the package if the provided predicate evaluates to true on the version, e.g. `useDuneifVersion = versions.isGe "1.1"`  will use dune if the version of the package is greater or equal to `"1.1"`,
 * `useDune` (optional, defaults to `false`) uses Dune to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.

doc/languages-frameworks/cuelang.section.md

@@ -7,7 +7,7 @@
 - do configuration akin to [Dhall Lang](https://dhall-lang.org/)
 - perform data validation
 
-## Cuelang schema quick start {#cuelang-quickstart}
+## Cuelang schema quick start
 
 Cuelang schemas are similar to JSON, here is a quick cheatsheet:
 
@@ -21,7 +21,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
 - Read <https://cuelang.org/docs/concepts/logic/> to learn more about the semantics.
 - Read <https://cuelang.org/docs/references/spec/> to learn about the language specification.
 
-## `writeCueValidator` {#cuelang-writeCueValidator}
+## `writeCueValidator`
 
 Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
 

doc/languages-frameworks/dotnet.section.md

@@ -11,7 +11,7 @@ with import <nixpkgs> {};
 mkShell {
   name = "dotnet-env";
   packages = [
-    dotnet-sdk
+    dotnet-sdk_3
   ];
 }
 ```
@@ -27,57 +27,36 @@ mkShell {
   name = "dotnet-env";
   packages = [
     (with dotnetCorePackages; combinePackages [
-      sdk_6_0
-      sdk_7_0
+      sdk_3_1
+      sdk_5_0
     ])
   ];
 }
 ```
 
-This will produce a dotnet installation that has the dotnet 6.0 7.0 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
+This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
 
 ```ShellSession
 $ dotnet --info
-.NET SDK:
- Version:   7.0.202
- Commit:    6c74320bc3
+.NET Core SDK (reflecting any global.json):
+ Version:   3.1.101
+ Commit:    b377529961
 
-Środowisko uruchomieniowe:
- OS Name:     nixos
- OS Version:  23.05
- OS Platform: Linux
- RID:         linux-x64
- Base Path:   /nix/store/n2pm44xq20hz7ybsasgmd7p3yh31gnh4-dotnet-sdk-7.0.202/sdk/7.0.202/
+...
 
-Host:
-  Version:      7.0.4
-  Architecture: x64
-  Commit:       0a396acafe
+.NET Core SDKs installed:
+  2.1.803 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
+  3.0.102 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
+  3.1.101 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
 
-.NET SDKs installed:
-  6.0.407 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/sdk]
-  7.0.202 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/sdk]
-
-.NET runtimes installed:
-  Microsoft.AspNetCore.App 6.0.15 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.AspNetCore.App 7.0.4 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.NETCore.App 6.0.15 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-  Microsoft.NETCore.App 7.0.4 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-
-Other architectures found:
-  None
-
-Environment variables:
-  Not set
-
-global.json file:
-  Not found
-
-Learn more:
-  https://aka.ms/dotnet/info
-
-Download .NET:
-  https://aka.ms/dotnet/download
+.NET Core runtimes installed:
+  Microsoft.AspNetCore.All 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.All]
+  Microsoft.AspNetCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.AspNetCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.AspNetCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.NETCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
+  Microsoft.NETCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
+  Microsoft.NETCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
 ```
 
 ## dotnet-sdk vs dotnetCorePackages.sdk {#dotnet-sdk-vs-dotnetcorepackages.sdk}
@@ -109,7 +88,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
 * `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
 * `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on Dotnet.
-* `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-sdk` is useful in cases where you need to change what dotnet SDK is being used.
 * `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.
@@ -140,8 +119,8 @@ in buildDotnetModule rec {
 
   projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
 
-  dotnet-sdk = dotnetCorePackages.sdk_6.0;
-  dotnet-runtime = dotnetCorePackages.runtime_6_0;
+  dotnet-sdk = dotnetCorePackages.sdk_3_1;
+  dotnet-runtime = dotnetCorePackages.net_5_0;
 
   executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
   executables = []; # Don't install any executables.

doc/languages-frameworks/emscripten.section.md

@@ -56,11 +56,11 @@ See the `zlib` example:
 
     zlib = (pkgs.zlib.override {
       stdenv = pkgs.emscriptenStdenv;
-    }).overrideAttrs
+    }).overrideDerivation
     (old: rec {
       buildInputs = old.buildInputs ++ [ pkg-config ];
       # we need to reset this setting!
-      env = (old.env or { }) // { NIX_CFLAGS_COMPILE = ""; };
+      NIX_CFLAGS_COMPILE="";
       configurePhase = ''
         # FIXME: Some tests require writing at $HOME
         HOME=$TMPDIR

doc/languages-frameworks/gnome.section.md

@@ -34,7 +34,7 @@ To allow software to use various virtual file systems, `gvfs` package can be als
 
 ### GdkPixbuf loaders {#ssec-gnome-gdk-pixbuf-loaders}
 
-GTK applications typically use [GdkPixbuf](https://gitlab.gnome.org/GNOME/gdk-pixbuf/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.
+GTK applications typically use [GdkPixbuf](https://developer.gnome.org/gdk-pixbuf/stable/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.
 
 Unlike other libraries mentioned in this section, GdkPixbuf only supports a single value in its controlling environment variable `GDK_PIXBUF_MODULE_FILE`. It is supposed to point to a cache file containing information about the available loaders. Each loader package will contain a `lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` file describing the default loaders in `gdk-pixbuf` package plus the loader contained in the package itself. If you want to use multiple third-party loaders, you will need to create your own cache file manually. Fortunately, this is pretty rare as [not many loaders exist](https://gitlab.gnome.org/federico/gdk-pixbuf-survey/blob/master/src/modules.md).
 
@@ -70,7 +70,7 @@ Also make sure that `icon-theme.cache` is installed for each theme provided by t
 
 ### GTK Themes {#ssec-gnome-themes}
 
-Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://docs.elementary.io/hig)) might require a special theme like `pantheon.elementary-gtk-theme`.
+Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines)) might require a special theme like `pantheon.elementary-gtk-theme`.
 
 ### GObject introspection typelibs {#ssec-gnome-typelibs}
 
@@ -116,6 +116,10 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
 
 - []{#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`.
 
+  ::: {.warning}
+  The setup hook [currently](https://github.com/NixOS/nixpkgs/issues/56943) does not work in expressions with `strictDeps` enabled, like Python packages. In those cases, you will need to disable it with `strictDeps = false;`.
+  :::
+
 - []{#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:

doc/languages-frameworks/go.section.md

@@ -20,7 +20,6 @@ In the following is an example expression using `buildGoModule`, the following a
 
   To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).
 - `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.
-- `modPostBuild`: Shell commands to run after the build of the go-modules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.
 
 ```nix
 pet = buildGoModule rec {
@@ -115,16 +114,7 @@ done
 
 ## Attributes used by the builders {#ssec-go-common-attributes}
 
-Many attributes [controlling the build phase](#variables-controlling-the-build-phase) are respected by both `buildGoModule` and `buildGoPackage`. Note that `buildGoModule` reads the following attributes also when building the `vendor/` go-modules fixed output derivation as well:
-
-- [`sourceRoot`](#var-stdenv-sourceRoot)
-- [`prePatch`](#var-stdenv-prePatch)
-- [`patches`](#var-stdenv-patches)
-- [`patchFlags`](#var-stdenv-patchFlags)
-- [`postPatch`](#var-stdenv-postPatch)
-- [`preBuild`](#var-stdenv-preBuild)
-
-In addition to the above attributes, and the many more variables respected also by `stdenv.mkDerivation`, both `buildGoModule` and `buildGoPackage` respect Go-specific attributes that tweak them to behave slightly differently:
+Both `buildGoModule` and `buildGoPackage` can be tweaked to behave slightly differently, if the following attributes are used:
 
 ### `ldflags` {#var-go-ldflags}
 

doc/languages-frameworks/haskell.section.md

@@ -71,10 +71,8 @@ $ nix-env -f '<nixpkgs>' -qaP -A haskell.compiler
 haskell.compiler.ghc810                  ghc-8.10.7
 haskell.compiler.ghc88                   ghc-8.8.4
 haskell.compiler.ghc90                   ghc-9.0.2
-haskell.compiler.ghc924                  ghc-9.2.4
+haskell.compiler.ghc92                   ghc-9.2.4
 haskell.compiler.ghc925                  ghc-9.2.5
-haskell.compiler.ghc926                  ghc-9.2.6
-haskell.compiler.ghc92                   ghc-9.2.7
 haskell.compiler.ghc942                  ghc-9.4.2
 haskell.compiler.ghc943                  ghc-9.4.3
 haskell.compiler.ghc94                   ghc-9.4.4
@@ -88,15 +86,13 @@ haskell.compiler.ghc924Binary            ghc-binary-9.2.4
 haskell.compiler.ghc924BinaryMinimal     ghc-binary-9.2.4
 haskell.compiler.integer-simple.ghc810   ghc-integer-simple-8.10.7
 haskell.compiler.integer-simple.ghc8107  ghc-integer-simple-8.10.7
-haskell.compiler.integer-simple.ghc88    ghc-integer-simple-8.8.4
 haskell.compiler.integer-simple.ghc884   ghc-integer-simple-8.8.4
+haskell.compiler.integer-simple.ghc88    ghc-integer-simple-8.8.4
 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.ghc92     ghc-native-bignum-9.2.4
 haskell.compiler.native-bignum.ghc924    ghc-native-bignum-9.2.4
 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.ghc92     ghc-native-bignum-9.2.7
-haskell.compiler.native-bignum.ghc927    ghc-native-bignum-9.2.7
 haskell.compiler.native-bignum.ghc942    ghc-native-bignum-9.4.2
 haskell.compiler.native-bignum.ghc943    ghc-native-bignum-9.4.3
 haskell.compiler.native-bignum.ghc94     ghc-native-bignum-9.4.4
@@ -108,16 +104,16 @@ 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.ghc927`:
+9.4.4 is `haskell.packages.ghc944`. In fact `haskellPackages` is just an alias
+for `haskell.packages.ghc924`:
 
 ```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
+$ nix-env -f '<nixpkgs>' -qaP -A haskell.packages.ghc924
+haskell.packages.ghc924.a50                                                         a50-0.5
+haskell.packages.ghc924.AAI                                                         AAI-0.2.0.1
+haskell.packages.ghc924.aasam                                                       aasam-0.2.0.0
+haskell.packages.ghc924.abacate                                                     abacate-0.0.0.0
+haskell.packages.ghc924.abc-puzzle                                                  abc-puzzle-0.2.1
 …
 ```
 
@@ -141,12 +137,7 @@ set the default version to a version older than the newest on Hackage. We do
 this to get them or their reverse dependencies to compile in our package set.
 4. For all packages, for which the newest Hackage version is not the default
 version, there will also be a `haskellPackages.foo_x_y_z` package with the
-newest version. The `x_y_z` part encodes the version with dots replaced by
-underscores. When the newest version changes by a new release to Hackage the
-old package will disappear under that name and be replaced by a newer one under
-the name with the new version. The package name including the version will
-also disappear when the default version e.g. from Stackage catches up with the
-newest version from Hackage.
+newest version.
 5. For some packages, we also manually add other `haskellPackages.foo_x_y_z`
 versions, if they are required for a certain build.
 
@@ -160,7 +151,7 @@ All `haskell.packages.*` package sets use the same package descriptions and the
 of versions by default. There are however GHC version specific override `.nix`
 files to loosen this a bit.
 
-### Dependency resolution {#haskell-dependency-resolution}
+### Dependency resolution
 
 Normally when you build Haskell packages with `cabal-install`, `cabal-install`
 does dependency resolution. It will look at all Haskell package versions known
@@ -170,14 +161,12 @@ given in the `.cabal` file of your package and all its dependencies.
 
 The [Haskell builder in nixpkgs](#haskell-mkderivation) does no such thing.
 It will simply take as input packages with names off the desired dependencies
-and just check whether they fulfill the version bounds and fail if they don’t
-(by default, see `jailbreak` to circumvent this).
+and just check whether they fulfill the version bounds and (by default, see
+`jailbreak`) fail if they don’t.
 
-The `haskellPackages.callPackage` function does the package resolution.
-It will, e.g., use `haskellPackages.aeson`which has the default version as
-described above for a package input of name `aeson`. (More general:
-`<packages>.callPackage f` will call `f` with named inputs provided from the
-package set `<packages>`.)
+The package resolution is done by the `haskellPackages.callPackage` function
+which will, e.g., use `haskellPackages.aeson` for a package input of name
+`aeson`.
 While this is the default behavior, it is possible to override the dependencies
 for a specific package, see
 [`override` and `overrideScope`](#haskell-overriding-haskell-packages).
@@ -206,7 +195,7 @@ maintenance work for `haskellPackages` is required. Besides that, it is not
 possible to get the dependencies of a legacy project from nixpkgs or to use a
 specific stack solver for compiling a project.
 
-Even though we couldn’t use them directly in nixpkgs, it would be desirable
+Even though we couldn‘t use them directly in nixpkgs, it would be desirable
 to have tooling to generate working Nix package sets from build plans generated
 by `cabal-install` or a specific Stackage snapshot via import-from-derivation.
 Sadly we currently don’t have tooling for this. For this you might be
@@ -230,7 +219,7 @@ specification, test suites, benchmarks etc. by compiling and invoking the
 package's `Setup.hs`. It does *not* use or invoke the `cabal-install` binary,
 but uses the underlying `Cabal` library instead.
 
-### General arguments {#haskell-derivation-args}
+### General arguments
 
 `pname`
 : Package name, assumed to be the same as on Hackage (if applicable)
@@ -479,7 +468,7 @@ are especially useful when writing [overrides](#haskell-overriding-haskell-packa
 when you want to make sure that they are definitely included. However, it is
 recommended to use the more accurate ones listed above when possible.
 
-### Meta attributes {#haskell-derivation-meta}
+### Meta attributes
 
 `haskellPackages.mkDerivation` accepts the following attributes as direct
 arguments which are transparently set in `meta` of the resulting derivation. See
@@ -549,7 +538,7 @@ via [`shellFor`](#haskell-shellFor).
 When using `cabal-install` for dependency resolution you need to be a bit
 careful to achieve build purity. `cabal-install` will find and use all
 dependencies installed from the packages `env` via Nix, but it will also
-consult Hackage to potentially download and compile dependencies if it can’t
+consult Hackage to potentially download and compile dependencies if it can‘t
 find a valid build plan locally. To prevent this you can either never run
 `cabal update`, remove the cabal database from your `~/.cabal` folder or run
 `cabal` with `--offline`. Note though, that for some usecases `cabal2nix` needs
@@ -714,7 +703,7 @@ editor plugin to achieve this.
 
 ## Overriding Haskell packages {#haskell-overriding-haskell-packages}
 
-### Overriding a single package {#haskell-overriding-a-single-package}
+### Overriding a single package
 
 <!-- TODO(@sternenseemann): we should document /somewhere/ that base == null etc. -->
 
@@ -803,7 +792,7 @@ lib.pipe my-haskell-package [
 ]
 ```
 
-#### `haskell.lib.compose` {#haskell-haskell.lib.compose}
+#### `haskell.lib.compose`
 
 The base interface for all overriding is the following function:
 
@@ -826,7 +815,7 @@ following overview. Refer to the
 [documentation of `haskellPackages.mkDerivation`](#haskell-mkderivation)
 for a more detailed description of the effects of the respective arguments.
 
-##### Packaging Helpers {#haskell-packaging-helpers}
+##### Packaging Helpers
 
 `overrideSrc { src, version } drv`
 : Replace the source used for building `drv` with the path or derivation given
@@ -875,7 +864,7 @@ sometimes necessary when working with versioned packages in
 altogether. Useful if it fails to evaluate cleanly and is causing
 noise in the evaluation errors tab on Hydra.
 
-##### Development Helpers {#haskell-development-helpers}
+##### Development Helpers
 
 `sdistTarball drv`
 : Create a source distribution tarball like those found on Hackage
@@ -913,7 +902,7 @@ for debugging with e.g. `gdb`.
 
 <!-- TODO(@sternenseemann): shellAware -->
 
-##### Trivial Helpers {#haskell-trivial-helpers}
+##### Trivial Helpers
 
 `doJailbreak drv`
 : Sets the `jailbreak` argument to `true` for `drv`.
@@ -998,7 +987,7 @@ benchmark component.
 `dontCoverage drv`
 : Sets the `doCoverage` argument to `false` for `drv`.
 
-#### Library functions in the Haskell package sets {#haskell-package-set-lib-functions}
+#### Library functions in the Haskell package sets
 
 Some library functions depend on packages from the Haskell package sets. Thus they are
 exposed from those instead of from `haskell.lib.compose` which can only access what is
@@ -1062,7 +1051,7 @@ it does for the unstable branches.
 
 ## F.A.Q. {#haskell-faq}
 
-### Why is topic X not covered in this section? Why is section Y missing? {#haskell-why-not-covered}
+### Why is topic X not covered in this section? Why is section Y missing?
 
 We have been working on [moving the nixpkgs Haskell documentation back into the
 nixpkgs manual](https://github.com/NixOS/nixpkgs/issues/121403). Since this

doc/languages-frameworks/index.xml

@@ -25,7 +25,6 @@
  <xi:include href="ios.section.xml" />
  <xi:include href="java.section.xml" />
  <xi:include href="javascript.section.xml" />
- <xi:include href="lisp.section.xml" />
  <xi:include href="lua.section.xml" />
  <xi:include href="maven.section.xml" />
  <xi:include href="nim.section.xml" />
@@ -33,13 +32,11 @@
  <xi:include href="octave.section.xml" />
  <xi:include href="perl.section.xml" />
  <xi:include href="php.section.xml" />
- <xi:include href="pkg-config.section.xml" />
  <xi:include href="python.section.xml" />
  <xi:include href="qt.section.xml" />
  <xi:include href="r.section.xml" />
  <xi:include href="ruby.section.xml" />
  <xi:include href="rust.section.xml" />
- <xi:include href="swift.section.xml" />
  <xi:include href="texlive.section.xml" />
  <xi:include href="titanium.section.xml" />
  <xi:include href="vim.section.xml" />

doc/languages-frameworks/javascript.section.md

@@ -6,16 +6,16 @@ This contains instructions on how to package javascript applications.
 
 The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
 
-## Getting unstuck / finding code examples {#javascript-finding-examples}
+## Getting unstuck / finding code examples
 
 If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
 
-### Github {#javascript-finding-examples-github}
+### Github
 
 - Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
 - Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
 
-### Gitlab {#javascript-finding-examples-gitlab}
+### Gitlab
 
 - Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
 - Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
@@ -105,7 +105,7 @@ After you have identified the correct system, you need to override your package
     });
 ```
 
-### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
+### Adding and Updating Javascript packages in nixpkgs
 
 To add a package from NPM to nixpkgs:
 
@@ -140,7 +140,7 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script:
 ./pkgs/development/node-packages/generate.sh
 ```
 
-#### Git protocol error {#javascript-git-error}
+#### Git protocol error
 
 Some packages may have Git dependencies from GitHub specified with `git://`.
 GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
@@ -229,7 +229,7 @@ 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` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs-16_x`.
 - `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}
@@ -288,7 +288,7 @@ configurePhase = ''
 This will generate a derivation including the `node_modules` directory.
 If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.
 
-#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}
+#### Overriding dependency behavior
 
 In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
 

doc/languages-frameworks/lisp.section.md

@@ -1,304 +0,0 @@
-# lisp-modules {#lisp}
-
-This document describes the Nixpkgs infrastructure for building Common Lisp
-libraries that use ASDF (Another System Definition Facility). It lives in
-`pkgs/development/lisp-modules`.
-
-## Overview {#lisp-overview}
-
-The main entry point of the API are the Common Lisp implementation packages
-(e.g. `abcl`, `ccl`, `clasp-common-lisp`, `clisp` `ecl`, `sbcl`)
-themselves. They have the `pkgs` and `withPackages` attributes, which can be
-used to discover available packages and to build wrappers, respectively.
-
-The `pkgs` attribute set contains packages that were automatically imported from
-Quicklisp, and any other manually defined ones. Not every package works for all
-the CL implementations (e.g. `nyxt` only makes sense for `sbcl`).
-
-The `withPackages` function is of primary utility. It is used to build runnable
-wrappers, with a pinned and pre-built ASDF FASL available in the `ASDF`
-environment variable, and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS`
-configured to find the desired systems on runtime.
-
-With a few exceptions, the primary thing that the infrastructure does is to run
-`asdf:load-system` for each system specified in the `systems` argument to
-`build-asdf-system`, and save the FASLs to the Nix store. Then, it makes these
-FASLs available to wrappers. Any other use-cases, such as producing SBCL
-executables with `sb-ext:save-lisp-and-die`, are achieved via overriding the
-`buildPhase` etc.
-
-In addition, Lisps have the `withOverrides` function, which can be used to
-substitute any package in the scope of their `pkgs`. This will be useful
-together with `overrideLispAttrs` when dealing with slashy ASDF systems, because
-they should stay in the main package and be build by specifying the `systems`
-argument to `build-asdf-system`.
-
-## The 90% use case example {#lisp-use-case-example}
-
-The most common way to use the library is to run ad-hoc wrappers like this:
-
-`nix-shell -p 'sbcl.withPackages (ps: with ps; [ alexandria ])'`
-
-Then, in a shell:
-
-```
-$ result/bin/sbcl
-* (load (sb-ext:posix-getenv "ASDF"))
-* (asdf:load-system 'alexandria)
-```
-
-Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
-
-```
-let
-  sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
-in mkShell {
-  buildInputs = [ sbcl' ];
-}
-```
-
-Such a Lisp can be now used e.g. to compile your sources:
-
-```
-buildPhase = ''
-  ${sbcl'}/bin/sbcl --load my-build-file.lisp
-''
-```
-
-## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
-
-The library is able to very quickly import all the packages distributed by
-Quicklisp by parsing its `releases.txt` and `systems.txt` files. These files are
-available from [http://beta.quicklisp.org/dist/quicklisp.txt].
-
-The import process is implemented in the `import` directory as Common Lisp
-functions in the `org.lispbuilds.nix` ASDF system. To run the script, one can
-execute `ql-import.lisp`:
-
-```
-nix-shell --run 'sbcl --script ql-import.lisp'
-```
-
-The script will:
-
-1. Download the latest Quicklisp `systems.txt` and `releases.txt` files
-2. Generate an SQLite database of all QL systems in `packages.sqlite`
-3. Generate an `imported.nix` file from the database
-
-The maintainer's job there is to:
-
-1. Re-run the `ql-import.lisp` script
-2. Add missing native dependencies in `ql.nix`
-3. For packages that still don't build, package them manually in `packages.nix`
-
-Also, the `imported.nix` file **must not be edited manually**! It should only be
-generated as described in this section.
-
-### Adding native dependencies {#lisp-quicklisp-adding-native-dependencies}
-
-The Quicklisp files contain ASDF dependency data, but don't include native
-library (CFFI) dependencies, and, in the case of ABCL, Java dependencies.
-
-The `ql.nix` file contains a long list of overrides, where these dependencies
-can be added.
-
-Packages defined in `packages.nix` contain these dependencies naturally.
-
-### Trusting `systems.txt` and `releases.txt` {#lisp-quicklisp-trusting}
-
-The previous implementation of `lisp-modules` didn't fully trust the Quicklisp
-data, because there were times where the dependencies specified were not
-complete, and caused broken builds. It instead used a `nix-shell` environment to
-discover real dependencies by using the ASDF APIs.
-
-The current implementation has chosen to trust this data, because it's faster to
-parse a text file than to build each system to generate its Nix file, and
-because that way packages can be mass-imported. Because of that, there may come
-a day where some packages will break, due to bugs in Quicklisp. In that case,
-the fix could be a manual override in `packages.nix` and `ql.nix`.
-
-A known fact is that Quicklisp doesn't include dependencies on slashy systems in
-its data. This is an example of a situation where such fixes were used, e.g. to
-replace the `systems` attribute of the affected packages. (See the definition of
-`iolib`).
-
-### Quirks {#lisp-quicklisp-quirks}
-
-During Quicklisp import:
-
-- `+` in names are converted to `_plus{_,}`: `cl+ssl`->`cl_plus_ssl`, `alexandria+`->`alexandria_plus`
-- `.` to `_dot_`: `iolib.base`->`iolib_dot_base`
-- names starting with a number have a `_` prepended (`3d-vectors`->`_3d-vectors`)
-- `_` in names is converted to `__` for reversibility
-
-
-## Defining packages manually inside Nixpkgs {#lisp-defining-packages-inside}
-
-New packages, that for some reason are not in Quicklisp, and so cannot be
-auto-imported, can be written in the `packages.nix` file.
-
-In that file, use the `build-asdf-system` function, which is a wrapper around
-`mkDerivation` for building ASDF systems. Various other hacks are present, such
-as `build-with-compile-into-pwd` for systems which create files during
-compilation.
-
-The `build-asdf-system` function is documented with comments in
-`nix-cl.nix`. Also, `packages.nix` is full of examples of how to use it.
-
-## Defining packages manually outside Nixpkgs {#lisp-defining-packages-outside}
-
-Lisp derivations (`abcl`, `sbcl` etc.) also export the `buildASDFSystem`
-function, which is the same as `build-asdf-system`, except for the `lisp`
-argument which is set to the given CL implementation.
-
-It can be used to define packages outside Nixpkgs, and, for example, add them
-into the package scope with `withOverrides` which will be discussed later on.
-
-### Including an external package in scope {#lisp-including-external-pkg-in-scope}
-
-A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
-Nixpkgs-provided scope like this:
-
-```
-let
-  alexandria = sbcl.buildASDFSystem rec {
-    pname = "alexandria";
-    version = "1.4";
-    src = fetchFromGitLab {
-      domain = "gitlab.common-lisp.net";
-      owner = "alexandria";
-      repo = "alexandria";
-      rev = "v${version}";
-      hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-    };
-  };
-  sbcl' = sbcl.withOverrides (self: super: {
-    inherit alexandria;
-  });
-in sbcl'.pkgs.alexandria
-```
-
-## Overriding package attributes {#lisp-overriding-package-attributes}
-
-Packages export the `overrideLispAttrs` function, which can be used to build a
-new package with different parameters.
-
-Example of overriding `alexandria`:
-
-```
-sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
-  version = "1.4";
-  src = fetchFromGitLab {
-    domain = "gitlab.common-lisp.net";
-    owner = "alexandria";
-    repo = "alexandria";
-    rev = "v${version}";
-    hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-  };
-})
-```
-
-## Overriding packages in scope {#lisp-overriding-packages-in-scope}
-
-Packages can be woven into a new scope by using `withOverrides`:
-
-```
-let
-  sbcl' = sbcl.withOverrides (self: super: {
-    alexandria = super.alexandria.overrideLispAttrs (oldAttrs: rec {
-      pname = "alexandria";
-      version = "1.4";
-      src = fetchFromGitLab {
-        domain = "gitlab.common-lisp.net";
-        owner = "alexandria";
-        repo = "alexandria";
-        rev = "v${version}";
-        hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-      };
-    });
-  });
-in builtins.elemAt sbcl'.pkgs.bordeaux-threads.lispLibs 0
-```
-
-### Dealing with slashy systems {#lisp-dealing-with-slashy-systems}
-
-Slashy (secondary) systems should not exist in their own packages! Instead, they
-should be included in the parent package as an extra entry in the `systems`
-argument to the `build-asdf-system`/`buildASDFSystem` functions.
-
-The reason is that ASDF searches for a secondary system in the `.asd` of the
-parent package. Thus, having them separate would cause either one of them not to
-load cleanly, because one will contains FASLs of itself but not the other, and
-vice versa.
-
-To package slashy systems, use `overrideLispAttrs`, like so:
-
-```
-ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
-  systems = oldAttrs.systems ++ [ "alexandria/tests" ];
-  lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
-})
-```
-
-See the respective section on using `withOverrides` for how to weave it back
-into `ecl.pkgs`.
-
-Note that sometimes the slashy systems might not only have more dependencies
-than the main one, but create a circular dependency between `.asd`
-files. Unfortunately, in this case an adhoc solution becomes necessary.
-
-## Building Wrappers {#lisp-building-wrappers}
-
-Wrappers can be built using the `withPackages` function of Common Lisp
-implementations (`abcl`, `ecl`, `sbcl` etc.):
-
-```
-sbcl.withPackages (ps: [ ps.alexandria ps.bordeaux-threads ])
-```
-
-Such a wrapper can then be executed like this:
-
-```
-result/bin/sbcl
-```
-
-### Loading ASDF {#lisp-loading-asdf}
-
-For best results, avoid calling `(require 'asdf)` When using the
-library-generated wrappers.
-
-Use `(load (ext:getenv "ASDF"))` instead, supplying your implementation's way of
-getting an environment variable for `ext:getenv`. This will load the
-(pre-compiled to FASL) Nixpkgs-provided version of ASDF.
-
-### Loading systems {#lisp-loading-systems}
-
-There, you can simply use `asdf:load-system`. This works by setting the right
-values for the `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` environment
-variables, so that systems are found in the Nix store and pre-compiled FASLs are
-loaded.
-
-## Adding a new Lisp {#lisp-adding-a-new-lisp}
-
-The function `wrapLisp` is used to wrap Common Lisp implementations. It adds the
-`pkgs`, `withPackages`, `withOverrides` and `buildASDFSystem` attributes to the
-derivation.
-
-`wrapLisp` takes these arguments:
-
-- `pkg`: the Lisp package
-- `faslExt`: Implementation-specific extension for FASL files
-- `program`: The name of executable file in `${pkg}/bin/` (Default: `pkg.pname`)
-- `flags`: A list of flags to always pass to `program` (Default: `[]`)
-- `asdf`: The ASDF version to use (Default: `pkgs.asdf_3_3`)
-- `packageOverrides`: Package overrides config (Default: `(self: super: {})`)
-
-This example wraps CLISP:
-
-```
-wrapLisp {
-  pkg = clisp;
-  faslExt = "fas";
-  flags = ["-E" "UTF8"];
-}
-```

doc/languages-frameworks/lua.section.md

@@ -129,21 +129,16 @@ Let's present the luarocks way first and the manual one in a second time.
 ### Packaging a library on luarocks {#packaging-a-library-on-luarocks}
 
 [Luarocks.org](https://luarocks.org/) is the main repository of lua packages.
-The site proposes two types of packages, the `rockspec` and the `src.rock`
+The site proposes two types of packages, the rockspec and the src.rock
 (equivalent of a [rockspec](https://github.com/luarocks/luarocks/wiki/Rockspec-format) but with the source).
+These packages can have different build types such as `cmake`, `builtin` etc .
 
-Luarocks-based packages are generated in [pkgs/development/lua-modules/generated-packages.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/generated-packages.nix) from
-the whitelist maintainers/scripts/luarocks-packages.csv and updated by running
-the script
-[maintainers/scripts/update-luarocks-packages](https://github.com/NixOS/nixpkgs/tree/master/maintainers/scripts/update-luarocks-packages):
-
-```sh
-./maintainers/scripts/update-luarocks-packages update
-```
+Luarocks-based packages are generated in pkgs/development/lua-modules/generated-packages.nix from
+the whitelist maintainers/scripts/luarocks-packages.csv and updated by running maintainers/scripts/update-luarocks-packages.
 
 [luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
 The automation only goes so far though and some packages need to be customized.
-These customizations go in [pkgs/development/lua-modules/overrides.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/overrides.nix).
+These customizations go in `pkgs/development/lua-modules/overrides.nix`.
 For instance if the rockspec defines `external_dependencies`, these need to be manually added to the overrides.nix.
 
 You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME`.

doc/languages-frameworks/ocaml.section.md

@@ -38,12 +38,12 @@ Here is a simple package example.
 
 - It uses the `fetchFromGitHub` fetcher to get its source.
 
-- It also accept `duneVersion` parameter (valid value are `"1"`, `"2"`, and
-  `"3"`). The recommended practice it to set only if you don't want the default
-  value and/or it depends on something else like package version. You might see
-  a not-supported argument `useDune2`. The behavior was `useDune2 = true;` =>
-  `duneVersion = "2";` and `useDune2 = false;` => `duneVersion = "1";`. It was
-  used at the time when dune3 didn't existed.
+- `duneVersion = "2"` ensures that Dune version 2 is used for the
+  build (this is the default; valid values are `"1"`, `"2"`, and `"3"`);
+  note that there is also a legacy `useDune2` boolean attribute:
+  set to `false` it corresponds to `duneVersion = "1"`; set to `true` it
+  corresponds to `duneVersion = "2"`. If both arguments (`duneVersion` and
+  `useDune2`) are given, the second one (`useDune2`) is silently ignored.
 
 - It sets the optional `doCheck` attribute such that tests will be run with
   `dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
@@ -71,6 +71,7 @@ Here is a simple package example.
 buildDunePackage rec {
   pname = "angstrom";
   version = "0.15.0";
+  duneVersion = "2";
 
   minimalOCamlVersion = "4.04";
 
@@ -103,6 +104,8 @@ buildDunePackage rec {
   pname = "wtf8";
   version = "1.0.2";
 
+  useDune2 = true;
+
   minimalOCamlVersion = "4.02";
 
   src = fetchurl {
@@ -126,8 +129,3 @@ 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
-behavior.

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

@@ -1,51 +0,0 @@
-# pkg-config {#sec-pkg-config}
-
-*pkg-config* is a unified interface for declaring and querying built C/C++ libraries.
-
-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.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 zlib:
-
-```
-{ pkg-config, testers, ... }:
-
-stdenv.mkDerivation (finalAttrs: {
-  ...
-
-  nativeBuildInputs = [ pkg-config validatePkgConfig ];
-
-  passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
-
-  meta = {
-    ...
-    pkgConfigModules = [ "zlib" ];
-  };
-})
-```
-
-## Accessing packages via pkg-config module name {#sec-pkg-config-usage}
-
-### Within Nixpkgs {#sec-pkg-config-usage-internal}
-
-A [setup hook](#setup-hook-pkg-config) is bundled in the `pkg-config` package to bring a derivation's declared build inputs into the environment.
-This will populate environment variables like `PKG_CONFIG_PATH`, `PKG_CONFIG_PATH_FOR_BUILD`, and `PKG_CONFIG_PATH_HOST` based on:
-
- - how `pkg-config` itself is depended upon
-
- - how other dependencies are depended upon
-
-For more details see the section on [specifying dependencies in general](#ssec-stdenv-dependencies).
-
-Normal pkg-config commands to look up dependencies by name will then work with those environment variables defined by the hook.
-
-### Externally {#sec-pkg-config-usage-external}
-
-The `defaultPkgConfigPackages` package set is a set of aliases, named after the modules they provide.
-This is meant to be used by language-to-nix integrations.
-Hand-written packages should use the normal Nixpkgs attribute name instead.

doc/languages-frameworks/python.section.md

@@ -58,7 +58,7 @@ with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create
 a re-usable environment in a single-file Python script; then we will create a
 full Python environment for development with this same environment.
 
-Philosophically, this should be familiar to users who are used to a `venv` style
+Philosphically, this should be familiar to users who are used to a `venv` style
 of development: individual projects create their own Python environments without
 impacting the global environment or each other.
 
@@ -436,7 +436,7 @@ arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If
 something is exclusively a build-time dependency, then the dependency should be
 included in `buildInputs`, but if it is (also) a runtime dependency, then it
 should be added to `propagatedBuildInputs`. Test dependencies are considered
-build-time dependencies and passed to `nativeCheckInputs`.
+build-time dependencies and passed to `checkInputs`.
 
 The following example shows which arguments are given to `buildPythonPackage` in
 order to build [`datashape`](https://github.com/blaze/datashape).
@@ -453,7 +453,7 @@ buildPythonPackage rec {
     hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
   };
 
-  nativeCheckInputs = [ pytest ];
+  checkInputs = [ pytest ];
   propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];
 
   meta = with lib; {
@@ -466,7 +466,7 @@ buildPythonPackage rec {
 ```
 
 We can see several runtime dependencies, `numpy`, `multipledispatch`, and
-`python-dateutil`. Furthermore, we have one `nativeCheckInputs`, i.e. `pytest`. `pytest` is a
+`python-dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a
 test runner and is only used during the `checkPhase` and is therefore not added
 to `propagatedBuildInputs`.
 
@@ -569,7 +569,7 @@ Pytest is the most common test runner for python repositories. A trivial
 test run would be:
 
 ```
-  nativeCheckInputs = [ pytest ];
+  checkInputs = [ pytest ];
   checkPhase = ''
     runHook preCheck
 
@@ -585,7 +585,7 @@ sandbox, and will generally need many tests to be disabled.
 To filter tests using pytest, one can do the following:
 
 ```
-  nativeCheckInputs = [ pytest ];
+  checkInputs = [ pytest ];
   # avoid tests which need additional data or touch network
   checkPhase = ''
     runHook preCheck
@@ -618,7 +618,7 @@ when a package may need many items disabled to run the test suite.
 Using the example above, the analogous `pytestCheckHook` usage would be:
 
 ```
-  nativeCheckInputs = [ pytestCheckHook ];
+  checkInputs = [ pytestCheckHook ];
 
   # requires additional data
   pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
@@ -744,17 +744,17 @@ work in any of the formats supported by `buildPythonPackage` currently,
 with the exception of `other` (see `format` in
 [`buildPythonPackage` parameters](#buildpythonpackage-parameters) for more details).
 
-#### Using unittestCheckHook {#using-unittestcheckhook}
+### Using unittestCheckHook {#using-unittestcheckhook}
 
 `unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:
 
 ```
-  nativeCheckInputs = [ unittestCheckHook ];
+  checkInputs = [ unittestCheckHook ];
 
-  unittestFlagsArray = [ "-s" "tests" "-v" ];
+  unittestFlags = [ "-s" "tests" "-v" ];
 ```
 
-#### Using sphinxHook {#using-sphinxhook}
+##### Using sphinxHook {#using-sphinxhook}
 
 The `sphinxHook` is a helpful tool to build documentation and manpages
 using the popular Sphinx documentation generator.
@@ -1006,7 +1006,7 @@ buildPythonPackage rec {
     rm testing/test_argcomplete.py
   '';
 
-  nativeCheckInputs = [ hypothesis ];
+  checkInputs = [ hypothesis ];
   nativeBuildInputs = [ setuptools-scm ];
   propagatedBuildInputs = [ attrs py setuptools six pluggy ];
 
@@ -1019,7 +1019,7 @@ buildPythonPackage rec {
 
 The `buildPythonPackage` mainly does four things:
 
-* In the `buildPhase`, it calls `${python.pythonForBuild.interpreter} setup.py bdist_wheel` to
+* In the `buildPhase`, it calls `${python.interpreter} setup.py bdist_wheel` to
   build a wheel binary zipfile.
 * In the `installPhase`, it installs the wheel file using `pip install *.whl`.
 * In the `postFixup` phase, the `wrapPythonPrograms` bash function is called to
@@ -1028,7 +1028,7 @@ The `buildPythonPackage` mainly does four things:
 * In the `installCheck` phase, `${python.interpreter} setup.py test` is run.
 
 By default tests are run because `doCheck = true`. Test dependencies, like
-e.g. the test runner, should be added to `nativeCheckInputs`.
+e.g. the test runner, should be added to `checkInputs`.
 
 By default `meta.platforms` is set to the same value
 as the interpreter unless overridden otherwise.
@@ -1082,7 +1082,7 @@ because their behaviour is different:
 * `buildInputs ? []`: Build and/or run-time dependencies that need to be
   compiled for the host machine. Typically non-Python libraries which are being
   linked.
-* `nativeCheckInputs ? []`: Dependencies needed for running the `checkPhase`. These
+* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These
   are added to `nativeBuildInputs` when `doCheck = true`. Items listed in
   `tests_require` go here.
 * `propagatedBuildInputs ? []`: Aside from propagating dependencies,
@@ -1117,7 +1117,7 @@ with import <nixpkgs> {};
 in python.withPackages(ps: [ps.blaze])).env
 ```
 
-#### Optional extra dependencies {#python-optional-dependencies}
+#### Optional extra dependencies
 
 Some packages define optional dependencies for additional features. With
 `setuptools` this is called `extras_require` and `flit` calls it
@@ -1416,7 +1416,7 @@ example of such a situation is when `py.test` is used.
   buildPythonPackage {
     # ...
     # assumes the tests are located in tests
-    nativeCheckInputs = [ pytest ];
+    checkInputs = [ pytest ];
     checkPhase = ''
       runHook preCheck
 
@@ -1546,7 +1546,7 @@ of such package using the feature is `pkgs/tools/X11/xpra/default.nix`.
 As workaround install it as an extra `preInstall` step:
 
 ```shell
-${python.pythonForBuild.interpreter} setup.py install_data --install-dir=$out --root=$out
+${python.interpreter} setup.py install_data --install-dir=$out --root=$out
 sed -i '/ = data\_files/d' setup.py
 ```
 
@@ -1768,7 +1768,7 @@ In a `setup.py` or `setup.cfg` it is common to declare dependencies:
 
 * `setup_requires` corresponds to `nativeBuildInputs`
 * `install_requires` corresponds to `propagatedBuildInputs`
-* `tests_require` corresponds to `nativeCheckInputs`
+* `tests_require` corresponds to `checkInputs`
 
 ## Contributing {#contributing}
 
@@ -1801,14 +1801,14 @@ The following rules are desired to be respected:
 * Attribute names in `python-packages.nix` should be sorted alphanumerically to
   avoid merge conflicts and ease locating attributes.
 
-## Package set maintenance {#python-package-set-maintenance}
+## Package set maintenance
 
 The whole Python package set has a lot of packages that do not see regular
 updates, because they either are a very fragile component in the Python
 ecosystem, like for example the `hypothesis` package, or packages that have
 no maintainer, so maintenance falls back to the package set maintainers.
 
-### Updating packages in bulk {#python-package-bulk-updates}
+### Updating packages in bulk
 
 There is a tool to update alot of python libraries in bulk, it exists at
 `maintainers/scripts/update-python-libraries` with this repository.
@@ -1821,11 +1821,6 @@ hosted on GitHub, exporting a `GITHUB_API_TOKEN` is highly recommended.
 Updating packages in bulk leads to lots of breakages, which is why a
 stabilization period on the `python-unstable` branch is required.
 
-If a package is fragile and often breaks during these bulks updates, it
-may be reasonable to set `passthru.skipBulkUpdate = true` in the
-derivation. This decision should not be made on a whim and should
-always be supported by a qualifying comment.
-
 Once the branch is sufficiently stable it should normally be merged
 into the `staging` branch.
 
@@ -1836,7 +1831,7 @@ would be:
 $ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix
 ```
 
-## CPython Update Schedule {#python-cpython-update-schedule}
+## CPython Update Schedule
 
 With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now
 follows a yearly release cadence. In nixpkgs, all supported interpreters

doc/languages-frameworks/ruby.section.md

@@ -201,7 +201,7 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
 
 Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
 
-### Platform-specific gems {#ruby-platform-specif-gems}
+### Platform-specific gems
 
 Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).
 Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:

doc/languages-frameworks/rust.section.md

@@ -13,7 +13,7 @@ into your `configuration.nix` or bring them into scope with `nix-shell -p rustc
 
 For other versions such as daily builds (beta and nightly),
 use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
-or use [community maintained Rust toolchains](#using-community-maintained-rust-toolchains).
+or use a community maintained [Rust overlay](#using-community-rust-overlays).
 
 ## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
 
@@ -50,11 +50,6 @@ package. `cargoHash256` is used for traditional Nix SHA-256 hashes,
 such as the one in the example above. `cargoHash` should instead be
 used for [SRI](https://www.w3.org/TR/SRI/) hashes. For example:
 
-Exception: If the application has cargo `git` dependencies, the `cargoHash`/`cargoSha256`
-approach will not work, and you will need to copy the `Cargo.lock` file of the application
-to nixpkgs and continue with the next section for specifying the options of the`cargoLock`
-section.
-
 ```nix
   cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
 ```
@@ -162,7 +157,7 @@ required to build a rust package. A simple fix is to use:
 
 ```nix
 postPatch = ''
-  ln -s ${./Cargo.lock} Cargo.lock
+  cp ${./Cargo.lock} Cargo.lock
 '';
 ```
 
@@ -416,13 +411,13 @@ rustPlatform.buildRustPackage rec {
 }
 ```
 
-### Compiling non-Rust packages that include Rust code {#compiling-non-rust-packages-that-include-rust-code}
+## Compiling non-Rust packages that include Rust code {#compiling-non-rust-packages-that-include-rust-code}
 
 Several non-Rust packages incorporate Rust code for performance- or
 security-sensitive parts. `rustPlatform` exposes several functions and
 hooks that can be used to integrate Cargo in non-Rust packages.
 
-#### Vendoring of dependencies {#vendoring-of-dependencies}
+### Vendoring of dependencies {#vendoring-of-dependencies}
 
 Since network access is not allowed in sandboxed builds, Rust crate
 dependencies need to be retrieved using a fetcher. `rustPlatform`
@@ -482,7 +477,7 @@ added. To find the correct hash, you can first use `lib.fakeSha256` or
 `lib.fakeHash` as a stub hash. Building `cargoDeps` will then inform
 you of the correct hash.
 
-#### Hooks {#hooks}
+### Hooks {#hooks}
 
 `rustPlatform` provides the following hooks to automate Cargo builds:
 
@@ -518,7 +513,7 @@ you of the correct hash.
 * `bindgenHook`: for crates which use `bindgen` as a build dependency, lets
   `bindgen` find `libclang` and `libclang` find the libraries in `buildInputs`.
 
-#### Examples {#examples}
+### Examples {#examples}
 
 #### Python package using `setuptools-rust` {#python-package-using-setuptools-rust}
 
@@ -647,127 +642,7 @@ buildPythonPackage rec {
 }
 ```
 
-## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
-
-### Simple operation {#simple-operation}
-
-When run, `cargo build` produces a file called `Cargo.lock`,
-containing pinned versions of all dependencies. Nixpkgs contains a
-tool called `crate2Nix` (`nix-shell -p crate2nix`), which can be
-used to turn a `Cargo.lock` into a Nix expression.  That Nix
-expression calls `rustc` directly (hence bypassing Cargo), and can
-be used to compile a crate and all its dependencies.
-
-See [`crate2nix`'s documentation](https://github.com/kolloch/crate2nix#known-restrictions)
-for instructions on how to use it.
-
-### Handling external dependencies {#handling-external-dependencies}
-
-Some crates require external libraries. For crates from
-[crates.io](https://crates.io), such libraries can be specified in
-`defaultCrateOverrides` package in nixpkgs itself.
-
-Starting from that file, one can add more overrides, to add features
-or build inputs by overriding the hello crate in a separate file.
-
-```nix
-with import <nixpkgs> {};
-((import ./hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    hello = attrs: { buildInputs = [ openssl ]; };
-  };
-}
-```
-
-Here, `crateOverrides` is expected to be a attribute set, where the
-key is the crate name without version number and the value a function.
-The function gets all attributes passed to `buildRustCrate` as first
-argument and returns a set that contains all attribute that should be
-overwritten.
-
-For more complicated cases, such as when parts of the crate's
-derivation depend on the crate's version, the `attrs` argument of
-the override above can be read, as in the following example, which
-patches the derivation:
-
-```nix
-with import <nixpkgs> {};
-((import ./hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0")  {
-      postPatch = ''
-        substituteInPlace lib/zoneinfo.rs \
-          --replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
-      '';
-    };
-  };
-}
-```
-
-Another situation is when we want to override a nested
-dependency. This actually works in the exact same way, since the
-`crateOverrides` parameter is forwarded to the crate's
-dependencies. For instance, to override the build inputs for crate
-`libc` in the example above, where `libc` is a dependency of the main
-crate, we could do:
-
-```nix
-with import <nixpkgs> {};
-((import hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    libc = attrs: { buildInputs = []; };
-  };
-}
-```
-
-### Options and phases configuration {#options-and-phases-configuration}
-
-Actually, the overrides introduced in the previous section are more
-general. A number of other parameters can be overridden:
-
-- The version of `rustc` used to compile the crate:
-
-  ```nix
-  (hello {}).override { rust = pkgs.rust; };
-  ```
-
-- Whether to build in release mode or debug mode (release mode by
-  default):
-
-  ```nix
-  (hello {}).override { release = false; };
-  ```
-
-- Whether to print the commands sent to `rustc` when building
-  (equivalent to `--verbose` in cargo:
-
-  ```nix
-  (hello {}).override { verbose = false; };
-  ```
-
-- Extra arguments to be passed to `rustc`:
-
-  ```nix
-  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
-  ```
-
-- Phases, just like in any other derivation, can be specified using
-  the following attributes: `preUnpack`, `postUnpack`, `prePatch`,
-  `patches`, `postPatch`, `preConfigure` (in the case of a Rust crate,
-  this is run before calling the "build" script), `postConfigure`
-  (after the "build" script),`preBuild`, `postBuild`, `preInstall` and
-  `postInstall`. As an example, here is how to create a new module
-  before running the build script:
-
-  ```nix
-  (hello {}).override {
-    preConfigure = ''
-       echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
-    '';
-  };
-  ```
-
-### Setting Up `nix-shell` {#setting-up-nix-shell}
+## Setting Up `nix-shell` {#setting-up-nix-shell}
 
 Oftentimes you want to develop code from within `nix-shell`. Unfortunately
 `buildRustCrate` does not support common `nix-shell` operations directly
@@ -811,61 +686,31 @@ $ cargo build
 $ cargo test
 ```
 
-## Using community maintained Rust toolchains {#using-community-maintained-rust-toolchains}
+### Controlling Rust Version Inside `nix-shell` {#controlling-rust-version-inside-nix-shell}
 
-::: {.note}
-Note: The following projects cannot be used within nixpkgs since [IFD](#ssec-import-from-derivation) is disallowed.
-To package things that require Rust nightly, `RUSTC_BOOTSTRAP = true;` can sometimes be used as a hack.
-:::
-
-There are two community maintained approaches to Rust toolchain management:
-- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
-- [fenix](https://github.com/nix-community/fenix)
-
-Despite their names, both projects provides a similar set of packages and overlays under different APIs.
-
-Oxalica's overlay allows you to select a particular Rust version without you providing a hash or a flake input,
-but comes with a larger git repository than fenix.
-
-Fenix also provides rust-analyzer nightly in addition to the Rust toolchains.
-
-Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
-Because of this and ergonomics, either of those community projects
-should be preferred to the Mozilla's Rust overlay ([nixpkgs-mozilla](https://github.com/mozilla/nixpkgs-mozilla)).
-
-The following documentation demonstrates examples using fenix and oxalica's Rust overlay
-with `nix-shell` and building derivations. More advanced usages like flake usage
-are documented in their own repositories.
-
-### Using Rust nightly with `nix-shell` {#using-rust-nightly-with-nix-shell}
-
-Here is a simple `shell.nix` that provides Rust nightly (default profile) using fenix:
+To control your rust version (i.e. use nightly) from within `shell.nix` (or
+other nix expressions) you can use the following `shell.nix`
 
 ```nix
-with import <nixpkgs> { };
-let
-  fenix = callPackage
-    (fetchFromGitHub {
-      owner = "nix-community";
-      repo = "fenix";
-      # commit from: 2023-03-03
-      rev = "e2ea04982b892263c4d939f1cc3bf60a9c4deaa1";
-      hash = "sha256-AsOim1A8KKtMWIxG+lXh5Q4P2bhOZjoUhFWJ1EuZNNk=";
-    })
-    { };
+# Latest Nightly
+with import <nixpkgs> {};
+let src = fetchFromGitHub {
+      owner = "mozilla";
+      repo = "nixpkgs-mozilla";
+      # commit from: 2019-05-15
+      rev = "9f35c4b09fd44a77227e79ff0c1b4b6a69dff533";
+      hash = "sha256-18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0=";
+   };
 in
-mkShell {
+with import "${src.out}/rust-overlay.nix" pkgs pkgs;
+stdenv.mkDerivation {
   name = "rust-env";
-  nativeBuildInputs = [
-    # Note: to use stable, just replace `default` with `stable`
-    fenix.default.toolchain
-
-    # Example Build-time Additional Dependencies
-    pkg-config
-  ];
   buildInputs = [
-    # Example Run-time Additional Dependencies
-    openssl
+    # Note: to use stable, just replace `nightly` with `stable`
+    latest.rustChannels.nightly.rust
+
+    # Add some extra dependencies from `pkgs`
+    pkg-config openssl
   ];
 
   # Set Environment Variables
@@ -873,66 +718,116 @@ mkShell {
 }
 ```
 
-Save this to `shell.nix`, then run:
+Now run:
 
 ```ShellSession
 $ rustc --version
-rustc 1.69.0-nightly (13471d3b2 2023-03-02)
+rustc 1.26.0-nightly (188e693b3 2018-03-26)
 ```
 
 To see that you are using nightly.
 
-Oxalica's Rust overlay has more complete examples of `shell.nix` (and cross compilation) under its
-[`examples` directory](https://github.com/oxalica/rust-overlay/tree/e53e8853aa7b0688bc270e9e6a681d22e01cf299/examples).
+## Using community Rust overlays {#using-community-rust-overlays}
 
-### Using Rust nightly in a derivation with `buildRustPackage` {#using-rust-nightly-in-a-derivation-with-buildrustpackage}
+There are two community maintained approaches to Rust toolchain management:
+- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
+- [fenix](https://github.com/nix-community/fenix)
 
-You can also use Rust nightly to build rust packages using `makeRustPlatform`.
-The below snippet demonstrates invoking `buildRustPackage` with a Rust toolchain from oxalica's overlay:
+Oxalica's overlay allows you to select a particular Rust version and components.
+See [their documentation](https://github.com/oxalica/rust-overlay#rust-overlay) for more
+detailed usage.
 
+Fenix is an alternative to `rustup` and can also be used as an overlay.
+
+Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
+Because of this and ergonomics, either of those community projects
+should be preferred to the Mozilla's Rust overlay (`nixpkgs-mozilla`).
+
+### How to select a specific `rustc` and toolchain version {#how-to-select-a-specific-rustc-and-toolchain-version}
+
+You can consume the oxalica overlay and use it to grab a specific Rust toolchain version.
+Here is an example `shell.nix` showing how to grab the current stable toolchain:
 ```nix
-with import <nixpkgs>
-{
+{ pkgs ? import <nixpkgs> {
+    overlays = [
+      (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
+    ];
+  }
+}:
+pkgs.mkShell {
+  nativeBuildInputs = with pkgs; [
+    pkg-config
+    rust-bin.stable.latest.minimal
+  ];
+}
+```
+
+You can try this out by:
+1. Saving that to `shell.nix`
+2. Executing `nix-shell --pure --command 'rustc --version'`
+
+As of writing, this prints out `rustc 1.56.0 (09c42c458 2021-10-18)`.
+
+### How to use an overlay toolchain in a derivation  {#how-to-use-an-overlay-toolchain-in-a-derivation}
+
+You can also use an overlay's Rust toolchain with `buildRustPackage`.
+The below snippet demonstrates invoking `buildRustPackage` with an oxalica overlay selected Rust toolchain:
+```nix
+with import <nixpkgs> {
   overlays = [
     (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
   ];
 };
-let
-  rustPlatform = makeRustPlatform {
-    cargo = rust-bin.stable.latest.minimal;
-    rustc = rust-bin.stable.latest.minimal;
-  };
-in
 
 rustPlatform.buildRustPackage rec {
   pname = "ripgrep";
   version = "12.1.1";
+  nativeBuildInputs = [
+    rust-bin.stable.latest.minimal
+  ];
 
   src = fetchFromGitHub {
     owner = "BurntSushi";
     repo = "ripgrep";
     rev = version;
-    hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
+    hash = "sha256-1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps=";
   };
 
-  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
-
-  doCheck = false;
+  cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
 
   meta = with lib; {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
-    license = with licenses; [ mit unlicense ];
-    maintainers = with maintainers; [ tailhook ];
+    license = licenses.unlicense;
+    maintainers = [ maintainers.tailhook ];
   };
 }
 ```
 
 Follow the below steps to try that snippet.
+1. create a new directory
 1. save the above snippet as `default.nix` in that directory
-2. cd into that directory and run `nix-build`
+1. cd into that directory and run `nix-build`
 
-Fenix also has examples with `buildRustPackage`,
-[crane](https://github.com/ipetkov/crane),
-[naersk](https://github.com/nix-community/naersk),
-and cross compilation in its [Examples](https://github.com/nix-community/fenix#examples) section.
+### Rust overlay installation {#rust-overlay-installation}
+
+You can use this overlay by either changing your local nixpkgs configuration,
+or by adding the overlay declaratively in a nix expression,  e.g. in `configuration.nix`.
+For more information see [the manual on installing overlays](#sec-overlays-install).
+
+### Declarative Rust overlay installation {#declarative-rust-overlay-installation}
+
+This snippet shows how to use oxalica's Rust overlay.
+Add the following to your `configuration.nix`, `home-configuration.nix`, `shell.nix`, or similar:
+
+```nix
+{ pkgs ? import <nixpkgs> {
+    overlays = [
+      (import (builtins.fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
+      # Further overlays go here
+    ];
+  };
+};
+```
+
+Note that this will fetch the latest overlay version when rebuilding your system.

doc/languages-frameworks/swift.section.md

@@ -1,176 +0,0 @@
-# Swift {#swift}
-
-The Swift compiler is provided by the `swift` package:
-
-```sh
-# Compile and link a simple executable.
-nix-shell -p swift --run 'swiftc -' <<< 'print("Hello world!")'
-# Run it!
-./main
-```
-
-The `swift` package also provides the `swift` command, with some caveats:
-
-- Swift Package Manager (SwiftPM) is packaged separately as `swiftpm`. If you
-  need functionality like `swift build`, `swift run`, `swift test`, you must
-  also add the `swiftpm` package to your closure.
-- On Darwin, the `swift repl` command requires an Xcode installation. This is
-  because it uses the system LLDB debugserver, which has special entitlements.
-
-## Module search paths {#ssec-swift-module-search-paths}
-
-Like other toolchains in Nixpkgs, the Swift compiler executables are wrapped
-to help Swift find your application's dependencies in the Nix store. These
-wrappers scan the `buildInputs` of your package derivation for specific
-directories where Swift modules are placed by convention, and automatically
-add those directories to the Swift compiler search paths.
-
-Swift follows different conventions depending on the platform. The wrappers
-look for the following directories:
-
-- On Darwin platforms: `lib/swift/macosx`
-  (If not targeting macOS, replace `macosx` with the Xcode platform name.)
-- On other platforms: `lib/swift/linux/x86_64`
-  (Where `linux` and `x86_64` are from lowercase `uname -sm`.)
-- For convenience, Nixpkgs also adds simply `lib/swift` to the search path.
-  This can save a bit of work packaging Swift modules, because many Nix builds
-  will produce output for just one target any way.
-
-## Core libraries {#ssec-swift-core-libraries}
-
-In addition to the standard library, the Swift toolchain contains some
-additional 'core libraries' that, on Apple platforms, are normally distributed
-as part of the OS or Xcode. These are packaged separately in Nixpkgs, and can
-be found (for use in `buildInputs`) as:
-
-- `swiftPackages.Dispatch`
-- `swiftPackages.Foundation`
-- `swiftPackages.XCTest`
-
-## Packaging with SwiftPM {#ssec-swift-packaging-with-swiftpm}
-
-Nixpkgs includes a small helper `swiftpm2nix` that can fetch your SwiftPM
-dependencies for you, when you need to write a Nix expression to package your
-application.
-
-The first step is to run the generator:
-
-```sh
-cd /path/to/my/project
-# Enter a Nix shell with the required tools.
-nix-shell -p swift swiftpm swiftpm2nix
-# First, make sure the workspace is up-to-date.
-swift package resolve
-# Now generate the Nix code.
-swiftpm2nix
-```
-
-This produces some files in a directory `nix`, which will be part of your Nix
-expression. The next step is to write that expression:
-
-```nix
-{ stdenv, swift, swiftpm, swiftpm2nix, fetchFromGitHub }:
-
-let
-  # Pass the generated files to the helper.
-  generated = swiftpm2nix.helpers ./nix;
-in
-
-stdenv.mkDerivation rec {
-  pname = "myproject";
-  version = "0.0.0";
-
-  src = fetchFromGitHub {
-    owner = "nixos";
-    repo = pname;
-    rev = version;
-    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
-  };
-
-  # Including SwiftPM as a nativeBuildInput provides a buildPhase for you.
-  # This by default performs a release build using SwiftPM, essentially:
-  #   swift build -c release
-  nativeBuildInputs = [ swift swiftpm ];
-
-  # The helper provides a configure snippet that will prepare all dependencies
-  # in the correct place, where SwiftPM expects them.
-  configurePhase = generated.configure;
-
-  installPhase = ''
-    # This is a special function that invokes swiftpm to find the location
-    # of the binaries it produced.
-    binPath="$(swiftpmBinPath)"
-    # Now perform any installation steps.
-    mkdir -p $out/bin
-    cp $binPath/myproject $out/bin/
-  '';
-}
-```
-
-### Custom build flags {#ssec-swiftpm-custom-build-flags}
-
-If you'd like to build a different configuration than `release`:
-
-```nix
-swiftpmBuildConfig = "debug";
-```
-
-It is also possible to provide additional flags to `swift build`:
-
-```nix
-swiftpmFlags = [ "--disable-dead-strip" ];
-```
-
-The default `buildPhase` already passes `-j` for parallel building.
-
-If these two customization options are insufficient, simply provide your own
-`buildPhase` that invokes `swift build`.
-
-### Running tests {#ssec-swiftpm-running-tests}
-
-Including `swiftpm` in your `nativeBuildInputs` also provides a default
-`checkPhase`, but it must be enabled with:
-
-```nix
-doCheck = true;
-```
-
-This essentially runs: `swift test -c release`
-
-### Patching dependencies {#ssec-swiftpm-patching-dependencies}
-
-In some cases, it may be necessary to patch a SwiftPM dependency. SwiftPM
-dependencies are located in `.build/checkouts`, but the `swiftpm2nix` helper
-provides these as symlinks to read-only `/nix/store` paths. In order to patch
-them, we need to make them writable.
-
-A special function `swiftpmMakeMutable` is available to replace the symlink
-with a writable copy:
-
-```
-configurePhase = generated.configure ++ ''
-  # Replace the dependency symlink with a writable copy.
-  swiftpmMakeMutable swift-crypto
-  # Now apply a patch.
-  patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
-'';
-```
-
-## Considerations for custom build tools {#ssec-swift-considerations-for-custom-build-tools}
-
-### Linking the standard library {#ssec-swift-linking-the-standard-library}
-
-The `swift` package has a separate `lib` output containing just the Swift
-standard library, to prevent Swift applications needing a dependency on the
-full Swift compiler at run-time. Linking with the Nixpkgs Swift toolchain
-already ensures binaries correctly reference the `lib` output.
-
-Sometimes, Swift is used only to compile part of a mixed codebase, and the
-link step is manual. Custom build tools often locate the standard library
-relative to the `swift` compiler executable, and while the result will work,
-when this path ends up in the binary, it will have the Swift compiler as an
-unintended dependency.
-
-In this case, you should investigate how your build process discovers the
-standard library, and override the path. The correct path will be something
-like: `"${swift.swift.lib}/${swift.swiftModuleSubdir}"`

doc/languages-frameworks/texlive.section.md

@@ -40,24 +40,17 @@ Since release 15.09 there is a new TeX Live packaging that lives entirely under
 
 ## Custom packages {#sec-language-texlive-custom-packages}
 
-You may find that you need to use an external TeX package. A derivation for such package has to provide the contents of the "texmf" directory in its output and provide the appropriate `tlType` attribute (one of `"run"`, `"bin"`, `"doc"`, `"source"`). Dependencies on other TeX packages can be listed in the attribute `tlDeps`.
 
-Such derivation must then be listed in the attribute `pkgs` of an attribute set passed to `texlive.combine`, for instance by passing `extraPkgs = { pkgs = [ custom_package ]; };`. Within Nixpkgs, `pkgs` should be part of the derivation itself, allowing users to call `texlive.combine { inherit (texlive) scheme-small; inherit some_tex_package; }`.
-
-Here is a (very verbose) example where the attribute `pkgs` is attached to the derivation itself, which requires creating a fixed point. See also the packages `auctex`, `eukleides`, `mftrace` for more examples.
+You may find that you need to use an external TeX package. A derivation for such package has to provide contents of the "texmf" directory in its output and provide the `tlType` attribute. Here is a (very verbose) example:
 
 ```nix
 with import <nixpkgs> {};
 
 let
-  foiltex = stdenvNoCC.mkDerivation (finalAttrs: {
+  foiltex_run = stdenvNoCC.mkDerivation {
     pname = "latex-foiltex";
     version = "2.1.4b";
-    passthru = {
-      pkgs = [ finalAttrs.finalPackage ];
-      tlDeps = with texlive; [ latex ];
-      tlType = "run";
-    };
+    passthru.tlType = "run";
 
     srcs = [
       (fetchurl {
@@ -109,7 +102,8 @@ let
       maintainers = with maintainers; [ veprbl ];
       platforms = platforms.all;
     };
-  });
+  };
+  foiltex = { pkgs = [ foiltex_run ]; };
 
   latex_with_foiltex = texlive.combine {
     inherit (texlive) scheme-small;

doc/languages-frameworks/vim.section.md

@@ -166,8 +166,8 @@ in
 
 If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`.
 
-### Specificities for some plugins {#vim-plugin-specificities}
-#### Treesitter {#vim-plugin-treesitter}
+### Specificities for some plugins
+#### Treesitter
 
 By default `nvim-treesitter` encourages you to download, compile and install
 the required Treesitter grammars at run time with `:TSInstall`. This works
@@ -212,7 +212,7 @@ Note: this is not possible anymore for Neovim.
 
 ## Adding new plugins to nixpkgs {#adding-new-plugins-to-nixpkgs}
 
-Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names).
+Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
 
 After running `./update.py`, if nvim-treesitter received an update, also run [`nvim-treesitter/update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py) to update the tree sitter grammars for `nvim-treesitter`.
 
@@ -226,7 +226,7 @@ deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
 
 Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
 
-To add a new plugin, run `./update.py add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
+To add a new plugin, run `./update.py --add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
 
 Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of the Language Server Protocol integration with Vim/Neovim.
 
@@ -244,7 +244,7 @@ Alternatively, set the number of processes to a lower count to avoid rate-limiti
 ./pkgs/applications/editors/vim/plugins/update.py --proc 1
 ```
 
-## How to maintain an out-of-tree overlay of vim plugins ? {#vim-out-of-tree-overlays}
+## How to maintain an out-of-tree overlay of vim plugins ?
 
 You can use the updater script to generate basic packages out of a custom vim
 plugin list:

doc/manpage-urls.json

@@ -1,8 +1,5 @@
 {
-  "gnunet.conf(5)": "https://docs.gnunet.org/users/configuration.html",
-  "mpd(1)": "https://mpd.readthedocs.io/en/latest/mpd.1.html",
-  "mpd.conf(5)": "https://mpd.readthedocs.io/en/latest/mpd.conf.5.html",
-  "nix.conf(5)": "https://nixos.org/manual/nix/stable/command-ref/conf-file.html",
+  "nix.conf(5)": "https://nixos.org/manual/nix/stable/#sec-conf-file",
 
   "journald.conf(5)": "https://www.freedesktop.org/software/systemd/man/journald.conf.html",
   "logind.conf(5)": "https://www.freedesktop.org/software/systemd/man/logind.conf.html",

doc/manual.xml

@@ -1,24 +1,19 @@
 <book xmlns="http://docbook.org/ns/docbook"
-      xmlns:xi="http://www.w3.org/2001/XInclude"
-      xml:id="nixpkgs-manual">
+      xmlns:xi="http://www.w3.org/2001/XInclude">
  <info>
   <title>Nixpkgs Manual</title>
   <subtitle>Version <xi:include href=".version" parse="text" />
   </subtitle>
  </info>
  <xi:include href="preface.chapter.xml" />
- <part xml:id="part-using">
+ <part>
   <title>Using Nixpkgs</title>
   <xi:include href="using/configuration.chapter.xml" />
   <xi:include href="using/overlays.chapter.xml" />
   <xi:include href="using/overrides.chapter.xml" />
+  <xi:include href="functions.xml" />
  </part>
  <part>
-  <title>Nixpkgs <code>lib</code></title>
-  <xi:include href="functions.xml" />
-  <xi:include href="module-system/module-system.chapter.xml" />
- </part>
- <part xml:id="part-stdenv">
   <title>Standard environment</title>
   <xi:include href="stdenv/stdenv.chapter.xml" />
   <xi:include href="stdenv/meta.chapter.xml" />
@@ -26,7 +21,7 @@
   <xi:include href="stdenv/cross-compilation.chapter.xml" />
   <xi:include href="stdenv/platform-notes.chapter.xml" />
  </part>
- <part xml:id="part-builders">
+ <part>
   <title>Builders</title>
   <xi:include href="builders/fetchers.chapter.xml" />
   <xi:include href="builders/trivial-builders.chapter.xml" />
@@ -37,7 +32,7 @@
   <xi:include href="languages-frameworks/index.xml" />
   <xi:include href="builders/packages/index.xml" />
  </part>
- <part xml:id="part-contributing">
+ <part>
   <title>Contributing to Nixpkgs</title>
   <xi:include href="contributing/quick-start.chapter.xml" />
   <xi:include href="contributing/coding-conventions.chapter.xml" />

doc/module-system/module-system.chapter.md

@@ -1,105 +0,0 @@
-# Module System {#module-system}
-
-## Introduction {#module-system-introduction}
-
-The module system is a language for handling configuration, implemented as a Nix library.
-
-Compared to plain Nix, it adds documentation, type checking and composition or extensibility.
-
-::: {.note}
-This chapter is new and not complete yet. For a gentle introduction to the module system, in the context of NixOS, see [Writing NixOS Modules](https://nixos.org/manual/nixos/unstable/index.html#sec-writing-modules) in the NixOS manual.
-:::
-
-
-## `lib.evalModules` {#module-system-lib-evalModules}
-
-Evaluate a set of modules. This function is typically only used once per application (e.g. once in NixOS, once in Home Manager, ...).
-
-### Parameters {#module-system-lib-evalModules-parameters}
-
-#### `modules` {#module-system-lib-evalModules-param-modules}
-
-A list of modules. These are merged together to form the final configuration.
-<!-- TODO link to section about merging, TBD -->
-
-#### `specialArgs` {#module-system-lib-evalModules-param-specialArgs}
-
-An attribute set of module arguments that can be used in `imports`.
-
-This is in contrast to `config._module.args`, which is only available after all `imports` have been resolved.
-
-#### `class` {#module-system-lib-evalModules-param-class}
-
-If the `class` attribute is set and non-`null`, the module system will reject `imports` with a different `_class` declaration.
-
-The `class` value should be a string in lower [camel case](https://en.wikipedia.org/wiki/Camel_case).
-
-If applicable, the `class` should match the "prefix" of the attributes used in (experimental) [flakes](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html#description). Some examples are:
-
- - `nixos` as in `flake.nixosModules`
- - `nixosTest`: modules that constitute a [NixOS VM test](https://nixos.org/manual/nixos/stable/index.html#sec-nixos-tests)
-<!-- We've only just started with `class`. You're invited to add a few more. -->
-
-#### `prefix` {#module-system-lib-evalModules-param-prefix}
-
-A list of strings representing the location at or below which all options are evaluated. This is used by `types.submodule` to improve error reporting and find the implicit `name` module argument.
-
-### Return value {#module-system-lib-evalModules-return-value}
-
-The result is an attribute set with the following attributes:
-
-#### `options` {#module-system-lib-evalModules-return-value-options}
-
-The nested attribute set of all option declarations.
-
-#### `config` {#module-system-lib-evalModules-return-value-config}
-
-The nested attribute set of all option values.
-
-#### `type` {#module-system-lib-evalModules-return-value-type}
-
-A module system type. This type is an instance of `types.submoduleWith` containing the current [`modules`](#module-system-lib-evalModules-param-modules).
-
-The option definitions that are typed with this type will extend the current set of modules, like [`extendModules`](#module-system-lib-evalModules-return-value-extendModules).
-
-However, the value returned from the type is just the [`config`](#module-system-lib-evalModules-return-value-config), like any submodule.
-
-If you're familiar with prototype inheritance, you can think of this `evalModules` invocation as the prototype, and usages of this type as the instances.
-
-This type is also available to the [`modules`](#module-system-lib-evalModules-param-modules) as the module argument `moduleType`.
-<!-- TODO: document the module arguments. Using moduleType is like saying: suppose this configuration was extended. -->
-
-#### `extendModules` {#module-system-lib-evalModules-return-value-extendModules}
-
-A function similar to `evalModules` but building on top of the already passed [`modules`](#module-system-lib-evalModules-param-modules). Its arguments, `modules` and `specialArgs` are added to the existing values.
-
-If you're familiar with prototype inheritance, you can think of the current, actual `evalModules` invocation as the prototype, and the return value of `extendModules` as the instance.
-
-This functionality is also available to modules as the `extendModules` module argument.
-
-::: {.note}
-
-**Evaluation Performance**
-
-`extendModules` returns a configuration that shares very little with the original `evalModules` invocation, because the module arguments may be different.
-
-So if you have a configuration that has been (or will be) largely evaluated, almost none of the computation is shared with the configuration returned by `extendModules`.
-
-The real work of module evaluation happens while computing the values in `config` and `options`, so multiple invocations of `extendModules` have a particularly small cost, as long as only the final `config` and `options` are evaluated.
-
-If you do reference multiple `config` (or `options`) from before and after `extendModules`, evaluation performance is the same as with multiple `evalModules` invocations, because the new modules' ability to override existing configuration fundamentally requires constructing a new `config` and `options` fixpoint.
-:::
-
-#### `_module` {#module-system-lib-evalModules-return-value-_module}
-
-A portion of the configuration tree which is elided from `config`.
-
-<!-- TODO: when markdown migration is complete, make _module docs visible again and reference _module docs. Maybe move those docs into this chapter? -->
-
-#### `_type` {#module-system-lib-evalModules-return-value-_type}
-
-A nominal type marker, always `"configuration"`.
-
-#### `class` {#module-system-lib-evalModules-return-value-_configurationClass}
-
-The [`class` argument](#module-system-lib-evalModules-param-class).

doc/stdenv/cross-compilation.chapter.md

@@ -150,7 +150,7 @@ depsBuildBuild = [ buildPackages.stdenv.cc ];
 Add the following to your `mkDerivation` invocation.
 
 ```nix
-doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
+doCheck = stdenv.hostPlatform == stdenv.buildPlatform;
 ```
 
 #### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}

doc/stdenv/meta.chapter.md

@@ -86,23 +86,6 @@ meta.platforms = lib.platforms.linux;
 
 Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
 
-### `badPlatforms` {#var-meta-badPlatforms}
-
-The list of Nix [platform types](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L75-L81) on which the package is known not to be buildable.
-Hydra will never create prebuilt binaries for these platform types, even if they are in [`meta.platforms`](#var-meta-platforms).
-In general it is preferable to set `meta.platforms = lib.platforms.all` and then exclude any platforms on which the package is known not to build.
-For example, a package which requires dynamic linking and cannot be linked statically could use this:
-
-```nix
-meta.platforms = lib.platforms.all;
-meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
-```
-
-The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
-Some packages use this to automatically detect the maximum set of features with which they can be built.
-For example, `systemd` [requires dynamic linking](https://github.com/systemd/systemd/issues/20600#issuecomment-912338965), and [has a `meta.badPlatforms` setting](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/pkgs/os-specific/linux/systemd/default.nix#L752) similar to the one above.
-Packages which can be built with or without `systemd` support will use `lib.meta.availableOn` to detect whether or not `systemd` is available on the [`hostPlatform`](#ssec-cross-platform-parameters) for which they are being built; if it is not available (e.g. due to a statically-linked host platform like `pkgsStatic`) this support will be disabled by default.
-
 ### `tests` {#var-meta-tests}
 
 ::: {.warning}
@@ -118,7 +101,7 @@ $ cd path/to/nixpkgs
 $ nix-build -A your-package.tests
 ```
 
-#### Package tests {#var-meta-tests-packages}
+#### Package tests
 
 Tests that are part of the source package are often executed in the `installCheckPhase`.
 
@@ -130,7 +113,7 @@ Prefer `passthru.tests` for tests that are introduced in nixpkgs because:
 
 For more on how to write and run package tests, see <xref linkend="sec-package-tests"/>.
 
-#### NixOS tests {#var-meta-tests-nixos}
+#### NixOS tests
 
 The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
 
@@ -190,7 +173,7 @@ To be effective, it must be presented directly to an evaluation process that han
 
 ### `hydraPlatforms` {#var-meta-hydraPlatforms}
 
-The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
+The list of Nix platform types for which the Hydra instance at `hydra.nixos.org` will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
 
 ```nix
 meta.platforms = lib.platforms.linux;
@@ -199,26 +182,7 @@ meta.hydraPlatforms = [];
 
 ### `broken` {#var-meta-broken}
 
-If set to `true`, the package is marked as "broken", meaning that it won’t show up in [search.nixos.org](https://search.nixos.org/packages), and cannot be built or installed unless the environment variable [`NIXPKGS_ALLOW_BROKEN`](#opt-allowBroken) is set.
-Such unconditionally-broken packages should be removed from Nixpkgs eventually unless they are fixed.
-
-The value of this attribute can depend on a package's arguments, including `stdenv`.
-This means that `broken` can be used to express constraints, for example:
-
-- Does not cross compile
-
-  ```nix
-   meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform)
-  ```
-
-- Broken if all of a certain set of its dependencies are broken
-
-  ```nix
-  meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ])
-  ```
-
-This makes `broken` strictly more powerful than `meta.badPlatforms`.
-However `meta.availableOn` currently examines only `meta.platforms` and `meta.badPlatforms`, so `meta.broken` does not influence the default values for optional dependencies.
+If set to `true`, the package is marked as "broken", meaning that it won’t show up in `nix-env -qa`, and cannot be built or installed. Such packages should be removed from Nixpkgs eventually unless they are fixed.
 
 ## Licenses {#sec-meta-license}
 

doc/stdenv/stdenv.chapter.md

@@ -16,8 +16,7 @@ stdenv.mkDerivation {
 }
 ```
 
-(`stdenv` needs to be in scope, so if you write this in a separate Nix expression from `pkgs/all-packages.nix`, you need to pass it as a function argument.) Specifying a `name` and a `src` is the absolute minimum Nix requires. For convenience, you can also use `pname` and `version` attributes and `mkDerivation` will automatically set `name` to `"${pname}-${version}"` by default.
-**Since [RFC 0035](https://github.com/NixOS/rfcs/pull/35), this is preferred for packages in Nixpkgs**, as it allows us to reuse the version easily:
+(`stdenv` needs to be in scope, so if you write this in a separate Nix expression from `pkgs/all-packages.nix`, you need to pass it as a function argument.) Specifying a `name` and a `src` is the absolute minimum Nix requires. For convenience, you can also use `pname` and `version` attributes and `mkDerivation` will automatically set `name` to `"${pname}-${version}"` by default. Since [RFC 0035](https://github.com/NixOS/rfcs/pull/35), this is preferred for packages in Nixpkgs, as it allows us to reuse the version easily:
 
 ```nix
 stdenv.mkDerivation rec {
@@ -34,8 +33,7 @@ Many packages have dependencies that are not provided in the standard environmen
 
 ```nix
 stdenv.mkDerivation {
-  pname = "libfoo";
-  version = "1.2.3";
+  name = "libfoo-1.2.3";
   ...
   buildInputs = [libbar perl ncurses];
 }
@@ -47,8 +45,7 @@ Often it is necessary to override or modify some aspect of the build. To make th
 
 ```nix
 stdenv.mkDerivation {
-  pname = "fnord";
-  version = "4.5";
+  name = "fnord-4.5";
   ...
   buildPhase = ''
     gcc foo.c -o foo
@@ -68,8 +65,7 @@ While the standard environment provides a generic builder, you can still supply
 
 ```nix
 stdenv.mkDerivation {
-  pname = "libfoo";
-  version = "1.2.3";
+  name = "libfoo-1.2.3";
   ...
   builder = ./builder.sh;
 }
@@ -99,27 +95,6 @@ installPhase() {
 genericBuild
 ```
 
-### Building a `stdenv` package in `nix-shell` {#sec-building-stdenv-package-in-nix-shell}
-
-To build a `stdenv` package in a [`nix-shell`](https://nixos.org/manual/nix/unstable/command-ref/nix-shell.html), use
-
-```bash
-nix-shell '<nixpkgs>' -A some_package
-eval "${unpackPhase:-unpackPhase}"
-cd $sourceRoot
-eval "${patchPhase:-patchPhase}"
-eval "${configurePhase:-configurePhase}"
-eval "${buildPhase:-buildPhase}"
-```
-
-To modify a [phase](#sec-stdenv-phases), first print it with
-
-```bash
-type buildPhase
-```
-
-then change it in a text editor, and paste it back to the terminal.
-
 ## Tools provided by `stdenv` {#sec-tools-of-stdenv}
 
 The standard environment provides the following packages:
@@ -141,82 +116,6 @@ On Linux, `stdenv` also includes the `patchelf` utility.
 
 ## Specifying dependencies {#ssec-stdenv-dependencies}
 
-Build systems often require more dependencies than just what `stdenv` provides. This section describes attributes accepted by `stdenv.mkDerivation` that can be used to make these dependencies available to the build system.
-
-### Overview {#ssec-stdenv-dependencies-overview}
-
-A full reference of the different kinds of dependencies is provided in [](#ssec-stdenv-dependencies-reference), but here is an overview of the most common ones.
-It should cover most use cases.
-
-Add dependencies to `nativeBuildInputs` if they are executed during the build:
-- those which are needed on `$PATH` during the build, for example `cmake` and `pkg-config`
-- [setup hooks](#ssec-setup-hooks), for example [`makeWrapper`](#fun-makeWrapper)
-- interpreters needed by [`patchShebangs`](#patch-shebangs.sh) for build scripts (with the `--build` flag), which can be the case for e.g. `perl`
-
-Add dependencies to `buildInputs` if they will end up copied or linked into the final output or otherwise used at runtime:
-- libraries used by compilers, for example `zlib`,
-- interpreters needed by [`patchShebangs`](#patch-shebangs.sh) for scripts which are installed, which can be the case for e.g. `perl`
-
-::: {.note}
-These criteria are independent.
-
-For example, software using Wayland usually needs the `wayland` library at runtime, so `wayland` should be added to `buildInputs`.
-But it also executes the `wayland-scanner` program as part of the build to generate code, so `wayland` should also be added to `nativeBuildInputs`.
-:::
-
-Dependencies needed only to run tests are similarly classified between native (executed during build) and non-native (executed at runtime):
-- `nativeCheckInputs` for test tools needed on `$PATH` (such as `ctest`) and [setup hooks](#ssec-setup-hooks) (for example [`pytestCheckHook`](#python))
-- `checkInputs` for libraries linked into test executables (for example the `qcheck` OCaml package)
-
-These dependencies are only injected when [`doCheck`](#var-stdenv-doCheck) is set to `true`.
-
-#### Example {#ssec-stdenv-dependencies-overview-example}
-
-Consider for example this simplified derivation for `solo5`, a sandboxing tool:
-```nix
-stdenv.mkDerivation rec {
-  pname = "solo5";
-  version = "0.7.5";
-
-  src = fetchurl {
-    url = "https://github.com/Solo5/solo5/releases/download/v${version}/solo5-v${version}.tar.gz";
-    sha256 = "sha256-viwrS9lnaU8sTGuzK/+L/PlMM/xRRtgVuK5pixVeDEw=";
-  };
-
-  nativeBuildInputs = [ makeWrapper pkg-config ];
-  buildInputs = [ libseccomp ];
-
-  postInstall = ''
-    substituteInPlace $out/bin/solo5-virtio-mkimage \
-      --replace "/usr/lib/syslinux" "${syslinux}/share/syslinux" \
-      --replace "/usr/share/syslinux" "${syslinux}/share/syslinux" \
-      --replace "cp " "cp --no-preserve=mode "
-
-    wrapProgram $out/bin/solo5-virtio-mkimage \
-      --prefix PATH : ${lib.makeBinPath [ dosfstools mtools parted syslinux ]}
-  '';
-
-  doCheck = true;
-  nativeCheckInputs = [ util-linux qemu ];
-  checkPhase = '' [elided] '';
-}
-```
-
-- `makeWrapper` is a setup hook, i.e., a shell script sourced by the generic builder of `stdenv`.
-  It is thus executed during the build and must be added to `nativeBuildInputs`.
-- `pkg-config` is a build tool which the configure script of `solo5` expects to be on `$PATH` during the build:
-  therefore, it must be added to `nativeBuildInputs`.
-- `libseccomp` is a library linked into `$out/bin/solo5-elftool`.
-  As it is used at runtime, it must be added to `buildInputs`.
-- Tests need `qemu` and `getopt` (from `util-linux`) on `$PATH`, these must be added to `nativeCheckInputs`.
-- Some dependencies are injected directly in the shell code of phases: `syslinux`, `dosfstools`, `mtools`, and `parted`.
-In this specific case, they will end up in the output of the derivation (`$out` here).
-As Nix marks dependencies whose absolute path is present in the output as runtime dependencies, adding them to `buildInputs` is not required.
-
-For more complex cases, like libraries linked into an executable which is then executed as part of the build system, see [](#ssec-stdenv-dependencies-reference).
-
-### Reference {#ssec-stdenv-dependencies-reference}
-
 As described in the Nix manual, almost any `*.drv` store path in a derivation’s attribute set will induce a dependency on that derivation. `mkDerivation`, however, takes a few attributes intended to include all the dependencies of a package. This is done both for structure and consistency, but also so that certain other setup can take place. For example, certain dependencies need their bin directories added to the `PATH`. That is built-in, but other setup is done via a pluggable mechanism that works in conjunction with these dependency attributes. See [](#ssec-setup-hooks) for details.
 
 Dependencies can be broken down along three axes: their host and target platforms relative to the new derivation’s, and whether they are propagated. The platform distinctions are motivated by cross compilation; see [](#chap-cross) for exactly what each platform means. [^footnote-stdenv-ignored-build-platform] But even if one is not cross compiling, the platforms imply whether or not the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation. By default, the run-time/build-time distinction is just a hint for mental clarity, but with `strictDeps` set it is mostly enforced even in the native case.
@@ -288,21 +187,21 @@ Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In
 
 Overall, the unifying theme here is that propagation shouldn’t be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the dependending package asking for dependencies with the platforms it knows about; other platforms it doesn’t know how to ask for. The platform description in that scenario is a kind of unforagable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms weren’t in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
 
-#### Variables specifying dependencies {#variables-specifying-dependencies}
+### Variables specifying dependencies {#variables-specifying-dependencies}
 
-##### `depsBuildBuild` {#var-stdenv-depsBuildBuild}
+#### `depsBuildBuild` {#var-stdenv-depsBuildBuild}
 
 A list of dependencies whose host and target platforms are the new derivation’s build platform. These are programs and libraries used at build time that produce programs and libraries also used at build time. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it in `nativeBuildInputs` instead. The most common use of this `buildPackages.stdenv.cc`, the default C compiler for this role. That example crops up more than one might think in old commonly used C libraries.
 
 Since these packages are able to be run at build-time, they are always added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `nativeBuildInputs` {#var-stdenv-nativeBuildInputs}
+#### `nativeBuildInputs` {#var-stdenv-nativeBuildInputs}
 
 A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s host platform. These are programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild` or `depsBuildTarget`. This could be called `depsBuildHost` but `nativeBuildInputs` is used for historical continuity.
 
 Since these packages are able to be run at build-time, they are added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `depsBuildTarget` {#var-stdenv-depsBuildTarget}
+#### `depsBuildTarget` {#var-stdenv-depsBuildTarget}
 
 A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s target platform. These are programs used at build time that produce code to run with code produced by the depending package. Most commonly, these are tools used to build the runtime or standard library that the currently-being-built compiler will inject into any code it compiles. In many cases, the currently-being-built-compiler is itself employed for that task, but when that compiler won’t run (i.e. its build and host platform differ) this is not possible. Other times, the compiler relies on some other tool, like binutils, that is always built separately so that the dependency is unconditional.
 
@@ -310,41 +209,41 @@ This is a somewhat confusing concept to wrap one’s head around, and for good r
 
 Since these packages are able to run at build time, they are added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `depsHostHost` {#var-stdenv-depsHostHost}
+#### `depsHostHost` {#var-stdenv-depsHostHost}
 
 A list of dependencies whose host and target platforms match the new derivation’s host platform. In practice, this would usually be tools used by compilers for macros or a metaprogramming system, or libraries used by the macros or metaprogramming code itself. It’s always preferable to use a `depsBuildBuild` dependency in the derivation being built over a `depsHostHost` on the tool doing the building for this purpose.
 
-##### `buildInputs` {#var-stdenv-buildInputs}
+#### `buildInputs` {#var-stdenv-buildInputs}
 
 A list of dependencies whose host platform and target platform match the new derivation’s. This would be called `depsHostTarget` but for historical continuity. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild`.
 
 These are often programs and libraries used by the new derivation at *run*-time, but that isn’t always the case. For example, the machine code in a statically-linked library is only used at run-time, but the derivation containing the library is only needed at build-time. Even in the dynamic case, the library may also be needed at build-time to appease the linker.
 
-##### `depsTargetTarget` {#var-stdenv-depsTargetTarget}
+#### `depsTargetTarget` {#var-stdenv-depsTargetTarget}
 
 A list of dependencies whose host platform matches the new derivation’s target platform. These are packages that run on the target platform, e.g. the standard library or run-time deps of standard library that a compiler insists on knowing about. It’s poor form in almost all cases for a package to depend on another from a future stage \[future stage corresponding to positive offset\]. Do not use this attribute unless you are packaging a compiler and are sure it is needed.
 
-##### `depsBuildBuildPropagated` {#var-stdenv-depsBuildBuildPropagated}
+#### `depsBuildBuildPropagated` {#var-stdenv-depsBuildBuildPropagated}
 
 The propagated equivalent of `depsBuildBuild`. This perhaps never ought to be used, but it is included for consistency \[see below for the others\].
 
-##### `propagatedNativeBuildInputs` {#var-stdenv-propagatedNativeBuildInputs}
+#### `propagatedNativeBuildInputs` {#var-stdenv-propagatedNativeBuildInputs}
 
 The propagated equivalent of `nativeBuildInputs`. This would be called `depsBuildHostPropagated` but for historical continuity. For example, if package `Y` has `propagatedNativeBuildInputs = [X]`, and package `Z` has `buildInputs = [Y]`, then package `Z` will be built as if it included package `X` in its `nativeBuildInputs`. If instead, package `Z` has `nativeBuildInputs = [Y]`, then `Z` will be built as if it included `X` in the `depsBuildBuild` of package `Z`, because of the sum of the two `-1` host offsets.
 
-##### `depsBuildTargetPropagated` {#var-stdenv-depsBuildTargetPropagated}
+#### `depsBuildTargetPropagated` {#var-stdenv-depsBuildTargetPropagated}
 
 The propagated equivalent of `depsBuildTarget`. This is prefixed for the same reason of alerting potential users.
 
-##### `depsHostHostPropagated` {#var-stdenv-depsHostHostPropagated}
+#### `depsHostHostPropagated` {#var-stdenv-depsHostHostPropagated}
 
 The propagated equivalent of `depsHostHost`.
 
-##### `propagatedBuildInputs` {#var-stdenv-propagatedBuildInputs}
+#### `propagatedBuildInputs` {#var-stdenv-propagatedBuildInputs}
 
 The propagated equivalent of `buildInputs`. This would be called `depsHostTargetPropagated` but for historical continuity.
 
-##### `depsTargetTargetPropagated` {#var-stdenv-depsTargetTargetPropagated}
+#### `depsTargetTargetPropagated` {#var-stdenv-depsTargetTargetPropagated}
 
 The propagated equivalent of `depsTargetTarget`. This is prefixed for the same reason of alerting potential users.
 
@@ -354,7 +253,7 @@ The propagated equivalent of `depsTargetTarget`. This is prefixed for the same r
 
 #### `NIX_DEBUG` {#var-stdenv-NIX_DEBUG}
 
-A number between 0 and 7 indicating how much information to log. If set to 1 or higher, `stdenv` will print moderate debugging information during the build. In particular, the `gcc` and `ld` wrapper scripts will print out the complete command line passed to the wrapped tools. If set to 6 or higher, the `stdenv` setup script will be run with `set -x` tracing. If set to 7 or higher, the `gcc` and `ld` wrapper scripts will also be run with `set -x` tracing.
+A natural number indicating how much information to log. If set to 1 or higher, `stdenv` will print moderate debugging information during the build. In particular, the `gcc` and `ld` wrapper scripts will print out the complete command line passed to the wrapped tools. If set to 6 or higher, the `stdenv` setup script will be run with `set -x` tracing. If set to 7 or higher, the `gcc` and `ld` wrapper scripts will also be run with `set -x` tracing.
 
 ### Attributes affecting build properties {#attributes-affecting-build-properties}
 
@@ -384,107 +283,39 @@ Values inside it are not passed to the builder, so you can change them without t
 
 #### `passthru.updateScript` {#var-passthru-updateScript}
 
-A script to be run by `maintainers/scripts/update.nix` when the package is matched. The attribute can contain one of the following:
+A script to be run by `maintainers/scripts/update.nix` when the package is matched. It needs to be an executable file, either on the file system:
 
-- []{#var-passthru-updateScript-command} an executable file, either on the file system:
+```nix
+passthru.updateScript = ./update.sh;
+```
 
-  ```nix
-  passthru.updateScript = ./update.sh;
-  ```
+or inside the expression itself:
 
-  or inside the expression itself:
+```nix
+passthru.updateScript = writeScript "update-zoom-us" ''
+  #!/usr/bin/env nix-shell
+  #!nix-shell -i bash -p curl pcre common-updater-scripts
 
-  ```nix
-  passthru.updateScript = writeScript "update-zoom-us" ''
-    #!/usr/bin/env nix-shell
-    #!nix-shell -i bash -p curl pcre common-updater-scripts
+  set -eu -o pipefail
 
-    set -eu -o pipefail
+  version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcregrep -o1 '/(([0-9]\.?)+)/')"
+  update-source-version zoom-us "$version"
+'';
+```
 
-    version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcregrep -o1 '/(([0-9]\.?)+)/')"
-    update-source-version zoom-us "$version"
-  '';
-  ```
+The attribute can also contain a list, a script followed by arguments to be passed to it:
 
-- a list, a script followed by arguments to be passed to it:
+```nix
+passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
+```
 
-  ```nix
-  passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
-  ```
-
-- an attribute set containing:
-  - [`command`]{#var-passthru-updateScript-set-command} – a string or list in the [format expected by `passthru.updateScript`](#var-passthru-updateScript-command).
-  - [`attrPath`]{#var-passthru-updateScript-set-attrPath} (optional) – a string containing the canonical attribute path for the package. If present, it will be passed to the update script instead of the attribute path on which the package was discovered during Nixpkgs traversal.
-  - [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.
-
-  ```nix
-  passthru.updateScript = {
-    command = [ ../../update.sh pname ];
-    attrPath = pname;
-    supportedFeatures = [ … ];
-  };
-  ```
-
-##### How update scripts are executed? {#var-passthru-updateScript-execution}
-
-Update scripts are to be invoked by `maintainers/scripts/update.nix` script. You can run `nix-shell maintainers/scripts/update.nix` in the root of Nixpkgs repository for information on how to use it. `update.nix` offers several modes for selecting packages to update (e.g. select by attribute path, traverse Nixpkgs and filter by maintainer, etc.), and it will execute update scripts for all matched packages that have an `updateScript` attribute.
-
-Each update script will be passed the following environment variables:
-
-- [`UPDATE_NIX_NAME`]{#var-passthru-updateScript-env-UPDATE_NIX_NAME} – content of the `name` attribute of the updated package.
-- [`UPDATE_NIX_PNAME`]{#var-passthru-updateScript-env-UPDATE_NIX_PNAME} – content of the `pname` attribute of the updated package.
-- [`UPDATE_NIX_OLD_VERSION`]{#var-passthru-updateScript-env-UPDATE_NIX_OLD_VERSION} – content of the `version` attribute of the updated package.
-- [`UPDATE_NIX_ATTR_PATH`]{#var-passthru-updateScript-env-UPDATE_NIX_ATTR_PATH} – attribute path the `update.nix` discovered the package on (or the [canonical `attrPath`](#var-passthru-updateScript-set-attrPath) when available). Example: `pantheon.elementary-terminal`
+The script will be run with the `UPDATE_NIX_NAME`, `UPDATE_NIX_PNAME`, `UPDATE_NIX_OLD_VERSION` and `UPDATE_NIX_ATTR_PATH` environment variables set respectively to the name, pname, old version and attribute path of the package it is supposed to update.
 
 ::: {.note}
-An update script will be usually run from the root of the Nixpkgs repository but you should not rely on that. Also note that `update.nix` executes update scripts in parallel by default so you should avoid running `git commit` or any other commands that cannot handle that.
+The script will be usually run from the root of the Nixpkgs repository but you should not rely on that. Also note that the update scripts will be run in parallel by default; you should avoid running `git commit` or any other commands that cannot handle that.
 :::
 
-::: {.tip}
-While update scripts should not create commits themselves, `maintainers/scripts/update.nix` supports automatically creating commits when running it with `--argstr commit true`. If you need to customize commit message, you can have the update script implement [`commit`](#var-passthru-updateScript-commit) feature.
-:::
-
-##### Supported features {#var-passthru-updateScript-supported-features}
-###### `commit` {#var-passthru-updateScript-commit}
-
-This feature allows update scripts to *ask* `update.nix` to create Git commits.
-
-When support of this feature is declared, whenever the update script exits with `0` return status, it is expected to print a JSON list containing an object described below for each updated attribute to standard output.
-
-When `update.nix` is run with `--argstr commit true` arguments, it will create a separate commit for each of the objects. An empty list can be returned when the script did not update any files, for example, when the package is already at the latest version.
-
-The commit object contains the following values:
-
-- [`attrPath`]{#var-passthru-updateScript-commit-attrPath} – a string containing attribute path.
-- [`oldVersion`]{#var-passthru-updateScript-commit-oldVersion} – a string containing old version.
-- [`newVersion`]{#var-passthru-updateScript-commit-newVersion} – a string containing new version.
-- [`files`]{#var-passthru-updateScript-commit-files} – a non-empty list of file paths (as strings) to add to the commit.
-- [`commitBody`]{#var-passthru-updateScript-commit-commitBody} (optional) – a string with extra content to be appended to the default commit message (useful for adding changelog links).
-- [`commitMessage`]{#var-passthru-updateScript-commit-commitMessage} (optional) – a string to use instead of the default commit message.
-
-If the returned array contains exactly one object (e.g. `[{}]`), all values are optional and will be determined automatically.
-
-```{=docbook}
-<example>
-<title>Standard output of an update script using commit feature</title>
-```
-
-```json
-[
-  {
-    "attrPath": "volume_key",
-    "oldVersion": "0.3.11",
-    "newVersion": "0.3.12",
-    "files": [
-      "/path/to/nixpkgs/pkgs/development/libraries/volume-key/default.nix"
-    ]
-  }
-]
-```
-
-```{=docbook}
-</example>
-```
+For information about how to run the updates, execute `nix-shell maintainers/scripts/update.nix`.
 
 ### Recursive attributes in `mkDerivation` {#mkderivation-recursive-attributes}
 
@@ -707,7 +538,7 @@ The prefix under which the package must be installed, passed via the `--prefix`
 
 The key to use when specifying the prefix. By default, this is set to `--prefix=` as that is used by the majority of packages.
 
-##### `dontAddStaticConfigureFlags` {#var-stdenv-dontAddStaticConfigureFlags}
+##### `dontAddStaticConfigureFlags`
 
 By default, when building statically, stdenv will try to add build system appropriate configure flags to try to enable static builds.
 
@@ -795,7 +626,7 @@ Before and after running `make`, the hooks `preBuild` and `postBuild` are called
 
 ### The check phase {#ssec-check-phase}
 
-The check phase checks whether the package was built correctly by running its test suite. The default `checkPhase` calls `make $checkTarget`, but only if the [`doCheck` variable](#var-stdenv-doCheck) is enabled.
+The check phase checks whether the package was built correctly by running its test suite. The default `checkPhase` calls `make check`, but only if the `doCheck` variable is enabled.
 
 #### Variables controlling the check phase {#variables-controlling-the-check-phase}
 
@@ -815,8 +646,7 @@ See the [build phase](#var-stdenv-makeFlags) for details.
 
 ##### `checkTarget` {#var-stdenv-checkTarget}
 
-The `make` target that runs the tests.
-If unset, use `check` if it exists, otherwise `test`; if neither is found, do nothing.
+The make target that runs the tests. Defaults to `check`.
 
 ##### `checkFlags` / `checkFlagsArray` {#var-stdenv-checkFlags}
 
@@ -824,11 +654,7 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
 
 ##### `checkInputs` {#var-stdenv-checkInputs}
 
-A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doCheck` is set.
-
-##### `nativeCheckInputs` {#var-stdenv-nativeCheckInputs}
-
-A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doCheck` is set.
+A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doCheck` is set.
 
 ##### `preCheck` {#var-stdenv-preCheck}
 
@@ -995,11 +821,7 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
 
 ##### `installCheckInputs` {#var-stdenv-installCheckInputs}
 
-A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doInstallCheck` is set.
-
-##### `nativeInstallCheckInputs` {#var-stdenv-nativeInstallCheckInputs}
-
-A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.
+A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.
 
 ##### `preInstallCheck` {#var-stdenv-preInstallCheck}
 
@@ -1099,15 +921,15 @@ postInstall = ''
 
 Performs string substitution on the contents of \<infile\>, writing the result to \<outfile\>. The substitutions in \<subs\> are of the following form:
 
-#### `--replace` \<s1\> \<s2\> {#fun-substitute-replace}
+#### `--replace` \<s1\> \<s2\>
 
 Replace every occurrence of the string \<s1\> by \<s2\>.
 
-#### `--subst-var` \<varName\> {#fun-substitute-subst-var}
+#### `--subst-var` \<varName\>
 
 Replace every occurrence of `@varName@` by the contents of the environment variable \<varName\>. This is useful for generating files from templates, using `@...@` in the template as placeholders.
 
-#### `--subst-var-by` \<varName\> \<s\> {#fun-substitute-subst-var-by}
+#### `--subst-var-by` \<varName\> \<s\>
 
 Replace every occurrence of `@varName@` by the string \<s\>.
 
@@ -1248,7 +1070,7 @@ Multiple paths can be specified.
 patchShebangs [--build | --host] PATH...
 ```
 
-##### Flags {#patch-shebangs.sh-invocation-flags}
+##### Flags
 
 `--build`
 : Look up commands available at build time
@@ -1256,7 +1078,7 @@ patchShebangs [--build | --host] PATH...
 `--host`
 : Look up commands available at run time
 
-##### Examples {#patch-shebangs.sh-invocation-examples}
+##### Examples
 
 ```sh
 patchShebangs --host /nix/store/<hash>-hello-1.0/bin
@@ -1343,7 +1165,7 @@ Similarly, the CC Wrapper follows the Bintools Wrapper in defining standard envi
 
 Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses.
 
-### Other hooks {#stdenv-other-hooks}
+### Other hooks
 
 Many other packages provide hooks, that are not part of `stdenv`. You can find
 these in the [Hooks Reference](#chap-hooks).
@@ -1401,7 +1223,7 @@ bin/blib.a(bios_console.o): In function `bios_handle_cup':
 
 Adds the `-O2 -D_FORTIFY_SOURCE=2` compiler options. During code generation the compiler knows a great deal of information about buffer sizes (where possible), and attempts to replace insecure unlimited length buffer function calls with length-limited ones. This is especially useful for old, crufty code. Additionally, format strings in writable memory that contain `%n` are blocked. If an application depends on such a format string, it will need to be worked around.
 
-Additionally, some warnings are enabled which might trigger build failures if compiler warnings are treated as errors in the package build. In this case, set `env.NIX_CFLAGS_COMPILE` to `-Wno-error=warning-type`.
+Additionally, some warnings are enabled which might trigger build failures if compiler warnings are treated as errors in the package build. In this case, set `NIX_CFLAGS_COMPILE` to `-Wno-error=warning-type`.
 
 This needs to be turned off or fixed for errors similar to:
 

flake.nix

@@ -57,19 +57,6 @@
 
       nixosModules = {
         notDetected = ./nixos/modules/installer/scan/not-detected.nix;
-
-        /*
-          Make the `nixpkgs.*` configuration read-only. Guarantees that `pkgs`
-          is the way you initialize it.
-
-          Example:
-
-              {
-                imports = [ nixpkgs.nixosModules.readOnlyPkgs ];
-                nixpkgs.pkgs = nixpkgs.legacyPackages.x86_64-linux;
-              }
-        */
-        readOnlyPkgs = ./nixos/modules/misc/nixpkgs/read-only.nix;
       };
     };
 }

lib/ascii-table.nix

@@ -1,7 +1,4 @@
-{ "\t" =  9;
-  "\n" = 10;
-  "\r" = 13;
-  " "  = 32;
+{ " "  = 32;
   "!"  = 33;
   "\"" = 34;
   "#"  = 35;

lib/attrsets.nix

@@ -9,7 +9,7 @@ let
 in
 
 rec {
-  inherit (builtins) attrNames listToAttrs hasAttr isAttrs getAttr removeAttrs;
+  inherit (builtins) attrNames listToAttrs hasAttr isAttrs getAttr;
 
 
   /* Return an attribute from nested attribute sets.
@@ -168,7 +168,7 @@ rec {
        ] { a.b.c = 0; }
        => { a = { b = { d = 1; }; }; x = { y = "xy"; }; }
 
-    Type: updateManyAttrsByPath :: [{ path :: [String]; update :: (Any -> Any); }] -> AttrSet -> AttrSet
+    Type: updateManyAttrsByPath :: [{ path :: [String], update :: (Any -> Any) }] -> AttrSet -> AttrSet
   */
   updateManyAttrsByPath = let
     # When recursing into attributes, instead of updating the `path` of each
@@ -333,66 +333,6 @@ rec {
       ) (attrNames set)
     );
 
-   /*
-    Like builtins.foldl' but for attribute sets.
-    Iterates over every name-value pair in the given attribute set.
-    The result of the callback function is often called `acc` for accumulator. It is passed between callbacks from left to right and the final `acc` is the return value of `foldlAttrs`.
-
-    Attention:
-      There is a completely different function
-      `lib.foldAttrs`
-      which has nothing to do with this function, despite the similar name.
-
-    Example:
-      foldlAttrs
-        (acc: name: value: {
-          sum = acc.sum + value;
-          names = acc.names ++ [name];
-        })
-        { sum = 0; names = []; }
-        {
-          foo = 1;
-          bar = 10;
-        }
-      ->
-        {
-          sum = 11;
-          names = ["bar" "foo"];
-        }
-
-      foldlAttrs
-        (throw "function not needed")
-        123
-        {};
-      ->
-        123
-
-      foldlAttrs
-        (_: _: v: v)
-        (throw "initial accumulator not needed")
-        { z = 3; a = 2; };
-      ->
-        3
-
-      The accumulator doesn't have to be an attrset.
-      It can be as simple as a number or string.
-
-      foldlAttrs
-        (acc: _: v: acc * 10 + v)
-        1
-        { z = 1; a = 2; };
-      ->
-        121
-
-    Type:
-      foldlAttrs :: ( a -> String -> b -> a ) -> a -> { ... :: b } -> a
-  */
-  foldlAttrs = f: init: set:
-    foldl'
-      (acc: name: f acc name set.${name})
-      init
-      (attrNames set);
-
   /* Apply fold functions to values grouped by key.
 
      Example:
@@ -474,7 +414,7 @@ rec {
        => { name = "some"; value = 6; }
 
      Type:
-       nameValuePair :: String -> Any -> { name :: String; value :: Any; }
+       nameValuePair :: String -> Any -> { name :: String, value :: Any }
   */
   nameValuePair =
     # Attribute name
@@ -509,7 +449,7 @@ rec {
        => { foo_x = "bar-a"; foo_y = "bar-b"; }
 
      Type:
-       mapAttrs' :: (String -> Any -> { name :: String; value :: Any; }) -> AttrSet -> AttrSet
+       mapAttrs' :: (String -> Any -> { name = String; value = Any }) -> AttrSet -> AttrSet
   */
   mapAttrs' =
     # A function, given an attribute's name and value, returns a new `nameValuePair`.
@@ -540,13 +480,8 @@ rec {
 
 
   /* Like `mapAttrs`, except that it recursively applies itself to
-     the *leaf* attributes of a potentially-nested attribute set:
-     the second argument of the function will never be an attrset.
-     Also, the first argument of the argument function is a *list*
-     of the attribute names that form the path to the leaf attribute.
-
-     For a function that gives you control over what counts as a leaf,
-     see `mapAttrsRecursiveCond`.
+     attribute sets.  Also, the first argument of the argument
+     function is a *list* of the names of the containing attributes.
 
      Example:
        mapAttrsRecursive (path: value: concatStringsSep "-" (path ++ [value]))
@@ -709,7 +644,7 @@ rec {
 
      Example:
        zipAttrsWith (name: values: values) [{a = "x";} {a = "y"; b = "z";}]
-       => { a = ["x" "y"]; b = ["z"]; }
+       => { a = ["x" "y"]; b = ["z"] }
 
      Type:
        zipAttrsWith :: (String -> [ Any ] -> Any) -> [ AttrSet ] -> AttrSet
@@ -724,7 +659,7 @@ rec {
 
      Example:
        zipAttrs [{a = "x";} {a = "y"; b = "z";}]
-       => { a = ["x" "y"]; b = ["z"]; }
+       => { a = ["x" "y"]; b = ["z"] }
 
      Type:
        zipAttrs :: [ AttrSet ] -> AttrSet

lib/customisation.nix

@@ -176,7 +176,7 @@ rec {
       # Only show the error for the first missing argument
       error = errorForArg (lib.head missingArgs);
 
-    in if missingArgs == [] then makeOverridable f allArgs else abort error;
+    in if missingArgs == [] then makeOverridable f allArgs else throw error;
 
 
   /* Like callPackage, but for a function that returns an attribute
@@ -213,14 +213,7 @@ rec {
             outputSpecified = true;
             drvPath = assert condition; drv.${outputName}.drvPath;
             outPath = assert condition; drv.${outputName}.outPath;
-          } //
-            # TODO: give the derivation control over the outputs.
-            #       `overrideAttrs` may not be the only attribute that needs
-            #       updating when switching outputs.
-            lib.optionalAttrs (passthru?overrideAttrs) {
-              # TODO: also add overrideAttrs when overrideAttrs is not custom, e.g. when not splicing.
-              overrideAttrs = f: (passthru.overrideAttrs f).${outputName};
-            };
+          };
         };
 
       outputsList = map outputToAttrListElement outputs;
@@ -259,8 +252,7 @@ rec {
       outputsList = map makeOutput outputs;
 
       drv' = (lib.head outputsList).value;
-    in if drv == null then null else
-      lib.deepSeq drv' drv';
+    in lib.deepSeq drv' drv';
 
   /* Make a set of packages with a common scope. All packages called
      with the provided `callPackage` will be evaluated with the same

lib/debug.nix

@@ -109,8 +109,6 @@ rec {
        traceSeqN 2 { a.b.c = 3; } null
        trace: { a = { b = {…}; }; }
        => null
-
-     Type: traceSeqN :: Int -> a -> b -> b
    */
   traceSeqN = depth: x: y:
     let snip = v: if      isList  v then noQuotes "[…]" v
@@ -175,63 +173,17 @@ rec {
 
   # -- TESTING --
 
-  /* Evaluates a set of tests.
-
-     A test is an attribute set `{expr, expected}`,
-     denoting an expression and its expected result.
-
-     The result is a `list` of __failed tests__, each represented as
-     `{name, expected, result}`,
-
-     - expected
-       - What was passed as `expected`
-     - result
-       - The actual `result` of the test
+  /* Evaluate a set of tests.  A test is an attribute set `{expr,
+     expected}`, denoting an expression and its expected result.  The
+     result is a list of failed tests, each represented as `{name,
+     expected, actual}`, denoting the attribute name of the failing
+     test and its expected and actual results.
 
      Used for regression testing of the functions in lib; see
-     tests.nix for more examples.
+     tests.nix for an example. Only tests having names starting with
+     "test" are run.
 
-     Important: Only attributes that start with `test` are executed.
-
-     - If you want to run only a subset of the tests add the attribute `tests = ["testName"];`
-
-    Example:
-
-     runTests {
-       testAndOk = {
-         expr = lib.and true false;
-         expected = false;
-       };
-       testAndFail = {
-         expr = lib.and true false;
-         expected = true;
-       };
-     }
-     ->
-     [
-       {
-         name = "testAndFail";
-         expected = true;
-         result = false;
-       }
-     ]
-
-    Type:
-      runTests :: {
-        tests = [ String ];
-        ${testName} :: {
-          expr :: a;
-          expected :: a;
-        };
-      }
-      ->
-      [
-        {
-          name :: String;
-          expected :: a;
-          result :: a;
-        }
-      ]
+     Add attr { tests = ["testName"]; } to run these tests only.
   */
   runTests =
     # Tests to run
@@ -250,4 +202,90 @@ rec {
        { testX = allTrue [ true ]; }
   */
   testAllTrue = expr: { inherit expr; expected = map (x: true) expr; };
+
+
+  # -- DEPRECATED --
+
+  traceShowVal = x: trace (showVal x) x;
+  traceShowValMarked = str: x: trace (str + showVal x) x;
+
+  attrNamesToStr = a:
+    trace ( "Warning: `attrNamesToStr` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please use more specific concatenation "
+          + "for your uses (`lib.concat(Map)StringsSep`)." )
+    (concatStringsSep "; " (map (x: "${x}=") (attrNames a)));
+
+  showVal =
+    trace ( "Warning: `showVal` is deprecated "
+          + "and will be removed in the next release, "
+          + "please use `traceSeqN`" )
+    (let
+      modify = v:
+        let pr = f: { __pretty = f; val = v; };
+        in   if isDerivation v then pr
+          (drv: "<δ:${drv.name}:${concatStringsSep ","
+                                 (attrNames drv)}>")
+        else if [] ==   v then pr (const "[]")
+        else if isList  v then pr (l: "[ ${go (head l)}, … ]")
+        else if isAttrs v then pr
+          (a: "{ ${ concatStringsSep ", " (attrNames a)} }")
+        else v;
+      go = x: generators.toPretty
+        { allowPrettyValues = true; }
+        (modify x);
+    in go);
+
+  traceXMLVal = x:
+    trace ( "Warning: `traceXMLVal` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please use `traceValFn builtins.toXML`." )
+    (trace (builtins.toXML x) x);
+  traceXMLValMarked = str: x:
+    trace ( "Warning: `traceXMLValMarked` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please use `traceValFn (x: str + builtins.toXML x)`." )
+    (trace (str + builtins.toXML x) x);
+
+  # trace the arguments passed to function and its result
+  # maybe rewrite these functions in a traceCallXml like style. Then one function is enough
+  traceCall  = n: f: a: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a));
+  traceCall2 = n: f: a: b: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a) (t "arg 2" b));
+  traceCall3 = n: f: a: b: c: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a) (t "arg 2" b) (t "arg 3" c));
+
+  traceValIfNot = c: x:
+    trace ( "Warning: `traceValIfNot` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please use `if/then/else` and `traceValSeq 1`.")
+    (if c x then true else traceSeq (showVal x) false);
+
+
+  addErrorContextToAttrs = attrs:
+    trace ( "Warning: `addErrorContextToAttrs` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please use `builtins.addErrorContext` directly." )
+    (mapAttrs (a: v: addErrorContext "while evaluating ${a}" v) attrs);
+
+  # example: (traceCallXml "myfun" id 3) will output something like
+  # calling myfun arg 1: 3 result: 3
+  # this forces deep evaluation of all arguments and the result!
+  # note: if result doesn't evaluate you'll get no trace at all (FIXME)
+  #       args should be printed in any case
+  traceCallXml = a:
+    trace ( "Warning: `traceCallXml` is deprecated "
+          + "and will be removed in the next release. "
+          + "Please complain if you use the function regularly." )
+    (if !isInt a then
+      traceCallXml 1 "calling ${a}\n"
+    else
+      let nr = a;
+      in (str: expr:
+          if isFunction expr then
+            (arg:
+              traceCallXml (builtins.add 1 nr) "${str}\n arg ${builtins.toString nr} is \n ${builtins.toXML (builtins.seq arg arg)}" (expr arg)
+            )
+          else
+            let r = builtins.seq expr expr;
+            in trace "${str}\n result:\n${builtins.toXML r}" r
+      ));
 }

lib/default.nix

@@ -78,7 +78,7 @@ let
       composeManyExtensions makeExtensible makeExtensibleWithCustomName;
     inherit (self.attrsets) attrByPath hasAttrByPath setAttrByPath
       getAttrFromPath attrVals attrValues getAttrs catAttrs filterAttrs
-      filterAttrsRecursive foldlAttrs foldAttrs collect nameValuePair mapAttrs
+      filterAttrsRecursive foldAttrs collect nameValuePair mapAttrs
       mapAttrs' mapAttrsToList concatMapAttrs mapAttrsRecursive mapAttrsRecursiveCond
       genAttrs isDerivation toDerivation optionalAttrs
       zipAttrsWithNames zipAttrsWith zipAttrs recursiveUpdateUntil
@@ -88,19 +88,19 @@ let
       updateManyAttrsByPath;
     inherit (self.lists) singleton forEach foldr fold foldl foldl' imap0 imap1
       concatMap flatten remove findSingle findFirst any all count
-      optional optionals toList range replicate partition zipListsWith zipLists
+      optional optionals toList range partition zipListsWith zipLists
       reverseList listDfs toposort sort naturalSort compareLists take
       drop sublist last init crossLists unique intersectLists
       subtractLists mutuallyExclusive groupBy groupBy';
     inherit (self.strings) concatStrings concatMapStrings concatImapStrings
       intersperse concatStringsSep concatMapStringsSep
-      concatImapStringsSep concatLines makeSearchPath makeSearchPathOutput
+      concatImapStringsSep makeSearchPath makeSearchPathOutput
       makeLibraryPath makeBinPath optionalString
       hasInfix hasPrefix hasSuffix stringToCharacters stringAsChars escape
       escapeShellArg escapeShellArgs
       isStorePath isStringLike
       isValidPosixName toShellVar toShellVars
-      escapeRegex escapeURL escapeXML replaceChars lowerChars
+      escapeRegex escapeXML replaceChars lowerChars
       upperChars toLower toUpper addContextFrom splitString
       removePrefix removeSuffix versionOlder versionAtLeast
       getName getVersion
@@ -145,10 +145,11 @@ let
       isOptionType mkOptionType;
     inherit (self.asserts)
       assertMsg assertOneOf;
-    inherit (self.debug) traceIf traceVal traceValFn
-      traceSeq traceSeqN traceValSeq
-      traceValSeqFn traceValSeqN traceValSeqNFn traceFnSeqN
-      runTests testAllTrue;
+    inherit (self.debug) addErrorContextToAttrs traceIf traceVal traceValFn
+      traceXMLVal traceXMLValMarked traceSeq traceSeqN traceValSeq
+      traceValSeqFn traceValSeqN traceValSeqNFn traceFnSeqN traceShowVal
+      traceShowValMarked showVal traceCall traceCall2 traceCall3
+      traceValIfNot runTests testAllTrue traceCallXml attrNamesToStr;
     inherit (self.misc) maybeEnv defaultMergeArg defaultMerge foldArgs
       maybeAttrNullable maybeAttr ifEnable checkFlag getValue
       checkReqs uniqList uniqListExt condConcat lazyGenericClosure

lib/generators.nix

@@ -355,7 +355,6 @@ rec {
   # PLIST handling
   toPlist = {}: v: let
     isFloat = builtins.isFloat or (x: false);
-    isPath = x: builtins.typeOf x == "path";
     expr = ind: x:  with builtins;
       if x == null  then "" else
       if isBool x   then bool ind x else
@@ -363,7 +362,6 @@ rec {
       if isString x then str ind x else
       if isList x   then list ind x else
       if isAttrs x  then attrs ind x else
-      if isPath x   then str ind (toString x) else
       if isFloat x  then float ind x else
       abort "generators.toPlist: should never happen (v = ${v})";
 
@@ -424,103 +422,8 @@ ${expr "" v}
       (if v then "True" else "False")
     else if isFunction v then
       abort "generators.toDhall: cannot convert a function to Dhall"
-    else if v == null then
+    else if isNull v then
       abort "generators.toDhall: cannot convert a null to Dhall"
     else
       builtins.toJSON v;
-
-  /*
-   Translate a simple Nix expression to Lua representation with occasional
-   Lua-inlines that can be construted by mkLuaInline function.
-
-   Configuration:
-     * multiline - by default is true which results in indented block-like view.
-     * indent - initial indent.
-     * asBindings - by default generate single value, but with this use attrset to set global vars.
-
-   Attention:
-     Regardless of multiline parameter there is no trailing newline.
-
-   Example:
-     generators.toLua {}
-       {
-         cmd = [ "typescript-language-server" "--stdio" ];
-         settings.workspace.library = mkLuaInline ''vim.api.nvim_get_runtime_file("", true)'';
-       }
-     ->
-      {
-        ["cmd"] = {
-          "typescript-language-server",
-          "--stdio"
-        },
-        ["settings"] = {
-          ["workspace"] = {
-            ["library"] = (vim.api.nvim_get_runtime_file("", true))
-          }
-        }
-      }
-
-   Type:
-     toLua :: AttrSet -> Any -> String
-  */
-  toLua = {
-    /* If this option is true, the output is indented with newlines for attribute sets and lists */
-    multiline ? true,
-    /* Initial indentation level */
-    indent ? "",
-    /* Interpret as variable bindings */
-    asBindings ? false,
-  }@args: v:
-    with builtins;
-    let
-      innerIndent = "${indent}  ";
-      introSpace = if multiline then "\n${innerIndent}" else " ";
-      outroSpace = if multiline then "\n${indent}" else " ";
-      innerArgs = args // {
-        indent = if asBindings then indent else innerIndent;
-        asBindings = false;
-      };
-      concatItems = concatStringsSep ",${introSpace}";
-      isLuaInline = { _type ? null, ... }: _type == "lua-inline";
-
-      generatedBindings =
-          assert lib.assertMsg (badVarNames == []) "Bad Lua var names: ${toPretty {} badVarNames}";
-          libStr.concatStrings (
-            lib.attrsets.mapAttrsToList (key: value: "${indent}${key} = ${toLua innerArgs value}\n") v
-            );
-
-      # https://en.wikibooks.org/wiki/Lua_Programming/variable#Variable_names
-      matchVarName = match "[[:alpha:]_][[:alnum:]_]*(\\.[[:alpha:]_][[:alnum:]_]*)*";
-      badVarNames = filter (name: matchVarName name == null) (attrNames v);
-    in
-    if asBindings then
-      generatedBindings
-    else if v == null then
-      "nil"
-    else if isInt v || isFloat v || isString v || isBool v then
-      builtins.toJSON v
-    else if isList v then
-      (if v == [ ] then "{}" else
-      "{${introSpace}${concatItems (map (value: "${toLua innerArgs value}") v)}${outroSpace}}")
-    else if isAttrs v then
-      (
-        if isLuaInline v then
-          "(${v.expr})"
-        else if v == { } then
-          "{}"
-        else
-          "{${introSpace}${concatItems (
-            lib.attrsets.mapAttrsToList (key: value: "[${builtins.toJSON key}] = ${toLua innerArgs value}") v
-            )}${outroSpace}}"
-      )
-    else
-      abort "generators.toLua: type ${typeOf v} is unsupported";
-
-  /*
-   Mark string as Lua expression to be inlined when processed by toLua.
-
-   Type:
-     mkLuaInline :: String -> AttrSet
-  */
-  mkLuaInline = expr: { _type = "lua-inline"; inherit expr; };
 }

lib/kernel.nix

@@ -8,10 +8,9 @@ with lib;
   option = x:
       x // { optional = true; };
 
-  yes      = { tristate    = "y";  optional = false; };
-  no       = { tristate    = "n";  optional = false; };
-  module   = { tristate    = "m";  optional = false; };
-  unset    = { tristate    = null; optional = false; };
+  yes      = { tristate    = "y"; optional = false; };
+  no       = { tristate    = "n"; optional = false; };
+  module   = { tristate    = "m"; optional = false; };
   freeform = x: { freeform = x; optional = false; };
 
   /*

lib/licenses.nix

@@ -81,6 +81,7 @@ in mkLicense lset) ({
   apsl10 = {
     spdxId = "APSL-1.0";
     fullName = "Apple Public Source License 1.0";
+    url = "https://web.archive.org/web/20040701000000*/http://www.opensource.apple.com/apsl/1.0.txt";
   };
 
   apsl20 = {
@@ -108,26 +109,11 @@ in mkLicense lset) ({
     fullName = "Apache License 2.0";
   };
 
-  asl20-llvm = {
-    spdxId = "Apache-2.0 WITH LLVM-exception";
-    fullName = "Apache License 2.0 with LLVM Exceptions";
-  };
-
   bitstreamVera = {
     spdxId = "Bitstream-Vera";
     fullName = "Bitstream Vera Font License";
   };
 
-  bitTorrent10 = {
-     spdxId = "BitTorrent-1.0";
-     fullName = " BitTorrent Open Source License v1.0";
-  };
-
-  bitTorrent11 = {
-    spdxId = "BitTorrent-1.1";
-    fullName = " BitTorrent Open Source License v1.1";
-  };
-
   bola11 = {
     url = "https://blitiri.com.ar/p/bola/";
     fullName = "Buena Onda License Agreement 1.1";
@@ -224,12 +210,6 @@ in mkLicense lset) ({
     fullName = "Creative Commons Zero v1.0 Universal";
   };
 
-  cc-by-nc-nd-30 = {
-    spdxId = "CC-BY-NC-ND-3.0";
-    fullName = "Creative Commons Attribution Non Commercial No Derivative Works 3.0 Unported";
-    free = false;
-  };
-
   cc-by-nc-sa-20 = {
     spdxId = "CC-BY-NC-SA-2.0";
     fullName = "Creative Commons Attribution Non Commercial Share Alike 2.0";
@@ -353,13 +333,6 @@ in mkLicense lset) ({
     free = false;
   };
 
-  ecl20 = {
-    fullName = "Educational Community License, Version 2.0";
-    url = "https://opensource.org/licenses/ECL-2.0";
-    shortName = "ECL 2.0";
-    spdxId = "ECL-2.0";
-  };
-
   efl10 = {
     spdxId = "EFL-1.0";
     fullName = "Eiffel Forum License v1.0";
@@ -585,12 +558,6 @@ in mkLicense lset) ({
     redistributable = false;
   };
 
-  fair = {
-    fullName = "Fair License";
-    spdxId = "Fair";
-    free = true;
-  };
-
   issl = {
     fullName = "Intel Simplified Software License";
     url = "https://software.intel.com/en-us/license/intel-simplified-software-license";
@@ -667,6 +634,11 @@ in mkLicense lset) ({
     url = "https://opensource.franz.com/preamble.html";
   };
 
+  llvm-exception = {
+    spdxId = "LLVM-exception";
+    fullName = "LLVM Exception"; # LLVM exceptions to the Apache 2.0 License
+  };
+
   lppl12 = {
     spdxId = "LPPL-1.2";
     fullName = "LaTeX Project Public License v1.2";
@@ -737,12 +709,7 @@ in mkLicense lset) ({
 
   ncsa = {
     spdxId = "NCSA";
-    fullName = "University of Illinois/NCSA Open Source License";
-  };
-
-  nlpl = {
-    spdxId = "NLPL";
-    fullName = "No Limit Public License";
+    fullName  = "University of Illinois/NCSA Open Source License";
   };
 
   nposl3 = {
@@ -909,13 +876,6 @@ in mkLicense lset) ({
     url = "https://github.com/thestk/stk/blob/master/LICENSE";
   };
 
-  tsl = {
-    shortName = "TSL";
-    fullName = "Timescale License Agreegment";
-    url = "https://github.com/timescale/timescaledb/blob/main/tsl/LICENSE-TIMESCALE";
-    unfree = true;
-  };
-
   tcltk = {
     spdxId = "TCL";
     fullName = "TCL/TK License";

lib/lists.nix

@@ -303,22 +303,10 @@ rec {
     else
       genList (n: first + n) (last - first + 1);
 
-  /* Return a list with `n` copies of an element.
-
-    Type: replicate :: int -> a -> [a]
-
-    Example:
-      replicate 3 "a"
-      => [ "a" "a" "a" ]
-      replicate 2 true
-      => [ true true ]
-  */
-  replicate = n: elem: genList (_: elem) n;
-
   /* Splits the elements of a list in two lists, `right` and
      `wrong`, depending on the evaluation of a predicate.
 
-     Type: (a -> bool) -> [a] -> { right :: [a]; wrong :: [a]; }
+     Type: (a -> bool) -> [a] -> { right :: [a], wrong :: [a] }
 
      Example:
        partition (x: x > 2) [ 5 1 2 3 4 ]
@@ -386,7 +374,7 @@ rec {
   /* Merges two lists of the same size together. If the sizes aren't the same
      the merging stops at the shortest.
 
-     Type: zipLists :: [a] -> [b] -> [{ fst :: a; snd :: b; }]
+     Type: zipLists :: [a] -> [b] -> [{ fst :: a, snd :: b}]
 
      Example:
        zipLists [ 1 2 ] [ "a" "b" ]

lib/meta.nix

@@ -76,9 +76,7 @@ rec {
 
        1. (legacy) a system string.
 
-       2. (modern) a pattern for the entire platform structure (see `lib.systems.inspect.platformPatterns`).
-
-       3. (modern) a pattern for the platform `parsed` field (see `lib.systems.inspect.patterns`).
+       2. (modern) a pattern for the platform `parsed` field.
 
      We can inject these into a pattern for the whole of a structured platform,
      and then match that.
@@ -87,8 +85,6 @@ rec {
       pattern =
         if builtins.isString elem
         then { system = elem; }
-        else if elem?parsed
-        then elem
         else { parsed = elem; };
     in lib.matchAttrs pattern platform;
 

lib/modules.nix

@@ -21,7 +21,6 @@ let
     isBool
     isFunction
     isList
-    isPath
     isString
     length
     mapAttrs
@@ -46,9 +45,6 @@ let
     showOption
     unknownModule
     ;
-  inherit (lib.strings)
-    isConvertibleWithToString
-    ;
 
   showDeclPrefix = loc: decl: prefix:
     " - option(s) with prefix `${showOption (loc ++ [prefix])}' in module `${decl._file}'";
@@ -63,8 +59,39 @@ let
           decls
       ));
 
-  /* See https://nixos.org/manual/nixpkgs/unstable/#module-system-lib-evalModules
-     or file://./../doc/module-system/module-system.chapter.md
+in
+
+rec {
+
+  /*
+    Evaluate a set of modules.  The result is a set with the attributes:
+
+      ‘options’: The nested set of all option declarations,
+
+      ‘config’: The nested set of all option values.
+
+      ‘type’: A module system type representing the module set as a submodule,
+            to be extended by configuration from the containing module set.
+
+            This is also available as the module argument ‘moduleType’.
+
+      ‘extendModules’: A function similar to ‘evalModules’ but building on top
+            of the module set. Its arguments, ‘modules’ and ‘specialArgs’ are
+            added to the existing values.
+
+            Using ‘extendModules’ a few times has no performance impact as long
+            as you only reference the final ‘options’ and ‘config’.
+            If you do reference multiple ‘config’ (or ‘options’) from before and
+            after ‘extendModules’, performance is the same as with multiple
+            ‘evalModules’ invocations, because the new modules' ability to
+            override existing configuration fundamentally requires a new
+            fixpoint to be constructed.
+
+            This is also available as a module argument.
+
+      ‘_module’: A portion of the configuration tree which is elided from
+            ‘config’. It contains some values that are mostly internal to the
+            module system implementation.
 
      !!! Please think twice before adding to this argument list! The more
      that is specified here instead of in the modules themselves the harder
@@ -79,12 +106,8 @@ let
                   # there's _module.args. If specialArgs.modulesPath is defined it will be
                   # used as the base path for disabledModules.
                   specialArgs ? {}
-                , # `class`:
-                  # A nominal type for modules. When set and non-null, this adds a check to
-                  # make sure that only compatible modules are imported.
-                  # This would be remove in the future, Prefer _module.args option instead.
-                  class ? null
-                , args ? {}
+                , # This would be remove in the future, Prefer _module.args option instead.
+                  args ? {}
                 , # This would be remove in the future, Prefer _module.check option instead.
                   check ? true
                 }:
@@ -233,7 +256,6 @@ let
 
       merged =
         let collected = collectModules
-          class
           (specialArgs.modulesPath or "")
           (regularModules ++ [ internalModule ])
           ({ inherit lib options config specialArgs; } // specialArgs);
@@ -310,64 +332,38 @@ let
         prefix ? [],
         }:
           evalModules (evalModulesArgs // {
-            inherit class;
             modules = regularModules ++ modules;
             specialArgs = evalModulesArgs.specialArgs or {} // specialArgs;
             prefix = extendArgs.prefix or evalModulesArgs.prefix or [];
           });
 
       type = lib.types.submoduleWith {
-        inherit modules specialArgs class;
+        inherit modules specialArgs;
       };
 
       result = withWarnings {
-        _type = "configuration";
         options = checked options;
         config = checked (removeAttrs config [ "_module" ]);
         _module = checked (config._module);
         inherit extendModules type;
-        class = class;
       };
     in result;
 
-  # collectModules :: (class: String) -> (modulesPath: String) -> (modules: [ Module ]) -> (args: Attrs) -> [ Module ]
+  # collectModules :: (modulesPath: String) -> (modules: [ Module ]) -> (args: Attrs) -> [ Module ]
   #
   # Collects all modules recursively through `import` statements, filtering out
   # all modules in disabledModules.
-  collectModules = class: let
+  collectModules = let
 
       # Like unifyModuleSyntax, but also imports paths and calls functions if necessary
       loadModule = args: fallbackFile: fallbackKey: m:
-        if isFunction m then
-          unifyModuleSyntax fallbackFile fallbackKey (applyModuleArgs fallbackKey m args)
-        else if isAttrs m then
-          if m._type or "module" == "module" then
-            unifyModuleSyntax fallbackFile fallbackKey m
-          else if m._type == "if" || m._type == "override" then
-            loadModule args fallbackFile fallbackKey { config = m; }
-          else
-            throw (
-              "Could not load a value as a module, because it is of type ${lib.strings.escapeNixString m._type}"
-              + lib.optionalString (fallbackFile != unknownModule) ", in file ${toString fallbackFile}."
-              + lib.optionalString (m._type == "configuration") " If you do intend to import this configuration, please only import the modules that make up the configuration. You may have to create a `let` binding, file or attribute to give yourself access to the relevant modules.\nWhile loading a configuration into the module system is a very sensible idea, it can not be done cleanly in practice."
-               # Extended explanation: That's because a finalized configuration is more than just a set of modules. For instance, it has its own `specialArgs` that, by the nature of `specialArgs` can't be loaded through `imports` or the the `modules` argument. So instead, we have to ask you to extract the relevant modules and use those instead. This way, we keep the module system comparatively simple, and hopefully avoid a bad surprise down the line.
-            )
+        if isFunction m || isAttrs m then
+          unifyModuleSyntax fallbackFile fallbackKey (applyModuleArgsIfFunction fallbackKey m args)
         else if isList m then
           let defs = [{ file = fallbackFile; value = m; }]; in
           throw "Module imports can't be nested lists. Perhaps you meant to remove one level of lists? Definitions: ${showDefs defs}"
         else unifyModuleSyntax (toString m) (toString m) (applyModuleArgsIfFunction (toString m) (import m) args);
 
-      checkModule =
-        if class != null
-        then
-          m:
-            if m._class != null -> m._class == class
-            then m
-            else
-              throw "The module ${m._file or m.key} was imported into ${class} instead of ${m._class}."
-        else
-          m: m;
-
       /*
       Collects all modules recursively into the form
 
@@ -401,13 +397,13 @@ let
           };
         in parentFile: parentKey: initialModules: args: collectResults (imap1 (n: x:
           let
-            module = checkModule (loadModule args parentFile "${parentKey}:anon-${toString n}" x);
+            module = loadModule args parentFile "${parentKey}:anon-${toString n}" x;
             collectedImports = collectStructuredModules module._file module.key module.imports args;
           in {
             key = module.key;
             module = module;
             modules = collectedImports.modules;
-            disabled = (if module.disabledModules != [] then [{ file = module._file; disabled = module.disabledModules; }] else []) ++ collectedImports.disabled;
+            disabled = module.disabledModules ++ collectedImports.disabled;
           }) initialModules);
 
       # filterModules :: String -> { disabled, modules } -> [ Module ]
@@ -416,30 +412,10 @@ let
       # modules recursively. It returns the final list of unique-by-key modules
       filterModules = modulesPath: { disabled, modules }:
         let
-          moduleKey = file: m:
-            if isString m
-            then
-              if builtins.substring 0 1 m == "/"
-              then m
-              else toString modulesPath + "/" + m
-
-            else if isConvertibleWithToString m
-            then
-              if m?key && m.key != toString m
-              then
-                throw "Module `${file}` contains a disabledModules item that is an attribute set that can be converted to a string (${toString m}) but also has a `.key` attribute (${m.key}) with a different value. This makes it ambiguous which module should be disabled."
-              else
-                toString m
-
-            else if m?key
-            then
-              m.key
-
-            else if isAttrs m
-            then throw "Module `${file}` contains a disabledModules item that is an attribute set, presumably a module, that does not have a `key` attribute. This means that the module system doesn't have any means to identify the module that should be disabled. Make sure that you've put the correct value in disabledModules: a string path relative to modulesPath, a path value, or an attribute set with a `key` attribute."
-            else throw "Each disabledModules item must be a path, string, or a attribute set with a key attribute, or a value supported by toString. However, one of the disabledModules items in `${toString file}` is none of that, but is of type ${builtins.typeOf m}.";
-
-          disabledKeys = concatMap ({ file, disabled }: map (moduleKey file) disabled) disabled;
+          moduleKey = m: if isString m && (builtins.substring 0 1 m != "/")
+            then toString modulesPath + "/" + m
+            else toString m;
+          disabledKeys = map moduleKey disabled;
           keyFilter = filter (attrs: ! elem attrs.key disabledKeys);
         in map (attrs: attrs.module) (builtins.genericClosure {
           startSet = keyFilter modules;
@@ -465,12 +441,11 @@ let
         else config;
     in
     if m ? config || m ? options then
-      let badAttrs = removeAttrs m ["_class" "_file" "key" "disabledModules" "imports" "options" "config" "meta" "freeformType"]; in
+      let badAttrs = removeAttrs m ["_file" "key" "disabledModules" "imports" "options" "config" "meta" "freeformType"]; in
       if badAttrs != {} then
         throw "Module `${key}' has an unsupported attribute `${head (attrNames badAttrs)}'. This is caused by introducing a top-level `config' or `options' attribute. Add configuration attributes immediately on the top level instead, or move all of them (namely: ${toString (attrNames badAttrs)}) into the explicit `config' attribute."
       else
         { _file = toString m._file or file;
-          _class = m._class or null;
           key = toString m.key or key;
           disabledModules = m.disabledModules or [];
           imports = m.imports or [];
@@ -481,18 +456,14 @@ let
       # shorthand syntax
       lib.throwIfNot (isAttrs m) "module ${file} (${key}) does not look like a module."
       { _file = toString m._file or file;
-        _class = m._class or null;
         key = toString m.key or key;
         disabledModules = m.disabledModules or [];
         imports = m.require or [] ++ m.imports or [];
         options = {};
-        config = addFreeformType (removeAttrs m ["_class" "_file" "key" "disabledModules" "require" "imports" "freeformType"]);
+        config = addFreeformType (removeAttrs m ["_file" "key" "disabledModules" "require" "imports" "freeformType"]);
       };
 
-  applyModuleArgsIfFunction = key: f: args@{ config, options, lib, ... }:
-    if isFunction f then applyModuleArgs key f args else f;
-
-  applyModuleArgs = key: f: args@{ config, options, lib, ... }:
+  applyModuleArgsIfFunction = key: f: args@{ config, options, lib, ... }: if isFunction f then
     let
       # Module arguments are resolved in a strict manner when attribute set
       # deconstruction is used.  As the arguments are now defined with the
@@ -516,7 +487,9 @@ let
       # context on the explicit arguments of "args" too. This update
       # operator is used to make the "args@{ ... }: with args.lib;" notation
       # works.
-    in f (args // extraArgs);
+    in f (args // extraArgs)
+  else
+    f;
 
   /* Merge a list of modules.  This will recurse over the option
      declarations in all modules, combining them into a single set.
@@ -570,19 +543,15 @@ let
         zipAttrsWith (n: concatLists)
           (map (module: let subtree = module.${attr}; in
               if !(builtins.isAttrs subtree) then
-                throw (if attr == "config" then ''
-                  You're trying to define a value of type `${builtins.typeOf subtree}'
-                  rather than an attribute set for the option
+                throw ''
+                  You're trying to declare a value of type `${builtins.typeOf subtree}'
+                  rather than an attribute-set for the option
                   `${builtins.concatStringsSep "." prefix}'!
 
                   This usually happens if `${builtins.concatStringsSep "." prefix}' has option
                   definitions inside that are not matched. Please check how to properly define
                   this option by e.g. referring to `man 5 configuration.nix'!
-                '' else ''
-                  An option declaration for `${builtins.concatStringsSep "." prefix}' has type
-                  `${builtins.typeOf subtree}' rather than an attribute set.
-                  Did you mean to define this outside of `options'?
-                '')
+                ''
               else
                 mapAttrs (n: f module) subtree
               ) modules);
@@ -1221,67 +1190,4 @@ let
     _file = file;
     config = lib.importTOML file;
   };
-
-  private = lib.mapAttrs
-    (k: lib.warn "External use of `lib.modules.${k}` is deprecated. If your use case isn't covered by non-deprecated functions, we'd like to know more and perhaps support your use case well, instead of providing access to these low level functions. In this case please open an issue in https://github.com/nixos/nixpkgs/issues/.")
-    {
-      inherit
-        applyModuleArgsIfFunction
-        dischargeProperties
-        evalOptionValue
-        mergeModules
-        mergeModules'
-        pushDownProperties
-        unifyModuleSyntax
-        ;
-      collectModules = collectModules null;
-    };
-
-in
-private //
-{
-  # NOTE: not all of these functions are necessarily public interfaces; some
-  #       are just needed by types.nix, but are not meant to be consumed
-  #       externally.
-  inherit
-    defaultOrderPriority
-    defaultOverridePriority
-    defaultPriority
-    doRename
-    evalModules
-    filterOverrides
-    filterOverrides'
-    fixMergeModules
-    fixupOptionType  # should be private?
-    importJSON
-    importTOML
-    mergeDefinitions
-    mergeOptionDecls  # should be private?
-    mkAfter
-    mkAliasAndWrapDefinitions
-    mkAliasAndWrapDefsWithPriority
-    mkAliasDefinitions
-    mkAliasIfDef
-    mkAliasOptionModule
-    mkAliasOptionModuleMD
-    mkAssert
-    mkBefore
-    mkChangedOptionModule
-    mkDefault
-    mkDerivedConfig
-    mkFixStrictness
-    mkForce
-    mkIf
-    mkImageMediaOverride
-    mkMerge
-    mkMergedOptionModule
-    mkOptionDefault
-    mkOrder
-    mkOverride
-    mkRemovedOptionModule
-    mkRenamedOptionModule
-    mkRenamedOptionModuleWith
-    mkVMOverride
-    setDefaultModuleLocation
-    sortProperties;
 }

lib/options.nix

@@ -36,12 +36,6 @@ let
   inherit (lib.types)
     mkOptionType
     ;
-  inherit (lib.lists)
-    last
-    ;
-  prioritySuggestion = ''
-   Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.
-  '';
 in
 rec {
 
@@ -110,26 +104,17 @@ rec {
   /* Creates an Option attribute set for an option that specifies the
      package a module should use for some purpose.
 
-     The package is specified in the third argument under `default` as a list of strings
-     representing its attribute path in nixpkgs (or another package set).
-     Because of this, you need to pass nixpkgs itself (or a subset) as the first argument.
+     The package is specified as a list of strings representing its attribute path in nixpkgs.
 
-     The second argument may be either a string or a list of strings.
-     It provides the display name of the package in the description of the generated option
-     (using only the last element if the passed value is a list)
-     and serves as the fallback value for the `default` argument.
+     Because of this, you need to pass nixpkgs itself as the first argument.
 
-     To include extra information in the description, pass `extraDescription` to
-     append arbitrary text to the generated description.
-     You can also pass an `example` value, either a literal string or an attribute path.
+     The second argument is the name of the option, used in the description "The <name> package to use.".
 
-     The default argument can be omitted if the provided name is
-     an attribute of pkgs (if name is a string) or a
-     valid attribute path in pkgs (if name is a list).
+     You can also pass an example value, either a literal string or a package's attribute path.
 
-     If you wish to explicitly provide no default, pass `null` as `default`.
+     You can omit the default path if the name of the option is also attribute path in nixpkgs.
 
-     Type: mkPackageOption :: pkgs -> (string|[string]) -> { default? :: [string], example? :: null|string|[string], extraDescription? :: string } -> option
+     Type: mkPackageOption :: pkgs -> string -> { default :: [string], example :: null | string | [string] } -> option
 
      Example:
        mkPackageOption pkgs "hello" { }
@@ -141,46 +126,27 @@ rec {
          example = "pkgs.haskell.packages.ghc92.ghc.withPackages (hkgs: [ hkgs.primes ])";
        }
        => { _type = "option"; default = «derivation /nix/store/jxx55cxsjrf8kyh3fp2ya17q99w7541r-ghc-8.10.7.drv»; defaultText = { ... }; description = "The GHC package to use."; example = { ... }; type = { ... }; }
-
-     Example:
-       mkPackageOption pkgs [ "python39Packages" "pytorch" ] {
-         extraDescription = "This is an example and doesn't actually do anything.";
-       }
-       => { _type = "option"; default = «derivation /nix/store/gvqgsnc4fif9whvwd9ppa568yxbkmvk8-python3.9-pytorch-1.10.2.drv»; defaultText = { ... }; description = "The pytorch package to use. This is an example and doesn't actually do anything."; type = { ... }; }
-
   */
   mkPackageOption =
-    # Package set (a specific version of nixpkgs or a subset)
+    # Package set (a specific version of nixpkgs)
     pkgs:
       # Name for the package, shown in option description
       name:
-      {
-        # The attribute path where the default package is located (may be omitted)
-        default ? name,
-        # A string or an attribute path to use as an example (may be omitted)
-        example ? null,
-        # Additional text to include in the option description (may be omitted)
-        extraDescription ? "",
-      }:
-      let
-        name' = if isList name then last name else name;
-        default' = if isList default then default else [ default ];
-        defaultPath = concatStringsSep "." default';
-        defaultValue = attrByPath default'
-          (throw "${defaultPath} cannot be found in pkgs") pkgs;
+      { default ? [ name ], example ? null }:
+      let default' = if !isList default then [ default ] else default;
       in mkOption {
-        defaultText = literalExpression ("pkgs." + defaultPath);
         type = lib.types.package;
-        description = "The ${name'} package to use."
-          + (if extraDescription == "" then "" else " ") + extraDescription;
-        ${if default != null then "default" else null} = defaultValue;
+        description = "The ${name} package to use.";
+        default = attrByPath default'
+          (throw "${concatStringsSep "." default'} cannot be found in pkgs") pkgs;
+        defaultText = literalExpression ("pkgs." + concatStringsSep "." default');
         ${if example != null then "example" else null} = literalExpression
           (if isList example then "pkgs." + concatStringsSep "." example else example);
       };
 
   /* Like mkPackageOption, but emit an mdDoc description instead of DocBook. */
-  mkPackageOptionMD = pkgs: name: extra:
-    let option = mkPackageOption pkgs name extra;
+  mkPackageOptionMD = args: name: extra:
+    let option = mkPackageOption args name extra;
     in option // { description = lib.mdDoc option.description; };
 
   /* This option accepts anything, but it does not produce any result.
@@ -218,7 +184,7 @@ rec {
     if length defs == 1
     then (head defs).value
     else assert length defs > 1;
-      throw "The option `${showOption loc}' is defined multiple times while it's expected to be unique.\n${message}\nDefinition values:${showDefs defs}\n${prioritySuggestion}";
+      throw "The option `${showOption loc}' is defined multiple times.\n${message}\nDefinition values:${showDefs defs}";
 
   /* "Merge" option definitions by checking that they all have the same value. */
   mergeEqualOption = loc: defs:
@@ -229,13 +195,13 @@ rec {
     else if length defs == 1 then (head defs).value
     else (foldl' (first: def:
       if def.value != first.value then
-        throw "The option `${showOption loc}' has conflicting definition values:${showDefs [ first def ]}\n${prioritySuggestion}"
+        throw "The option `${showOption loc}' has conflicting definition values:${showDefs [ first def ]}"
       else
         first) (head defs) (tail defs)).value;
 
   /* Extracts values of all "value" keys of the given list.
 
-     Type: getValues :: [ { value :: a; } ] -> [a]
+     Type: getValues :: [ { value :: a } ] -> [a]
 
      Example:
        getValues [ { value = 1; } { value = 2; } ] // => [ 1 2 ]
@@ -245,7 +211,7 @@ rec {
 
   /* Extracts values of all "file" keys of the given list
 
-     Type: getFiles :: [ { file :: a; } ] -> [a]
+     Type: getFiles :: [ { file :: a } ] -> [a]
 
      Example:
        getFiles [ { file = "file1"; } { file = "file2"; } ] // => [ "file1" "file2" ]
@@ -368,17 +334,19 @@ rec {
 
   # Helper functions.
 
-  /* Convert an option, described as a list of the option parts to a
-     human-readable version.
+  /* Convert an option, described as a list of the option parts in to a
+     safe, human readable version.
 
      Example:
        (showOption ["foo" "bar" "baz"]) == "foo.bar.baz"
-       (showOption ["foo" "bar.baz" "tux"]) == "foo.\"bar.baz\".tux"
-       (showOption ["windowManager" "2bwm" "enable"]) == "windowManager.\"2bwm\".enable"
+       (showOption ["foo" "bar.baz" "tux"]) == "foo.bar.baz.tux"
 
      Placeholders will not be quoted as they are not actual values:
        (showOption ["foo" "*" "bar"]) == "foo.*.bar"
        (showOption ["foo" "<name>" "bar"]) == "foo.<name>.bar"
+
+     Unlike attributes, options can also start with numbers:
+       (showOption ["windowManager" "2bwm" "enable"]) == "windowManager.2bwm.enable"
   */
   showOption = parts: let
     escapeOptionPart = part:

lib/path/default.nix

@@ -4,7 +4,6 @@ let
 
   inherit (builtins)
     isString
-    isPath
     split
     match
     ;
@@ -15,9 +14,6 @@ let
     last
     genList
     elemAt
-    all
-    concatMap
-    foldl'
     ;
 
   inherit (lib.strings)
@@ -29,10 +25,6 @@ let
     assertMsg
     ;
 
-  inherit (lib.path.subpath)
-    isValid
-    ;
-
   # Return the reason why a subpath is invalid, or `null` if it's valid
   subpathInvalidReason = value:
     if ! isString value then
@@ -102,52 +94,6 @@ let
 
 in /* No rec! Add dependencies on this file at the top. */ {
 
-  /* Append a subpath string to a path.
-
-    Like `path + ("/" + string)` but safer, because it errors instead of returning potentially surprising results.
-    More specifically, it checks that the first argument is a [path value type](https://nixos.org/manual/nix/stable/language/values.html#type-path"),
-    and that the second argument is a valid subpath string (see `lib.path.subpath.isValid`).
-
-    Type:
-      append :: Path -> String -> Path
-
-    Example:
-      append /foo "bar/baz"
-      => /foo/bar/baz
-
-      # subpaths don't need to be normalised
-      append /foo "./bar//baz/./"
-      => /foo/bar/baz
-
-      # can append to root directory
-      append /. "foo/bar"
-      => /foo/bar
-
-      # first argument needs to be a path value type
-      append "/foo" "bar"
-      => <error>
-
-      # second argument needs to be a valid subpath string
-      append /foo /bar
-      => <error>
-      append /foo ""
-      => <error>
-      append /foo "/bar"
-      => <error>
-      append /foo "../bar"
-      => <error>
-  */
-  append =
-    # The absolute path to append to
-    path:
-    # The subpath string to append
-    subpath:
-    assert assertMsg (isPath path) ''
-      lib.path.append: The first argument is of type ${builtins.typeOf path}, but a path was expected'';
-    assert assertMsg (isValid subpath) ''
-      lib.path.append: Second argument is not a valid subpath string:
-          ${subpathInvalidReason subpath}'';
-    path + ("/" + subpath);
 
   /* Whether a value is a valid subpath string.
 
@@ -187,86 +133,10 @@ in /* No rec! Add dependencies on this file at the top. */ {
     subpath.isValid "./foo//bar/"
     => true
   */
-  subpath.isValid =
-    # The value to check
-    value:
+  subpath.isValid = value:
     subpathInvalidReason value == null;
 
 
-  /* Join subpath strings together using `/`, returning a normalised subpath string.
-
-    Like `concatStringsSep "/"` but safer, specifically:
-
-    - All elements must be valid subpath strings, see `lib.path.subpath.isValid`
-
-    - The result gets normalised, see `lib.path.subpath.normalise`
-
-    - The edge case of an empty list gets properly handled by returning the neutral subpath `"./."`
-
-    Laws:
-
-    - Associativity:
-
-          subpath.join [ x (subpath.join [ y z ]) ] == subpath.join [ (subpath.join [ x y ]) z ]
-
-    - Identity - `"./."` is the neutral element for normalised paths:
-
-          subpath.join [ ] == "./."
-          subpath.join [ (subpath.normalise p) "./." ] == subpath.normalise p
-          subpath.join [ "./." (subpath.normalise p) ] == subpath.normalise p
-
-    - Normalisation - the result is normalised according to `lib.path.subpath.normalise`:
-
-          subpath.join ps == subpath.normalise (subpath.join ps)
-
-    - For non-empty lists, the implementation is equivalent to normalising the result of `concatStringsSep "/"`.
-      Note that the above laws can be derived from this one.
-
-          ps != [] -> subpath.join ps == subpath.normalise (concatStringsSep "/" ps)
-
-    Type:
-      subpath.join :: [ String ] -> String
-
-    Example:
-      subpath.join [ "foo" "bar/baz" ]
-      => "./foo/bar/baz"
-
-      # normalise the result
-      subpath.join [ "./foo" "." "bar//./baz/" ]
-      => "./foo/bar/baz"
-
-      # passing an empty list results in the current directory
-      subpath.join [ ]
-      => "./."
-
-      # elements must be valid subpath strings
-      subpath.join [ /foo ]
-      => <error>
-      subpath.join [ "" ]
-      => <error>
-      subpath.join [ "/foo" ]
-      => <error>
-      subpath.join [ "../foo" ]
-      => <error>
-  */
-  subpath.join =
-    # The list of subpaths to join together
-    subpaths:
-    # Fast in case all paths are valid
-    if all isValid subpaths
-    then joinRelPath (concatMap splitRelPath subpaths)
-    else
-      # Otherwise we take our time to gather more info for a better error message
-      # Strictly go through each path, throwing on the first invalid one
-      # Tracks the list index in the fold accumulator
-      foldl' (i: path:
-        if isValid path
-        then i + 1
-        else throw ''
-          lib.path.subpath.join: Element at index ${toString i} is not a valid subpath string:
-              ${subpathInvalidReason path}''
-      ) 0 subpaths;
-
   /* Normalise a subpath. Throw an error if the subpath isn't valid, see
   `lib.path.subpath.isValid`
 
@@ -280,11 +150,11 @@ in /* No rec! Add dependencies on this file at the top. */ {
 
   Laws:
 
-  - Idempotency - normalising multiple times gives the same result:
+  - (Idempotency) Normalising multiple times gives the same result:
 
         subpath.normalise (subpath.normalise p) == subpath.normalise p
 
-  - Uniqueness - there's only a single normalisation for the paths that lead to the same file system node:
+  - (Uniqueness) There's only a single normalisation for the paths that lead to the same file system node:
 
         subpath.normalise p != subpath.normalise q -> $(realpath ${p}) != $(realpath ${q})
 
@@ -340,12 +210,9 @@ in /* No rec! Add dependencies on this file at the top. */ {
     subpath.normalise "/foo"
     => <error>
   */
-  subpath.normalise =
-    # The subpath string to normalise
-    subpath:
-    assert assertMsg (isValid subpath) ''
-      lib.path.subpath.normalise: Argument is not a valid subpath string:
-          ${subpathInvalidReason subpath}'';
-    joinRelPath (splitRelPath subpath);
+  subpath.normalise = path:
+    assert assertMsg (subpathInvalidReason path == null)
+      "lib.path.subpath.normalise: Argument is not a valid subpath string: ${subpathInvalidReason path}";
+    joinRelPath (splitRelPath path);
 
 }

lib/path/tests/unit.nix

@@ -3,44 +3,9 @@
 { libpath }:
 let
   lib = import libpath;
-  inherit (lib.path) append subpath;
+  inherit (lib.path) subpath;
 
   cases = lib.runTests {
-    # Test examples from the lib.path.append documentation
-    testAppendExample1 = {
-      expr = append /foo "bar/baz";
-      expected = /foo/bar/baz;
-    };
-    testAppendExample2 = {
-      expr = append /foo "./bar//baz/./";
-      expected = /foo/bar/baz;
-    };
-    testAppendExample3 = {
-      expr = append /. "foo/bar";
-      expected = /foo/bar;
-    };
-    testAppendExample4 = {
-      expr = (builtins.tryEval (append "/foo" "bar")).success;
-      expected = false;
-    };
-    testAppendExample5 = {
-      expr = (builtins.tryEval (append /foo /bar)).success;
-      expected = false;
-    };
-    testAppendExample6 = {
-      expr = (builtins.tryEval (append /foo "")).success;
-      expected = false;
-    };
-    testAppendExample7 = {
-      expr = (builtins.tryEval (append /foo "/bar")).success;
-      expected = false;
-    };
-    testAppendExample8 = {
-      expr = (builtins.tryEval (append /foo "../bar")).success;
-      expected = false;
-    };
-
-    # Test examples from the lib.path.subpath.isValid documentation
     testSubpathIsValidExample1 = {
       expr = subpath.isValid null;
       expected = false;
@@ -65,7 +30,6 @@ let
       expr = subpath.isValid "./foo//bar/";
       expected = true;
     };
-    # Some extra tests
     testSubpathIsValidTwoDotsEnd = {
       expr = subpath.isValid "foo/..";
       expected = false;
@@ -107,37 +71,6 @@ let
       expected = true;
     };
 
-    # Test examples from the lib.path.subpath.join documentation
-    testSubpathJoinExample1 = {
-      expr = subpath.join [ "foo" "bar/baz" ];
-      expected = "./foo/bar/baz";
-    };
-    testSubpathJoinExample2 = {
-      expr = subpath.join [ "./foo" "." "bar//./baz/" ];
-      expected = "./foo/bar/baz";
-    };
-    testSubpathJoinExample3 = {
-      expr = subpath.join [ ];
-      expected = "./.";
-    };
-    testSubpathJoinExample4 = {
-      expr = (builtins.tryEval (subpath.join [ /foo ])).success;
-      expected = false;
-    };
-    testSubpathJoinExample5 = {
-      expr = (builtins.tryEval (subpath.join [ "" ])).success;
-      expected = false;
-    };
-    testSubpathJoinExample6 = {
-      expr = (builtins.tryEval (subpath.join [ "/foo" ])).success;
-      expected = false;
-    };
-    testSubpathJoinExample7 = {
-      expr = (builtins.tryEval (subpath.join [ "../foo" ])).success;
-      expected = false;
-    };
-
-    # Test examples from the lib.path.subpath.normalise documentation
     testSubpathNormaliseExample1 = {
       expr = subpath.normalise "foo//bar";
       expected = "./foo/bar";
@@ -174,7 +107,6 @@ let
       expr = (builtins.tryEval (subpath.normalise "/foo")).success;
       expected = false;
     };
-    # Some extra tests
     testSubpathNormaliseIsValidDots = {
       expr = subpath.normalise "./foo/.bar/.../baz...qux";
       expected = "./foo/.bar/.../baz...qux";

lib/strings.nix

@@ -2,11 +2,7 @@
 { lib }:
 let
 
-  inherit (builtins) length;
-
-  inherit (lib.trivial) warnIf;
-
-asciiTable = import ./ascii-table.nix;
+inherit (builtins) length;
 
 in
 
@@ -132,17 +128,6 @@ rec {
     # List of input strings
     list: concatStringsSep sep (lib.imap1 f list);
 
-  /* Concatenate a list of strings, adding a newline at the end of each one.
-     Defined as `concatMapStrings (s: s + "\n")`.
-
-     Type: concatLines :: [string] -> string
-
-     Example:
-       concatLines [ "foo" "bar" ]
-       => "foo\nbar\n"
-  */
-  concatLines = concatMapStrings (s: s + "\n");
-
   /* Construct a Unix-style, colon-separated search path consisting of
      the given `subDir` appended to each of the given paths.
 
@@ -209,20 +194,7 @@ rec {
        normalizePath "/a//b///c/"
        => "/a/b/c/"
   */
-  normalizePath = s:
-    warnIf
-      (isPath s)
-      ''
-        lib.strings.normalizePath: The argument (${toString s}) is a path value, but only strings are supported.
-            Path values are always normalised in Nix, so there's no need to call this function on them.
-            This function also copies the path to the Nix store and returns the store path, the same as "''${path}" will, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-      (
-        builtins.foldl'
-          (x: y: if y == "/" && hasSuffix "/" x then x else x+y)
-          ""
-          (stringToCharacters s)
-      );
+  normalizePath = s: (builtins.foldl' (x: y: if y == "/" && hasSuffix "/" x then x else x+y) "" (stringToCharacters s));
 
   /* Depending on the boolean `cond', return either the given string
      or the empty string. Useful to concatenate against a bigger string.
@@ -255,17 +227,7 @@ rec {
     # Prefix to check for
     pref:
     # Input string
-    str:
-    # Before 23.05, paths would be copied to the store before converting them
-    # to strings and comparing. This was surprising and confusing.
-    warnIf
-      (isPath pref)
-      ''
-        lib.strings.hasPrefix: The first argument (${toString pref}) is a path value, but only strings are supported.
-            There is almost certainly a bug in the calling code, since this function always returns `false` in such a case.
-            This function also copies the path to the Nix store, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-      (substring 0 (stringLength pref) str == pref);
+    str: substring 0 (stringLength pref) str == pref;
 
   /* Determine whether a string has given suffix.
 
@@ -285,20 +247,8 @@ rec {
     let
       lenContent = stringLength content;
       lenSuffix = stringLength suffix;
-    in
-    # Before 23.05, paths would be copied to the store before converting them
-    # to strings and comparing. This was surprising and confusing.
-    warnIf
-      (isPath suffix)
-      ''
-        lib.strings.hasSuffix: The first argument (${toString suffix}) is a path value, but only strings are supported.
-            There is almost certainly a bug in the calling code, since this function always returns `false` in such a case.
-            This function also copies the path to the Nix store, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-      (
-        lenContent >= lenSuffix
-        && substring (lenContent - lenSuffix) lenContent content == suffix
-      );
+    in lenContent >= lenSuffix &&
+       substring (lenContent - lenSuffix) lenContent content == suffix;
 
   /* Determine whether a string contains the given infix
 
@@ -315,16 +265,7 @@ rec {
       => false
   */
   hasInfix = infix: content:
-    # Before 23.05, paths would be copied to the store before converting them
-    # to strings and comparing. This was surprising and confusing.
-    warnIf
-      (isPath infix)
-      ''
-        lib.strings.hasInfix: The first argument (${toString infix}) is a path value, but only strings are supported.
-            There is almost certainly a bug in the calling code, since this function always returns `false` in such a case.
-            This function also copies the path to the Nix store, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-      (builtins.match ".*${escapeRegex infix}.*" "${content}" != null);
+    builtins.match ".*${escapeRegex infix}.*" "${content}" != null;
 
   /* Convert a string to a list of characters (i.e. singleton strings).
      This allows you to, e.g., map a function over each character.  However,
@@ -375,7 +316,9 @@ rec {
        => 40
 
   */
-  charToInt = c: builtins.getAttr c asciiTable;
+  charToInt = let
+    table = import ./ascii-table.nix;
+  in c: builtins.getAttr c table;
 
   /* Escape occurrence of the elements of `list` in `string` by
      prefixing it with a backslash.
@@ -401,21 +344,6 @@ rec {
   */
   escapeC = list: replaceStrings list (map (c: "\\x${ toLower (lib.toHexString (charToInt c))}") list);
 
-  /* Escape the string so it can be safely placed inside a URL
-     query.
-
-     Type: escapeURL :: string -> string
-
-     Example:
-       escapeURL "foo/bar baz"
-       => "foo%2Fbar%20baz"
-  */
-  escapeURL = let
-    unreserved = [ "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z" "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "-" "_" "." "~" ];
-    toEscape = builtins.removeAttrs asciiTable unreserved;
-  in
-    replaceStrings (builtins.attrNames toEscape) (lib.mapAttrsToList (_: c: "%${fixedWidthString 2 "0" (lib.toHexString c)}") toEscape);
-
   /* Quote string to be used safely within the Bourne shell.
 
      Type: escapeShellArg :: string -> string
@@ -616,23 +544,14 @@ rec {
     prefix:
     # Input string
     str:
-    # Before 23.05, paths would be copied to the store before converting them
-    # to strings and comparing. This was surprising and confusing.
-    warnIf
-      (isPath prefix)
-      ''
-        lib.strings.removePrefix: The first argument (${toString prefix}) is a path value, but only strings are supported.
-            There is almost certainly a bug in the calling code, since this function never removes any prefix in such a case.
-            This function also copies the path to the Nix store, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-    (let
+    let
       preLen = stringLength prefix;
       sLen = stringLength str;
     in
-      if substring 0 preLen str == prefix then
+      if hasPrefix prefix str then
         substring preLen (sLen - preLen) str
       else
-        str);
+        str;
 
   /* Return a string without the specified suffix, if the suffix matches.
 
@@ -649,23 +568,14 @@ rec {
     suffix:
     # Input string
     str:
-    # Before 23.05, paths would be copied to the store before converting them
-    # to strings and comparing. This was surprising and confusing.
-    warnIf
-      (isPath suffix)
-      ''
-        lib.strings.removeSuffix: The first argument (${toString suffix}) is a path value, but only strings are supported.
-            There is almost certainly a bug in the calling code, since this function never removes any suffix in such a case.
-            This function also copies the path to the Nix store, which may not be what you want.
-            This behavior is deprecated and will throw an error in the future.''
-    (let
+    let
       sufLen = stringLength suffix;
       sLen = stringLength str;
     in
       if sufLen <= sLen && suffix == substring (sLen - sufLen) sufLen str then
         substring 0 (sLen - sufLen) str
       else
-        str);
+        str;
 
   /* Return true if string v1 denotes a version older than v2.
 

lib/systems/architectures.nix

@@ -40,21 +40,14 @@ rec {
   # a superior CPU has all the features of an inferior and is able to build and test code for it
   inferiors = {
     # x86_64 Intel
-    # https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
     default        = [ ];
     westmere       = [ ];
-    sandybridge    = [ "westmere"       ] ++ inferiors.westmere;
-    ivybridge      = [ "sandybridge"    ] ++ inferiors.sandybridge;
-    haswell        = [ "ivybridge"      ] ++ inferiors.ivybridge;
-    broadwell      = [ "haswell"        ] ++ inferiors.haswell;
-    skylake        = [ "broadwell"      ] ++ inferiors.broadwell;
-    skylake-avx512 = [ "skylake"        ] ++ inferiors.skylake;
-    cannonlake     = [ "skylake-avx512" ] ++ inferiors.skylake-avx512;
-    icelake-client = [ "cannonlake"     ] ++ inferiors.cannonlake;
-    icelake-server = [ "icelake-client" ] ++ inferiors.icelake-client;
-    cascadelake    = [ "skylake-avx512" ] ++ inferiors.cannonlake;
-    cooperlake     = [ "cascadelake"    ] ++ inferiors.cascadelake;
-    tigerlake      = [ "icelake-server" ] ++ inferiors.icelake-server;
+    sandybridge    = [ "westmere"    ] ++ inferiors.westmere;
+    ivybridge      = [ "sandybridge" ] ++ inferiors.sandybridge;
+    haswell        = [ "ivybridge"   ] ++ inferiors.ivybridge;
+    broadwell      = [ "haswell"     ] ++ inferiors.haswell;
+    skylake        = [ "broadwell"   ] ++ inferiors.broadwell;
+    skylake-avx512 = [ "skylake"     ] ++ inferiors.skylake;
 
     # x86_64 AMD
     # TODO: fill this (need testing)

lib/systems/default.nix

@@ -136,12 +136,10 @@ rec {
         else if final.isPower then "powerpc"
         else if final.isRiscV then "riscv"
         else if final.isS390 then "s390"
-        else if final.isLoongArch64 then "loongarch"
         else final.parsed.cpu.name;
 
       qemuArch =
         if final.isAarch32 then "arm"
-        else if final.isS390 && !final.isS390x then null
         else if final.isx86_64 then "x86_64"
         else if final.isx86 then "i386"
         else final.uname.processor;
@@ -186,7 +184,6 @@ rec {
               pulseSupport = false;
               smbdSupport = false;
               seccompSupport = false;
-              enableDocs = false;
               hostCpuTargets = [ "${final.qemuArch}-linux-user" ];
             };
             wine = (pkgs.winePackagesFor "wine${toString final.parsed.cpu.bits}").minimal;
@@ -196,7 +193,7 @@ rec {
           then "${pkgs.runtimeShell} -c '\"$@\"' --"
           else if final.isWindows
           then "${wine}/bin/wine${lib.optionalString (final.parsed.cpu.bits == 64) "64"}"
-          else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux && final.qemuArch != null
+          else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux
           then "${qemu-user}/bin/qemu-${final.qemuArch}"
           else if final.isWasi
           then "${pkgs.wasmtime}/bin/wasmtime"

lib/systems/doubles.nix

@@ -22,11 +22,11 @@ let
     "x86_64-solaris"
 
     # JS
-    "javascript-ghcjs"
+    "js-ghcjs"
 
     # Linux
     "aarch64-linux" "armv5tel-linux" "armv6l-linux" "armv7a-linux"
-    "armv7l-linux" "i686-linux" "loongarch64-linux" "m68k-linux" "microblaze-linux"
+    "armv7l-linux" "i686-linux" "m68k-linux" "microblaze-linux"
     "microblazeel-linux" "mipsel-linux" "mips64el-linux" "powerpc64-linux"
     "powerpc64le-linux" "riscv32-linux" "riscv64-linux" "s390-linux"
     "s390x-linux" "x86_64-linux"
@@ -86,7 +86,6 @@ in {
   m68k          = filterDoubles predicates.isM68k;
   s390          = filterDoubles predicates.isS390;
   s390x         = filterDoubles predicates.isS390x;
-  loongarch64   = filterDoubles predicates.isLoongArch64;
   js            = filterDoubles predicates.isJavaScript;
 
   bigEndian     = filterDoubles predicates.isBigEndian;

lib/systems/examples.nix

@@ -135,10 +135,6 @@ rec {
     libc = "newlib";
   };
 
-  loongarch64-linux = {
-    config = "loongarch64-unknown-linux-gnu";
-  };
-
   mmix = {
     config = "mmix-unknown-mmixware";
     libc = "newlib";
@@ -333,9 +329,6 @@ rec {
 
   # Ghcjs
   ghcjs = {
-    # This triple is special to GHC/Cabal/GHCJS and not recognized by autotools
-    # See: https://gitlab.haskell.org/ghc/ghc/-/commit/6636b670233522f01d002c9b97827d00289dbf5c
-    # https://github.com/ghcjs/ghcjs/issues/53
-    config = "javascript-unknown-ghcjs";
+    config = "js-unknown-ghcjs";
   };
 }

lib/systems/inspect.nix

@@ -7,16 +7,7 @@ let abis_ = abis; in
 let abis = lib.mapAttrs (_: abi: builtins.removeAttrs abi [ "assertions" ]) abis_; in
 
 rec {
-  # these patterns are to be matched against {host,build,target}Platform.parsed
   patterns = rec {
-    # The patterns below are lists in sum-of-products form.
-    #
-    # Each attribute is list of product conditions; non-list values are treated
-    # as a singleton list.  If *any* product condition in the list matches then
-    # the predicate matches.  Each product condition is tested by
-    # `lib.attrsets.matchAttrs`, which requires a match on *all* attributes of
-    # the product.
-
     isi686         = { cpu = cpuTypes.i686; };
     isx86_32       = { cpu = { family = "x86"; bits = 32; }; };
     isx86_64       = { cpu = { family = "x86"; bits = 64; }; };
@@ -57,8 +48,7 @@ rec {
     isM68k         = { cpu = { family = "m68k"; }; };
     isS390         = { cpu = { family = "s390"; }; };
     isS390x        = { cpu = { family = "s390"; bits = 64; }; };
-    isLoongArch64  = { cpu = { family = "loongarch"; bits = 64; }; };
-    isJavaScript   = { cpu = cpuTypes.javascript; };
+    isJavaScript   = { cpu = cpuTypes.js; };
 
     is32bit        = { cpu = { bits = 32; }; };
     is64bit        = { cpu = { bits = 64; }; };
@@ -91,13 +81,8 @@ rec {
     isMusl         = with abis; map (a: { abi = a; }) [ musl musleabi musleabihf muslabin32 muslabi64 ];
     isUClibc       = with abis; map (a: { abi = a; }) [ uclibc uclibceabi uclibceabihf ];
 
-    isEfi = [
-      { cpu = { family = "arm"; version = "6"; }; }
-      { cpu = { family = "arm"; version = "7"; }; }
-      { cpu = { family = "arm"; version = "8"; }; }
-      { cpu = { family = "riscv"; }; }
-      { cpu = { family = "x86"; }; }
-    ];
+    isEfi          = map (family: { cpu.family = family; })
+                       [ "x86" "arm" "aarch64" "riscv" ];
   };
 
   matchAnyAttrs = patterns:
@@ -105,13 +90,4 @@ rec {
     else matchAttrs patterns;
 
   predicates = mapAttrs (_: matchAnyAttrs) patterns;
-
-  # these patterns are to be matched against the entire
-  # {host,build,target}Platform structure; they include a `parsed={}` marker so
-  # that `lib.meta.availableOn` can distinguish them from the patterns which
-  # apply only to the `parsed` field.
-
-  platformPatterns = mapAttrs (_: p: { parsed = {}; } // p) {
-    isStatic = { isStatic = true; };
-  };
 }

lib/systems/parse.nix

@@ -131,9 +131,7 @@ rec {
 
     or1k     = { bits = 32; significantByte = bigEndian; family = "or1k"; };
 
-    loongarch64 = { bits = 64; significantByte = littleEndian; family = "loongarch"; };
-
-    javascript = { bits = 32; significantByte = littleEndian; family = "javascript"; };
+    js       = { bits = 32; significantByte = littleEndian; family = "js"; };
   };
 
   # GNU build systems assume that older NetBSD architectures are using a.out.
@@ -184,13 +182,24 @@ rec {
     (b == armv7l && isCompatible a armv7a)
     (b == armv7l && isCompatible a armv7r)
     (b == armv7l && isCompatible a armv7m)
+    (b == armv7a && isCompatible a armv8a)
+    (b == armv7r && isCompatible a armv8a)
+    (b == armv7m && isCompatible a armv8a)
+    (b == armv7a && isCompatible a armv8r)
+    (b == armv7r && isCompatible a armv8r)
+    (b == armv7m && isCompatible a armv8r)
+    (b == armv7a && isCompatible a armv8m)
+    (b == armv7r && isCompatible a armv8m)
+    (b == armv7m && isCompatible a armv8m)
 
     # ARMv8
-    (b == aarch64 && a == armv8a)
-    (b == armv8a && isCompatible a aarch64)
     (b == armv8r && isCompatible a armv8a)
     (b == armv8m && isCompatible a armv8a)
 
+    # XXX: not always true! Some arm64 cpus don’t support arm32 mode.
+    (b == aarch64 && a == armv8a)
+    (b == armv8a && isCompatible a aarch64)
+
     # PowerPC
     (b == powerpc && isCompatible a powerpc64)
     (b == powerpcle && isCompatible a powerpc64le)

lib/tests/maintainer-module.nix

@@ -7,8 +7,7 @@ in {
       type = types.str;
     };
     email = lib.mkOption {
-      type = types.nullOr types.str;
-      default = null;
+      type = types.str;
     };
     matrix = lib.mkOption {
       type = types.nullOr types.str;