nixos-rebuild: use sudo when whoami != root

Currently, executing `nixos-rebuild switch` as a non-root user will
result in a somewhat confusing error about being unable to link a
profile to a nix store path. This is not ideal, especially as we already
have most of the code to handle this properly and use `sudo` to elevate
permissions to install.

This is preferrable for flakes (better eval caching), and also more
intuitive for new users.

.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 linguist-generated
 **/node-packages.nix linguist-generated
 
 pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated

.github/CODEOWNERS

@@ -22,19 +22,19 @@
 /.editorconfig @Mic92 @zowoq
 
 # Libraries
-/lib                        @edolstra @infinisil
-/lib/systems                @alyssais @ericson2314 @matthewbauer
-/lib/generators.nix         @edolstra @Profpatsch
-/lib/cli.nix                @edolstra @Profpatsch
-/lib/debug.nix              @edolstra @Profpatsch
-/lib/asserts.nix            @edolstra @Profpatsch
+/lib                        @edolstra @nbp @infinisil
+/lib/systems                @alyssais @nbp @ericson2314 @matthewbauer
+/lib/generators.nix         @edolstra @nbp @Profpatsch
+/lib/cli.nix                @edolstra @nbp @Profpatsch
+/lib/debug.nix              @edolstra @nbp @Profpatsch
+/lib/asserts.nix            @edolstra @nbp @Profpatsch
 /lib/path.*                 @infinisil @fricklerhandwerk
 
 # Nixpkgs Internals
-/default.nix                                     @Ericson2314
-/pkgs/top-level/default.nix                      @Ericson2314
-/pkgs/top-level/impure.nix                       @Ericson2314
-/pkgs/top-level/stage.nix                        @Ericson2314 @matthewbauer
+/default.nix                                     @nbp
+/pkgs/top-level/default.nix                      @nbp @Ericson2314
+/pkgs/top-level/impure.nix                       @nbp @Ericson2314
+/pkgs/top-level/stage.nix                        @nbp @Ericson2314 @matthewbauer
 /pkgs/top-level/splice.nix                       @Ericson2314 @matthewbauer
 /pkgs/top-level/release-cross.nix                @Ericson2314 @matthewbauer
 /pkgs/stdenv/generic                             @Ericson2314 @matthewbauer
@@ -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
@@ -58,14 +57,31 @@
 /maintainers/scripts/db-to-md.sh @jtojnar @ryantm
 /maintainers/scripts/doc @jtojnar @ryantm
 
+/doc/* @fricklerhandwerk
 /doc/build-aux/pandoc-filters @jtojnar
+/doc/builders/trivial-builders.chapter.md @fricklerhandwerk
 /doc/contributing/ @fricklerhandwerk
 /doc/contributing/contributing-to-documentation.chapter.md @jtojnar @fricklerhandwerk
+/doc/stdenv @fricklerhandwerk
+/doc/using @fricklerhandwerk
 
 # NixOS Internals
-/nixos/default.nix                                    @infinisil
-/nixos/lib/from-env.nix                               @infinisil
-/nixos/lib/eval-config.nix                            @infinisil
+/nixos/default.nix          @nbp @infinisil
+/nixos/lib/from-env.nix     @nbp @infinisil
+/nixos/lib/eval-config.nix  @nbp @infinisil
+/nixos/doc/manual/configuration/abstractions.xml      @nbp
+/nixos/doc/manual/configuration/config-file.xml       @nbp
+/nixos/doc/manual/configuration/config-syntax.xml     @nbp
+/nixos/doc/manual/configuration/modularity.xml        @nbp
+/nixos/doc/manual/development/assertions.xml          @nbp
+/nixos/doc/manual/development/meta-attributes.xml     @nbp
+/nixos/doc/manual/development/option-declarations.xml @nbp
+/nixos/doc/manual/development/option-def.xml          @nbp
+/nixos/doc/manual/development/option-types.xml        @nbp
+/nixos/doc/manual/development/replace-modules.xml     @nbp
+/nixos/doc/manual/development/writing-modules.xml     @nbp
+/nixos/doc/manual/man-nixos-option.xml                @nbp
+/nixos/modules/installer/tools/nixos-option.sh        @nbp
 /nixos/modules/system                                 @dasJ
 /nixos/modules/system/activation/bootspec.nix         @grahamc @cole-h @raitobezarius
 /nixos/modules/system/activation/bootspec.cue         @grahamc @cole-h @raitobezarius
@@ -73,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
@@ -91,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
@@ -119,13 +134,13 @@
 /pkgs/development/ruby-modules      @marsam
 
 # Rust
-/pkgs/development/compilers/rust @Mic92 @zowoq @winterqt @figsoda
+/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq @winterqt @figsoda
 /pkgs/build-support/rust @zowoq @winterqt @figsoda
 /doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda
 
 # 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
@@ -296,15 +311,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           @ulrikstrid
-/pkgs/development/compilers/ocaml   @ulrikstrid
-/pkgs/development/ocaml-modules     @ulrikstrid
-
-# ZFS
-pkgs/os-specific/linux/zfs                @raitobezarius
-nixos/lib/make-single-disk-zfs-image.nix  @raitobezarius
-nixos/lib/make-multi-disk-zfs-image.nix   @raitobezarius
-nixos/modules/tasks/filesystems/zfs.nix   @raitobezarius
-nixos/tests/zfs.nix                       @raitobezarius

.github/PULL_REQUEST_TEMPLATE.md

@@ -22,7 +22,7 @@ For new packages please briefly describe the package or provide a link to its ho
   - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
 - [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
 - [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
-- [23.11 Release Notes (or backporting 23.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
+- [23.05 Release Notes (or backporting 22.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
   - [ ] (Package updates) Added a release notes entry if the change is major or breaking
   - [ ] (Module updates) Added a release notes entry if the change is significant
   - [ ] (Module addition) Added a release notes entry if adding a new NixOS module

.github/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.1.0
         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@v21
+    - uses: cachix/install-nix-action@v19
     - 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@v21
-        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

@@ -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@v21
+    - uses: cachix/install-nix-action@v19
       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/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@v21
+      - uses: cachix/install-nix-action@v19
         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@v21
+      - uses: cachix/install-nix-action@v19
         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@v21
+      - uses: cachix/install-nix-action@v19
         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/periodic-merge-24h.yml

@@ -38,10 +38,6 @@ jobs:
             into: staging-next-22.11
           - from: staging-next-22.11
             into: staging-22.11
-          - from: release-23.05
-            into: staging-next-23.05
-          - from: staging-next-23.05
-            into: staging-23.05
     name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
     steps:
       - uses: actions/checkout@v3
@@ -55,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@v21
+      - uses: cachix/install-nix-action@v19
         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 }}

.version

@@ -1 +1 @@
-23.11
+23.05

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.
@@ -66,12 +65,9 @@ Useful git commands that can help a lot with this are `git commit --patch --amen
 From time to time, changes between branches must be rebased, for example, if the
 number of new rebuilds they would cause is too large for the target branch. When
 rebasing, care must be taken to include only the intended changes, otherwise
-many CODEOWNERS will be inadvertently requested for review. To achieve this,
+many CODEOWNERS will be inadvertently requested for review.  To achieve this,
 rebasing should not be performed directly on the target branch, but on the merge
-base between the current and target branch. As an additional precautionary measure,
-you should temporarily mark the PR as draft for the duration of the operation.
-This reduces the probability of mass-pinging people. (OfBorg might still
-request a couple of persons for reviews though.)
+base between the current and target branch.
 
 In the following example, we assume that the current branch, called `feature`,
 is based on `master`, and we rebase it onto the merge base between
@@ -105,51 +101,21 @@ git status
 git push origin feature --force-with-lease
 ```
 
-### Something went wrong and a lot of people were pinged
-
-It happens. Remember to be kind, especially to new contributors.
-There is no way back, so the pull request should be closed and locked
-(if possible). The changes should be re-submitted in a new PR, in which the people
-originally involved in the conversation need to manually be pinged again.
-No further discussion should happen on the original PR, as a lot of people
-are now subscribed to it.
-
-The following message (or a version thereof) might be left when closing to
-describe the situation, since closing and locking without any explanation
-is kind of rude:
-
-```markdown
-It looks like you accidentally mass-pinged a bunch of people, which are now subscribed
-and getting notifications for everything in this pull request. Unfortunately, they
-cannot be automatically unsubscribed from the issue (removing review request does not
-unsubscribe), therefore development cannot continue in this pull request anymore.
-
-Please open a new pull request with your changes, link back to this one and ping the
-people actually involved in here over there.
-
-In order to avoid this in the future, there are instructions for how to properly
-rebase between branches in our [contribution guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging).
-Setting your pull request to draft prior to rebasing is strongly recommended.
-In draft status, you can preview the list of people that are about to be requested
-for review, which allows you to sidestep this issue.
-This is not a bulletproof method though, as OfBorg still does review requests even on draft PRs.
-```
-
 ## Backporting changes
 
 Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
 
-You can add a label such as `backport release-23.05` to a PR, so that merging it will
+You can add a label such as `backport release-22.11` to a PR, so that merging it will
 automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
-This also works for pull requests that have already been merged, and might take a couple of minutes to trigger.
+This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
 
 You can also create the backport manually:
 
 1. Take note of the commits in which the change was introduced into `master` branch.
-2. Check out the target _release branch_, e.g. `release-23.05`. Do not use a _channel branch_ like `nixos-23.05` or `nixpkgs-23.05-darwin`.
+2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
 3. Create a branch for your change, e.g. `git checkout -b backport`.
 4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
-5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-23.05`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[23.05]`.
+5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
 6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
 
 ## Criteria for Backporting changes
@@ -161,7 +127,7 @@ Anything that does not cause user or downstream dependency regressions can be ba
 - Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
 - Security critical applications (E.g. `firefox`)
 
-## Generating 23.11 Release Notes
+## 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.
@@ -169,10 +135,10 @@ 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.
 
-Steps for updating 23.11 Release notes:
+Steps for updating 23.05 Release notes:
 
-1. Edit `nixos/doc/manual/release-notes/rl-2311.section.md` with the desired changes
-2. Commit changes to `rl-2311.section.md`.
+1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
+2. Commit changes to `rl-2305.section.md`.
 
 ## Reviewing contributions
 

README.md

@@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 23.05 release](https://hydra.nixos.org/jobset/nixos/release-23.05)
+* [Continuous package builds for the NixOS 22.11 release](https://hydra.nixos.org/jobset/nixos/release-22.11)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 23.05 release](https://hydra.nixos.org/job/nixos/release-23.05/tested#tabs-constituents)
+* [Tests for the NixOS 22.11 release](https://hydra.nixos.org/job/nixos/release-22.11/tested#tabs-constituents)
 
 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are

doc/.gitignore

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

doc/Makefile

@@ -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"
@@ -66,13 +63,18 @@ out/html/index.html: doc-support/result manual-full.xml style.css highlightjs
 	cp doc-support/result/xsl/docbook/images/callouts/*.svg out/html/images/callouts/
 	chmod u+w -R out/html/
 
-out/epub/manual.epub: epub.xml
+out/epub/manual.epub: manual-full.xml
 	mkdir -p out/epub/scratch
 	xsltproc --nonet \
 		--output out/epub/scratch/ \
 		doc-support/result/epub.xsl \
-		./epub.xml
+		./manual-full.xml
 
+	cp -r $(pandoc_media_dir) out/epub/scratch/OEBPS
+	cp ./overrides.css out/epub/scratch/OEBPS
+	cp ./style.css out/epub/scratch/OEBPS
+	mkdir -p out/epub/scratch/OEBPS/images/callouts/
+	cp doc-support/result/xsl/docbook/images/callouts/*.svg out/epub/scratch/OEBPS/images/callouts/
 	echo "application/epub+zip" > mimetype
 	zip -0Xq "out/epub/manual.epub" mimetype
 	rm mimetype

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).
@@ -132,16 +131,11 @@ A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are m
 
 `fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `hash` is currently preferred.
 
-To use a different GitHub instance, use `githubBase` (defaults to `"github.com"`).
-
 `fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.
 
 ## `fetchFromGitLab` {#fetchfromgitlab}
 
-This is used with GitLab repositories. It behaves similarly to `fetchFromGitHub`, and expects `owner`, `repo`, `rev`, and `hash`.
-
-To use a specific GitLab instance, use `domain` (defaults to `"gitlab.com"`).
-
+This is used with GitLab repositories. The arguments expected are very similar to `fetchFromGitHub` above.
 
 ## `fetchFromGitiles` {#fetchfromgitiles}
 
@@ -149,7 +143,7 @@ This is used with Gitiles repositories. The arguments expected are similar to `f
 
 ## `fetchFromBitbucket` {#fetchfrombitbucket}
 
-This is used with BitBucket repositories. The arguments expected are very similar to `fetchFromGitHub` above.
+This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
 
 ## `fetchFromSavannah` {#fetchfromsavannah}
 

doc/builders/images/binarycache.section.md

@@ -6,7 +6,7 @@ Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](
 
 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}
+## Example
 
 The following derivation will construct a flat-file binary cache containing the closure of `hello`.
 

doc/builders/images/dockertools.section.md

@@ -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/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 {#sec-darwin-builder-example-flake}
-
-```
-{
-  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 {#sec-darwin-builder-reconfiguring}
-
-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,12 +1,9 @@
-# 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 filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you 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 for instance.
-It uses Linux' namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system.
-
-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`
-        The name of the environment and the wrapper executable.
+        Environment name.
 - `targetPkgs`
         Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
 - `multiPkgs`
@@ -20,35 +17,33 @@ Accepted arguments are:
 - `extraInstallCommands`
         Additional commands to be executed for finalizing the derivation with runner script.
 - `runScript`
-        A shell command to be executed inside the sandbox. It defaults to `bash`. Command line arguments passed to the resulting wrapper are appended to this command by default.
-        This command must be escaped; i.e. `"foo app" --do-stuff --with "some file"`. See `lib.escapeShellArgs`.
+        A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to `bash`.
 - `profile`
         Optional script for `/etc/profile` within the sandbox.
 
-You can create a simple environment using a `shell.nix` like this:
+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
-    alsa-lib
-  ]) ++ (with pkgs.xorg; [
-    libX11
-    libXcursor
-    libXrandr
-  ]);
-  multiPkgs = pkgs: (with pkgs; [
-    udev
-    alsa-lib
-  ]);
+  targetPkgs = pkgs: (with pkgs;
+    [ udev
+      alsa-lib
+    ]) ++ (with pkgs.xorg;
+    [ libX11
+      libXcursor
+      libXrandr
+    ]);
+  multiPkgs = pkgs: (with pkgs;
+    [ udev
+      alsa-lib
+    ]);
   runScript = "bash";
 }).env
 ```
 
-Running `nix-shell` on it would drop you into a shell inside an FHS env where those libraries and binaries are available in FHS-compliant paths. Applications that expect an FHS structure (i.e. proprietary binaries) can run inside this environment without modification.
-You can build a wrapper by running your binary in `runScript`, e.g. `./bin/start.sh`. Relative paths work as expected.
+Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported.
 
 Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.

doc/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 {#vm-tools-createEmptyImage-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 {#vm-tools-runInLinuxVM-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 {#vm-tools-runInLinuxVM-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 {#vm-tools-extractFs-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 {#vm-tools-extractFs-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 {#vm-tools-makeImageTestScript-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 {#vm-tools-diskImageFuns-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 {#vm-tools-diskImageFuns-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 {#vm-tools-diskImageFuns-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,5 +1,5 @@
 # Testers {#chap-testers}
-This chapter describes several testing builders which are available in the `testers` namespace.
+This chapter describes several testing builders which are available in the <literal>testers</literal> namespace.
 
 ## `hasPkgConfigModule` {#tester-hasPkgConfigModule}
 
@@ -164,26 +164,6 @@ tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
 };
 ```
 
-## `runNixOSTest` {#tester-runNixOSTest}
-
-A helper function that behaves exactly like the NixOS `runTest`, except it also assigns this Nixpkgs package set as the `pkgs` of the test and makes the `nixpkgs.*` options read-only.
-
-If your test is part of the Nixpkgs repository, or if you need a more general entrypoint, see ["Calling a test" in the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-calling-nixos-tests).
-
-Example:
-
-```nix
-pkgs.testers.runNixOSTest ({ lib, ... }: {
-  name = "hello";
-  nodes.machine = { pkgs, ... }: {
-    environment.systemPackages = [ pkgs.hello ];
-  };
-  testScript = ''
-    machine.succeed("hello")
-  '';
-})
-```
-
 ## `nixosTest` {#tester-nixosTest}
 
 Run a NixOS VM network test using this evaluation of Nixpkgs.
@@ -198,7 +178,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:
 
@@ -220,7 +200,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

@@ -220,9 +220,7 @@ There are a few naming guidelines:
 
 - The `version` attribute _must_ start with a digit e.g`"0.3.1rc2".
 
-- If a package is a commit from a repository without a version assigned, then the `version` attribute _should_ be the latest upstream version preceding that commit, followed by `-unstable-` and the date of the (fetched) commit. The date _must_ be in `"YYYY-MM-DD"` format.
-
-Example: Given a project had its latest releases `2.2` in November 2021, and `3.0` in January 2022, a commit authored on March 15, 2022 for an upcoming bugfix release `2.2.1` would have `version = "2.2-unstable-2022-03-15"`.
+- If a package is not a release but a commit from a repository, then the `version` attribute _must_ be the date of that (fetched) commit. The date _must_ be in `"unstable-YYYY-MM-DD"` format.
 
 - Dashes in the package `pname` _should_ be preserved in new variable names, rather than converted to underscores or camel cased — e.g., `http-parser` instead of `http_parser` or `httpParser`. The hyphenated style is preferred in all three package names.
 
@@ -456,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/reviewing-contributions.chapter.md

@@ -12,7 +12,7 @@ When reviewing a pull request, please always be nice and polite. Controversial c
 
 GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
 
-Pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
+pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
 
 All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
 
@@ -201,7 +201,7 @@ checks should be performed:
     them to either recommit using that key or to remove their key
     information.
 
-    Given a maintainer entry like this:
+    Given a maintainter entry like this:
 
     ``` nix
     {

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

@@ -20,36 +20,6 @@ in pkgs.stdenv.mkDerivation {
     ln -s ${doc-support} ./doc-support/result
   '';
 
-  epub = ''
-    <book xmlns="http://docbook.org/ns/docbook"
-          xmlns:xlink="http://www.w3.org/1999/xlink"
-          version="5.0"
-          xml:id="nixpkgs-manual">
-      <info>
-        <title>Nixpkgs Manual</title>
-        <subtitle>Version ${pkgs.lib.version}</subtitle>
-      </info>
-      <chapter>
-        <title>Temporarily unavailable</title>
-        <para>
-          The Nixpkgs manual is currently not available in EPUB format,
-          please use the <link xlink:href="https://nixos.org/nixpkgs/manual">HTML manual</link>
-          instead.
-        </para>
-        <para>
-          If you've used the EPUB manual in the past and it has been useful to you, please
-          <link xlink:href="https://github.com/NixOS/nixpkgs/issues/237234">let us know</link>.
-        </para>
-      </chapter>
-    </book>
-  '';
-  passAsFile = [ "epub" ];
-
-  preBuild = ''
-    cp $epubPath epub.xml
-    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/functions/generators.section.md

@@ -16,7 +16,7 @@ let
              if v == true then ''"yes"''
         else if v == false then ''"no"''
         else if isString v then ''"${v}"''
-        # and delegates all other values to the default generator
+        # and delegats all other values to the default generator
         else generators.mkValueStringDefault {} v;
     } ":";
   };

doc/hooks/autoconf.section.md

@@ -1,3 +1,4 @@
-# Autoconf {#setup-hook-autoconf}
+
+### Autoconf {#setup-hook-autoconf}
 
 The `autoreconfHook` derivation adds `autoreconfPhase`, which runs autoreconf, libtoolize and automake, essentially preparing the configure script in autotools-based builds. Most autotools-based packages come with the configure script pre-generated, but this hook is necessary for a few packages and when you need to patch the package’s configure scripts.

doc/hooks/automake.section.md

@@ -1,3 +1,4 @@
-# Automake {#setup-hook-automake}
+
+### Automake {#setup-hook-automake}
 
 Adds the `share/aclocal` subdirectory of each build input to the `ACLOCAL_PATH` environment variable.

doc/hooks/autopatchelf.section.md

@@ -1,4 +1,5 @@
-# autoPatchelfHook {#setup-hook-autopatchelfhook}
+
+### autoPatchelfHook {#setup-hook-autopatchelfhook}
 
 This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given `buildInputs` and `nativeBuildInputs`.
 

doc/hooks/breakpoint.section.md

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

doc/hooks/cmake.section.md

@@ -1,3 +1,4 @@
-# cmake {#cmake}
+
+### cmake {#cmake}
 
 Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to `CMAKE_PREFIX_PATH` so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`. `cmakeFlags` controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.

doc/hooks/gdk-pixbuf.section.md

@@ -1,3 +1,4 @@
-# gdk-pixbuf {#setup-hook-gdk-pixbuf}
+
+### gdk-pixbuf {#setup-hook-gdk-pixbuf}
 
 Exports `GDK_PIXBUF_MODULE_FILE` environment variable to the builder. Add librsvg package to `buildInputs` to get svg support. See also the [setup hook description in GNOME platform docs](#ssec-gnome-hooks-gdk-pixbuf).

doc/hooks/ghc.section.md

@@ -1,3 +1,4 @@
-# GHC {#ghc}
+
+### GHC {#ghc}
 
 Creates a temporary package database and registers every Haskell build input in it (TODO: how?).

doc/hooks/gnome.section.md

@@ -1,3 +1,4 @@
-# GNOME platform {#gnome-platform}
+
+### GNOME platform {#gnome-platform}
 
 Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in [](#sec-language-gnome).

doc/hooks/installShellFiles.section.md

@@ -1,4 +1,5 @@
-# `installShellFiles` {#installshellfiles}
+
+### `installShellFiles` {#installshellfiles}
 
 This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
 

doc/hooks/libiconv.section.md

@@ -1,3 +1,4 @@
-# libiconv, libintl {#libiconv-libintl}
+
+### libiconv, libintl {#libiconv-libintl}
 
 A few libraries automatically add to `NIX_LDFLAGS` their library, making their symbols automatically available to the linker. This includes libiconv and libintl (gettext). This is done to provide compatibility between GNU Linux, where libiconv and libintl are bundled in, and other systems where that might not be the case. Sometimes, this behavior is not desired. To disable this behavior, set `dontAddExtraLibs`.

doc/hooks/libxml2.section.md

@@ -1,3 +1,4 @@
-# libxml2 {#setup-hook-libxml2}
+
+### libxml2 {#setup-hook-libxml2}
 
 Adds every file named `catalog.xml` found under the `xml/dtd` and `xml/xsl` subdirectories of each build input to the `XML_CATALOG_FILES` environment variable.

doc/hooks/meson.section.md

@@ -1,25 +1,26 @@
-# Meson {#meson}
+
+### Meson {#meson}
 
 Overrides the configure phase to run meson to generate Ninja files. To run these files, you should accompany Meson with ninja. By default, `enableParallelBuilding` is enabled as Meson supports parallel building almost everywhere.
 
-## Variables controlling Meson {#variables-controlling-meson}
+#### Variables controlling Meson {#variables-controlling-meson}
 
-### `mesonFlags` {#mesonflags}
+##### `mesonFlags` {#mesonflags}
 
 Controls the flags passed to meson.
 
-### `mesonBuildType` {#mesonbuildtype}
+##### `mesonBuildType` {#mesonbuildtype}
 
 Which [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to pass to Meson. We default to `plain`.
 
-### `mesonAutoFeatures` {#mesonautofeatures}
+##### `mesonAutoFeatures` {#mesonautofeatures}
 
 What value to set [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `enabled`.
 
-### `mesonWrapMode` {#mesonwrapmode}
+##### `mesonWrapMode` {#mesonwrapmode}
 
 What value to set [`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `nodownload` as we disallow network access.
 
-### `dontUseMesonConfigure` {#dontusemesonconfigure}
+##### `dontUseMesonConfigure` {#dontusemesonconfigure}
 
 Disables using Meson’s `configurePhase`.

doc/hooks/ninja.section.md

@@ -1,3 +1,4 @@
-# ninja {#ninja}
+
+### ninja {#ninja}
 
 Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with the `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.

doc/hooks/perl.section.md

@@ -1,3 +1,4 @@
-# Perl {#setup-hook-perl}
+
+### Perl {#setup-hook-perl}
 
 Adds the `lib/site_perl` subdirectory of each build input to the `PERL5LIB` environment variable. For instance, if `buildInputs` contains Perl, then the `lib/site_perl` subdirectory of each input is added to the `PERL5LIB` environment variable.

doc/hooks/pkg-config.section.md

@@ -1,3 +1,4 @@
-# pkg-config {#setup-hook-pkg-config}
+
+### pkg-config {#setup-hook-pkg-config}
 
 Adds the `lib/pkgconfig` and `share/pkgconfig` subdirectories of each build input to the `PKG_CONFIG_PATH` environment variable.

doc/hooks/python.section.md

@@ -1,3 +1,4 @@
-# Python {#setup-hook-python}
+
+### Python {#setup-hook-python}
 
 Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.

doc/hooks/qt-4.section.md

@@ -1,3 +1,4 @@
-# Qt 4 {#qt-4}
+
+### Qt 4 {#qt-4}
 
 Sets the `QTDIR` environment variable to Qt’s path.

doc/hooks/scons.section.md

@@ -1,3 +1,4 @@
-# scons {#scons}
+
+### scons {#scons}
 
 Overrides the build, install, and check phases. This uses the scons build system as a replacement for make. scons does not provide a configure phase, so everything is managed at build and install time.

doc/hooks/tetex-tex-live.section.md

@@ -1,3 +1,4 @@
-# teTeX / TeX Live {#tetex-tex-live}
+
+### teTeX / TeX Live {#tetex-tex-live}
 
 Adds the `share/texmf-nix` subdirectory of each build input to the `TEXINPUTS` environment variable.

doc/hooks/unzip.section.md

@@ -1,3 +1,4 @@
-# unzip {#unzip}
+
+### unzip {#unzip}
 
 This setup hook will allow you to unzip .zip files specified in `$src`. There are many similar packages like `unrar`, `undmg`, etc.

doc/hooks/validatePkgConfig.section.md

@@ -1,3 +1,4 @@
-# validatePkgConfig {#validatepkgconfig}
+
+### validatePkgConfig {#validatepkgconfig}
 
 The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.

doc/hooks/waf.section.md

@@ -1,3 +1,4 @@
-# wafHook {#wafhook}
+
+### wafHook {#wafhook}
 
 Overrides the configure, build, and install phases. This will run the “waf” script used by many projects. If `wafPath` (default `./waf`) doesn’t exist, it will copy the version of waf available in Nixpkgs. `wafFlags` can be used to pass flags to the waf script.

doc/hooks/xcbuild.section.md

@@ -1,3 +1,4 @@
-# xcbuildHook {#xcbuildhook}
+
+### xcbuildHook {#xcbuildhook}
 
 Overrides the build and install phases to run the "xcbuild" command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.

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/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/default.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";
@@ -274,18 +274,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/bower.section.md

@@ -1,6 +1,6 @@
 # Bower {#sec-bower}
 
-[Bower](https://bower.io) is a package manager for web site front-end components. Bower packages (comprising of build artifacts and sometimes sources) are stored in `git` repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the `bower.json` file within each package.
+[Bower](https://bower.io) is a package manager for web site front-end components. Bower packages (comprising of build artefacts and sometimes sources) are stored in `git` repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the `bower.json` file within each package.
 
 The end result of running Bower is a `bower_components` directory which can be included in the web app's build process.
 
@@ -41,18 +41,32 @@ The function is implemented in [pkgs/development/bower-modules/generic/default.n
 
 ### Example buildBowerComponents {#ex-buildBowerComponents}
 
-```nix
+```{=docbook}
+<programlisting language="nix">
 bowerComponents = buildBowerComponents {
   name = "my-web-app";
-  generated = ./bower-packages.nix; # note 1
-  src = myWebApp; # note 2
+  generated = ./bower-packages.nix; <co xml:id="ex-buildBowerComponents-1" />
+  src = myWebApp; <co xml:id="ex-buildBowerComponents-2" />
 };
+</programlisting>
 ```
 
 In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
 
-1. `generated` specifies the file which was created by {command}`bower2nix`.
-2. `src` is your project's sources. It needs to contain a {file}`bower.json` file.
+```{=docbook}
+<calloutlist>
+  <callout arearefs="ex-buildBowerComponents-1">
+    <para>
+      <varname>generated</varname> specifies the file which was created by <command>bower2nix</command>.
+    </para>
+    </callout>
+      <callout arearefs="ex-buildBowerComponents-2">
+    <para>
+      <varname>src</varname> is your project's sources. It needs to contain a <filename>bower.json</filename> file.
+    </para>
+  </callout>
+</calloutlist>
+```
 
 `buildBowerComponents` will run Bower to link together the output of `bower2nix`, resulting in a `bower_components` directory which can be used.
 
@@ -77,9 +91,10 @@ gulp.task('build', [], function () {
 
 ### Example Full example — default.nix {#ex-buildBowerComponentsDefaultNix}
 
-```nix
+```{=docbook}
+<programlisting language="nix">
 { myWebApp ? { outPath = ./.; name = "myWebApp"; }
-, pkgs ? import <nixpkgs> {}
+, pkgs ? import &lt;nixpkgs&gt; {}
 }:
 
 pkgs.stdenv.mkDerivation {
@@ -88,29 +103,49 @@ pkgs.stdenv.mkDerivation {
 
   buildInputs = [ pkgs.nodePackages.gulp ];
 
-  bowerComponents = pkgs.buildBowerComponents { # note 1
+  bowerComponents = pkgs.buildBowerComponents { <co xml:id="ex-buildBowerComponentsDefault-1" />
     name = "my-web-app";
     generated = ./bower-packages.nix;
     src = myWebApp;
   };
 
   buildPhase = ''
-    cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . # note 2
-    export HOME=$PWD # note 3
-    ${pkgs.nodePackages.gulp}/bin/gulp build # note 4
+    cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . <co xml:id="ex-buildBowerComponentsDefault-2" />
+    export HOME=$PWD <co xml:id="ex-buildBowerComponentsDefault-3" />
+    ${pkgs.nodePackages.gulp}/bin/gulp build <co xml:id="ex-buildBowerComponentsDefault-4" />
   '';
 
   installPhase = "mv gulpdist $out";
 }
+</programlisting>
 ```
 
 A few notes about [Full example — `default.nix`](#ex-buildBowerComponentsDefaultNix):
 
-1. The result of `buildBowerComponents` is an input to the frontend build.
-2. Whether to symlink or copy the {file}`bower_components` directory depends on the build tool in use.
-   In this case a copy is used to avoid {command}`gulp` silliness with permissions.
-3. {command}`gulp` requires `HOME` to refer to a writeable directory.
-4. The actual build command in this example is {command}`gulp`. Other tools could be used instead.
+```{=docbook}
+<calloutlist>
+  <callout arearefs="ex-buildBowerComponentsDefault-1">
+    <para>
+      The result of <varname>buildBowerComponents</varname> is an input to the frontend build.
+    </para>
+  </callout>
+  <callout arearefs="ex-buildBowerComponentsDefault-2">
+    <para>
+      Whether to symlink or copy the <filename>bower_components</filename> directory depends on the build tool in use. In this case a copy is used to avoid <command>gulp</command> silliness with permissions.
+    </para>
+  </callout>
+  <callout arearefs="ex-buildBowerComponentsDefault-3">
+    <para>
+      <command>gulp</command> requires <varname>HOME</varname> to refer to a writeable directory.
+    </para>
+  </callout>
+  <callout arearefs="ex-buildBowerComponentsDefault-4">
+    <para>
+      The actual build command. Other tools could be used.
+    </para>
+  </callout>
+</calloutlist>
+```
 
 ## Troubleshooting {#ssec-bower2nix-troubleshooting}
 

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/cuda.section.md

@@ -8,7 +8,7 @@ A package set is available for each CUDA version, so for example
 `cudaPackages_11_6`. Within each set is a matching version of the above listed
 packages. Additionally, other versions of the packages that are packaged and
 compatible are available as well. For example, there can be a
-`cudaPackages.cudnn_8_3` package.
+`cudaPackages.cudnn_8_3_2` package.
 
 To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional
 ```nix
@@ -27,8 +27,8 @@ package set to make it the default. This guarantees you get a consistent package
 set.
 ```nix
 mypkg = let
-  cudaPackages = cudaPackages_11_5.overrideScope' (final: prev: {
-    cudnn = prev.cudnn_8_3;
+  cudaPackages = cudaPackages_11_5.overrideScope' (final: prev {
+    cudnn = prev.cudnn_8_3_2;
   }});
 in callPackage { inherit cudaPackages; };
 ```

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/dart.section.md

@@ -1,65 +0,0 @@
-# Dart {#sec-language-dart}
-
-## Dart applications {#ssec-dart-applications}
-
-The function `buildDartApplication` builds Dart applications managed with pub.
-
-It fetches its Dart dependencies automatically through `fetchDartDeps`, and (through a series of hooks) builds and installs the executables specified in the pubspec file. The hooks can be used in other derivations, if needed. The phases can also be overridden to do something different from installing binaries.
-
-If you are packaging a Flutter desktop application, use [`buildFlutterApplication`](#ssec-dart-flutter) instead.
-
-`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, simply set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).
-
-If the upstream source is missing a `pubspec.lock` file, you'll have to vendor one and specify it using `pubspecLockFile`. If it is needed, one will be generated for you and printed when attempting to build the derivation.
-
-The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
-
-Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.
-
-```nix
-{ buildDartApplication, fetchFromGitHub }:
-
-buildDartApplication rec {
-  pname = "dart-sass";
-  version = "1.62.1";
-
-  src = fetchFromGitHub {
-    owner = "sass";
-    repo = pname;
-    rev = version;
-    hash = "sha256-U6enz8yJcc4Wf8m54eYIAnVg/jsGi247Wy8lp1r1wg4=";
-  };
-
-  pubspecLockFile = ./pubspec.lock;
-  vendorHash = "sha256-Atm7zfnDambN/BmmUf4BG0yUz/y6xWzf0reDw3Ad41s=";
-}
-```
-
-## Flutter applications {#ssec-dart-flutter}
-
-The function `buildFlutterApplication` builds Flutter applications.
-
-The deps.json file must always be provided when packaging in Nixpkgs. It will be generated and printed if the derivation is attempted to be built without one. Alternatively, `autoDepsList` may be set to `true` when outside of Nixpkgs, as it relies on import-from-derivation.
-
-A `pubspec.lock` file must be available. See the [Dart documentation](#ssec-dart-applications) for more details.
-
-```nix
-{  flutter, fetchFromGitHub }:
-
-flutter.buildFlutterApplication {
-  pname = "firmware-updater";
-  version = "unstable-2023-04-30";
-
-  src = fetchFromGitHub {
-    owner = "canonical";
-    repo = "firmware-updater";
-    rev = "6e7dbdb64e344633ea62874b54ff3990bd3b8440";
-    sha256 = "sha256-s5mwtr5MSPqLMN+k851+pFIFFPa0N1hqz97ys050tFA=";
-    fetchSubmodules = true;
-  };
-
-  pubspecLockFile = ./pubspec.lock;
-  depsListFile = ./deps.json;
-  vendorHash = "sha256-cdMO+tr6kYiN5xKXa+uTMAcFf2C75F3wVPrn21G4QPQ=";
-}
-```

doc/languages-frameworks/dhall.section.md

@@ -307,12 +307,12 @@ $ nix-env --install --attr haskellPackages.dhall-nixpkgs
 
 $ nix-env --install --attr nix-prefetch-git  # Used by dhall-to-nixpkgs
 
-$ dhall-to-nixpkgs github https://github.com/Gabriella439/dhall-semver.git
+$ dhall-to-nixpkgs github https://github.com/Gabriel439/dhall-semver.git
 { buildDhallGitHubPackage, Prelude }:
   buildDhallGitHubPackage {
     name = "dhall-semver";
     githubBase = "github.com";
-    owner = "Gabriella439";
+    owner = "Gabriel439";
     repo = "dhall-semver";
     rev = "2d44ae605302ce5dc6c657a1216887fbb96392a4";
     fetchSubmodules = false;

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_3_1
       sdk_6_0
-      sdk_7_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 6.0 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_6_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

@@ -27,7 +27,7 @@ The modules are typically installed to `lib/gio/modules/` directory of a package
 
 In particular, we recommend:
 
-* adding `dconf.lib` for any software on Linux that reads [GSettings](#ssec-gnome-settings) (even transitively through e.g. GTK’s file manager)
+* adding `dconf.lib` for any software on Linux that reads [GSettings](#ssec-gnome-settings) (even transitivily through e.g. GTK’s file manager)
 * adding `glib-networking` for any software that accesses network using GIO or libsoup – glib-networking contains a module that implements TLS support and loads system-wide proxy settings
 
 To allow software to use various virtual file systems, `gvfs` package can be also added. But that is usually an optional feature so we typically use `gvfs` from the system (e.g. installed globally using NixOS module).
@@ -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:
@@ -137,15 +141,15 @@ Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is the
 
 ## Frequently encountered issues {#ssec-gnome-common-issues}
 
-### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
+#### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
 
 There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGAppsHook`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
 
-### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
+#### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
 
 Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
 
-### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
+#### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
 
 This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
 
@@ -193,7 +197,7 @@ mkDerivation {
 }
 ```
 
-### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
+#### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
 
 You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
 
@@ -209,6 +213,6 @@ You can rely on applications depending on the library setting the necessary envi
 
   []{#ssec-gnome-common-issues-unwrappable-package-gsettings-c} [Hard-coding GSettings schema path in C library](https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34) – nothing special other than using [Coccinelle patch](https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467) to generate the patch itself.
 
-### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
+#### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
 
 You can manually trigger the wrapping with `wrapGApp` in `preFixup` phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to [`wrapProgram`](#fun-wrapProgram) function.

doc/languages-frameworks/go.section.md

@@ -19,8 +19,7 @@ In the following is an example expression using `buildGoModule`, the following a
   To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`
 
   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-dependent `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.
+- `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.
 
 ```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).
@@ -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)
@@ -276,15 +265,6 @@ Defaults to `true`.
 : Whether to generate an index for interactive navigation of the HTML documentation.
 Defaults to `true` if supported.
 
-`doInstallIntermediates`
-: Whether to install intermediate build products (files written to `dist/build`
-by GHC during the build process). With `enableSeparateIntermediatesOutput`,
-these files are instead installed to [a separate `intermediates`
-output.][multiple-outputs] The output can then be passed into a future build of
-the same package with the `previousIntermediates` argument to support
-incremental builds. See [“Incremental builds”](#haskell-incremental-builds) for
-more information. Defaults to `false`.
-
 `enableLibraryProfiling`
 : Whether to enable [profiling][profiling] for libraries contained in the
 package. Enabled by default if supported.
@@ -380,12 +360,6 @@ Defaults to `false`.
 : Whether to install documentation to a separate `doc` output.
 Is automatically enabled if `doHaddock` is `true`.
 
-`enableSeparateIntermediatesOutput`
-: When `doInstallIntermediates` is true, whether to install intermediate build
-products to a separate `intermediates` output. See [“Incremental
-builds”](#haskell-incremental-builds) for more information. Defaults to
-`false`.
-
 `allowInconsistentDependencies`
 : If enabled, allow multiple versions of the same Haskell package in the
 dependency tree at configure time. Often in such a situation compilation would
@@ -396,11 +370,6 @@ later fail because of type mismatches. Defaults to `false`.
 when loading the library in the REPL, but requires extra build time and
 disk space. Defaults to `false`.
 
-`previousIntermediates`
-: If non-null, intermediate build artifacts are copied from this input to
-`dist/build` before performing compiling. See [“Incremental
-builds”](#haskell-incremental-builds) for more information. Defaults to `null`.
-
 `buildTarget`
 : Name of the executable or library to build and install.
 If unset, all available targets are built and installed.
@@ -499,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
@@ -516,54 +485,6 @@ the [Meta-attributes section](#chap-meta) for their documentation.
     * `broken`
     * `hydraPlatforms`
 
-### Incremental builds {#haskell-incremental-builds}
-
-`haskellPackages.mkDerivation` supports incremental builds for GHC 9.4 and
-newer with the `doInstallIntermediates`, `enableSeparateIntermediatesOutput`,
-and `previousIntermediates` arguments.
-
-The basic idea is to first perform a full build of the package in question,
-save its intermediate build products for later, and then copy those build
-products into the build directory of an incremental build performed later.
-Then, GHC will use those build artifacts to avoid recompiling unchanged
-modules.
-
-For more detail on how to store and use incremental build products, see
-[Gabriella Gonzalez’ blog post “Nixpkgs support for incremental Haskell
-builds”.][incremental-builds] motivation behind this feature.
-
-An incremental build for [the `turtle` package][turtle] can be performed like
-so:
-
-```nix
-let
-  pkgs = import <nixpkgs> {};
-  inherit (pkgs) haskell;
-  inherit (haskell.lib.compose) overrideCabal;
-
-  # Incremental builds work with GHC >=9.4.
-  turtle = haskell.packages.ghc944.turtle;
-
-  # This will do a full build of `turtle`, while writing the intermediate build products
-  # (compiled modules, etc.) to the `intermediates` output.
-  turtle-full-build-with-incremental-output = overrideCabal (drv: {
-    doInstallIntermediates = true;
-    enableSeparateIntermediatesOutput = true;
-  }) turtle;
-
-  # This will do an incremental build of `turtle` by copying the previously
-  # compiled modules and intermediate build products into the source tree
-  # before running the build.
-  #
-  # GHC will then naturally pick up and reuse these products, making this build
-  # complete much more quickly than the previous one.
-  turtle-incremental-build = overrideCabal (drv: {
-    previousIntermediates = turtle-full-build-with-incremental-output.intermediates;
-  }) turtle;
-in
-  turtle-incremental-build
-```
-
 ## Development environments {#haskell-development-environments}
 
 In addition to building and installing Haskell software, nixpkgs can also
@@ -782,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. -->
 
@@ -871,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:
 
@@ -894,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
@@ -943,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
@@ -981,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`.
@@ -1057,7 +978,7 @@ benchmark component.
 `dontBenchmark drv`
 : Set `doBenchmark` to `false` for `drv`.
 
-`setBuildTargets drv list`
+`setBuildTargets list drv`
 : Sets the `buildTarget` argument for `drv` so that the targets specified in `list` are built.
 
 `doCoverage drv`
@@ -1066,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
@@ -1130,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
@@ -1151,11 +1072,8 @@ on the issue linked above.
 [haskell.nix]: https://input-output-hk.github.io/haskell.nix/index.html
 [HLS user guide]: https://haskell-language-server.readthedocs.io/en/latest/configuration.html#configuring-your-editor
 [hoogle]: https://wiki.haskell.org/Hoogle
-[incremental-builds]: https://www.haskellforall.com/2022/12/nixpkgs-support-for-incremental-haskell.html
 [jailbreak-cabal]: https://github.com/NixOS/jailbreak-cabal/
-[multiple-outputs]: https://nixos.org/manual/nixpkgs/stable/#chap-multiple-output
 [optparse-applicative-completions]: https://github.com/pcapriotti/optparse-applicative/blob/7726b63796aa5d0df82e926d467f039b78ca09e2/README.md#bash-zsh-and-fish-completions
 [profiling-detail]: https://cabal.readthedocs.io/en/latest/cabal-project.html#cfg-field-profiling-detail
 [profiling]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html
 [search.nixos.org]: https://search.nixos.org
-[turtle]: https://hackage.haskell.org/package/turtle

doc/languages-frameworks/index.xml

@@ -14,7 +14,6 @@
  <xi:include href="crystal.section.xml" />
  <xi:include href="cuda.section.xml" />
  <xi:include href="cuelang.section.xml" />
- <xi:include href="dart.section.xml" />
  <xi:include href="dhall.section.xml" />
  <xi:include href="dotnet.section.xml" />
  <xi:include href="emscripten.section.xml" />
@@ -26,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" />

doc/languages-frameworks/ios.section.md

@@ -104,7 +104,7 @@ The above function takes a variety of parameters:
   and the location where the source code resides
 * `sdkVersion` specifies which version of the iOS SDK to use.
 
-It also possible to adjust the `xcodebuild` parameters. This is only needed in
+It also possile to adjust the `xcodebuild` parameters. This is only needed in
 rare circumstances. In most cases the default values should suffice:
 
 * Specifies which `xcodebuild` target to build. By default it takes the target
@@ -130,7 +130,7 @@ In addition, you need to set the following parameters:
   store certificates.
 * `generateIPA` specifies that we want to produce an IPA file (this is probably
   what you want)
-* `generateXCArchive` specifies that we want to produce an xcarchive file.
+* `generateXCArchive` specifies thet we want to produce an xcarchive file.
 
 When building IPA files on Hydra and when it is desired to allow iOS devices to
 install IPAs by browsing to the Hydra build products page, you can enable the

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,10 +140,10 @@ 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 unencrypted 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:
+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:
 
 ```
 The unauthenticated git protocol on port 9418 is no longer supported
@@ -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 {

doc/languages-frameworks/perl.section.md

@@ -118,7 +118,7 @@ ImageExifTool = buildPerlPackage {
     hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
   };
 
-  nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
+  buildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
   postInstall = lib.optionalString stdenv.isDarwin ''
     shortenPerlShebang $out/bin/exiftool
   '';

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

@@ -4,7 +4,7 @@
 
 Nixpkgs provides a couple of facilities for working with this tool.
 
-## Writing packages providing pkg-config modules {#pkg-config-writing-packages}
+## Writing packages providing pkg-config modules
 
 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.
@@ -29,9 +29,9 @@ stdenv.mkDerivation (finalAttrs: {
 })
 ```
 
-## Accessing packages via pkg-config module name {#sec-pkg-config-usage}
+## Accessing packages via pkg-config module name
 
-### Within Nixpkgs {#sec-pkg-config-usage-internal}
+### Within Nixpkgs
 
 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:
@@ -44,7 +44,7 @@ For more details see the section on [specifying dependencies in general](#ssec-s
 
 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}
+### Externally
 
 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.

doc/languages-frameworks/python.section.md

@@ -10,7 +10,7 @@ Several versions of the Python interpreter are available on Nix, as well as a
 high amount of packages. The attribute `python3` refers to the default
 interpreter, which is currently CPython 3.10. The attribute `python` refers to
 CPython 2.7 for backwards-compatibility. It is also possible to refer to
-specific versions, e.g. `python311` refers to CPython 3.11, and `pypy` refers to
+specific versions, e.g. `python39` refers to CPython 3.9, and `pypy` refers to
 the default PyPy interpreter.
 
 Python is used a lot, and in different ways. This affects also how it is
@@ -26,10 +26,10 @@ however, are in separate sets, with one set per interpreter version.
 The interpreters have several common attributes. One of these attributes is
 `pkgs`, which is a package set of Python libraries for this specific
 interpreter. E.g., the `toolz` package corresponding to the default interpreter
-is `python.pkgs.toolz`, and the CPython 3.11 version is `python311.pkgs.toolz`.
+is `python.pkgs.toolz`, and the CPython 3.9 version is `python39.pkgs.toolz`.
 The main package set contains aliases to these package sets, e.g.
-`pythonPackages` refers to `python.pkgs` and `python311Packages` to
-`python311.pkgs`.
+`pythonPackages` refers to `python.pkgs` and `python39Packages` to
+`python39.pkgs`.
 
 #### Installing Python and packages {#installing-python-and-packages}
 
@@ -54,7 +54,7 @@ with `python.buildEnv` or `python.withPackages` where the interpreter and other
 executables are wrapped to be able to find each other and all of the modules.
 
 In the following examples we will start by creating a simple, ad-hoc environment
-with a nix-shell that has `numpy` and `toolz` in Python 3.11; then we will create
+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.
 
@@ -70,10 +70,10 @@ temporary shell session with a Python and a *precise* list of packages (plus
 their runtime dependencies), with no other Python packages in the Python
 interpreter's scope.
 
-To create a Python 3.11 session with `numpy` and `toolz` available, run:
+To create a Python 3.9 session with `numpy` and `toolz` available, run:
 
 ```sh
-$ nix-shell -p 'python311.withPackages(ps: with ps; [ numpy toolz ])'
+$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy toolz ])'
 ```
 
 By default `nix-shell` will start a `bash` session with this interpreter in our
@@ -81,7 +81,8 @@ By default `nix-shell` will start a `bash` session with this interpreter in our
 
 ```Python console
 [nix-shell:~/src/nixpkgs]$ python3
-Python 3.11.3 (main, Apr  4 2023, 22:36:41) [GCC 12.2.0] on linux
+Python 3.9.12 (main, Mar 23 2022, 21:36:19)
+[GCC 11.3.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy; import toolz
 ```
@@ -101,12 +102,16 @@ will still get 1 wrapped Python interpreter. We can start the interpreter
 directly like so:
 
 ```sh
-$ nix-shell -p "python311.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
+$ nix-shell -p "python39.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
 this derivation will be built:
-  /nix/store/r19yf5qgfiakqlhkgjahbg3zg79549n4-python3-3.11.2-env.drv
-building '/nix/store/r19yf5qgfiakqlhkgjahbg3zg79549n4-python3-3.11.2-env.drv'...
-created 273 symlinks in user environment
-Python 3.11.2 (main, Feb  7 2023, 13:52:42) [GCC 12.2.0] on linux
+  /nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv
+this path will be fetched (0.09 MiB download, 0.41 MiB unpacked):
+  /nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2
+copying path '/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2' from 'https://cache.nixos.org'...
+building '/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv'...
+created 279 symlinks in user environment
+Python 3.9.12 (main, Mar 23 2022, 21:36:19)
+[GCC 11.3.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import requests
 >>>
@@ -145,7 +150,7 @@ Executing this script requires a `python3` that has `numpy`. Using what we learn
 in the previous section, we could startup a shell and just run it like so:
 
 ```ShellSession
-$ nix-shell -p 'python311.withPackages (ps: with ps; [ numpy ])' --run 'python3 foo.py'
+$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
 The dot product of [1 2] and [3 4] is: 11
 ```
 
@@ -185,17 +190,17 @@ can make it fully reproducible by pinning the `nixpkgs` import:
 
 ```python
 #!/usr/bin/env nix-shell
-#!nix-shell -i python3 -p "python3.withPackages (ps: [ ps.numpy ])"
-#!nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/e51209796c4262bfb8908e3d6d72302fe4e96f5f.tar.gz
+#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.numpy ])"
+#!nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/d373d80b1207d52621961b16aa4a3438e4f98167.tar.gz
 import numpy as np
 a = np.array([1,2])
 b = np.array([3,4])
 print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
 ```
 
-This will execute with the exact same versions of Python 3.10, numpy, and system
+This will execute with the exact same versions of Python 3.8, numpy, and system
 dependencies a year from now as it does today, because it will always use
-exactly git commit `e51209796c4262bfb8908e3d6d72302fe4e96f5f` of Nixpkgs for all
+exactly git commit `d373d80b1207d52621961b16aa4a3438e4f98167` of Nixpkgs for all
 of the package versions.
 
 This is also a great way to ensure the script executes identically on different
@@ -208,15 +213,12 @@ create a single script with Python dependencies, but in the course of normal
 development we're usually working in an entire package repository.
 
 As explained in the Nix manual, `nix-shell` can also load an expression from a
-`.nix` file. Say we want to have Python 3.11, `numpy` and `toolz`, like before,
+`.nix` file. Say we want to have Python 3.9, `numpy` and `toolz`, like before,
 in an environment. We can add a `shell.nix` file describing our dependencies:
 
 ```nix
 with import <nixpkgs> {};
-(python311.withPackages (ps: with ps; [
-  numpy
-  toolz
-])).env
+(python39.withPackages (ps: [ps.numpy ps.toolz])).env
 ```
 
 And then at the command line, just typing `nix-shell` produces the same
@@ -230,7 +232,7 @@ What's happening here?
    imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
    brings all attributes of `nixpkgs` in the local scope. These attributes form
    the main package set.
-2. Then we create a Python 3.11 environment with the `withPackages` function, as before.
+2. Then we create a Python 3.9 environment with the `withPackages` function, as before.
 3. The `withPackages` function expects us to provide a function as an argument
    that takes the set of all Python packages and returns a list of packages to
    include in the environment. Here, we select the packages `numpy` and `toolz`
@@ -241,7 +243,7 @@ To combine this with `mkShell` you can:
 ```nix
 with import <nixpkgs> {};
 let
-  pythonEnv = python311.withPackages (ps: [
+  pythonEnv = python39.withPackages (ps: [
     ps.numpy
     ps.toolz
   ]);
@@ -325,7 +327,7 @@ on NixOS.
 { # ...
 
   environment.systemPackages = with pkgs; [
-    (python310.withPackages(ps: with ps; [ numpy toolz ]))
+    (python38.withPackages(ps: with ps; [ numpy toolz ]))
   ];
 }
 ```
@@ -346,32 +348,20 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
 `toolz` package.
 
 ```nix
-{ lib
-, buildPythonPackage
-, fetchPypi
-}:
+{ lib, buildPythonPackage, fetchPypi }:
 
 buildPythonPackage rec {
   pname = "toolz";
   version = "0.10.0";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
     hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
   };
 
-  # has no tests
   doCheck = false;
 
-  pythonImportsCheck = [
-    "toolz.itertoolz"
-    "toolz.functoolz"
-    "toolz.dicttoolz"
-  ];
-
   meta = with lib; {
-    changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
     homepage = "https://github.com/pytoolz/toolz";
     description = "List processing tools and functional utilities";
     license = licenses.bsd3;
@@ -386,14 +376,13 @@ arguments is the name of the package, which consists of a basename (generally
 following the name on PyPi) and a version. Another argument, `src` specifies the
 source, which in this case is fetched from PyPI using the helper function
 `fetchPypi`. The argument `doCheck` is used to set whether tests should be run
-when building the package. Since there are no tests, we rely on `pythonImportsCheck`
-to test whether the package can be imported. Furthermore, we specify some meta
+when building the package. Furthermore, we specify some (optional) meta
 information. The output of the function is a derivation.
 
 An expression for `toolz` can be found in the Nixpkgs repository. As explained
 in the introduction of this Python section, a derivation of `toolz` is available
-for each interpreter version, e.g. `python311.pkgs.toolz` refers to the `toolz`
-derivation corresponding to the CPython 3.11 interpreter.
+for each interpreter version, e.g. `python39.pkgs.toolz` refers to the `toolz`
+derivation corresponding to the CPython 3.9 interpreter.
 
 The above example works when you're directly working on
 `pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though,
@@ -406,35 +395,29 @@ and adds it along with a `numpy` package to a Python environment.
 with import <nixpkgs> {};
 
 ( let
-    my_toolz = python311.pkgs.buildPythonPackage rec {
+    my_toolz = python39.pkgs.buildPythonPackage rec {
       pname = "toolz";
       version = "0.10.0";
-      format = "setuptools";
 
-      src = fetchPypi {
+      src = python39.pkgs.fetchPypi {
         inherit pname version;
         hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
       };
 
-      # has no tests
       doCheck = false;
 
       meta = {
         homepage = "https://github.com/pytoolz/toolz/";
         description = "List processing tools and functional utilities";
-        # [...]
       };
     };
 
-  in python311.withPackages (ps: with ps; [
-    numpy
-    my_toolz
-  ])
+  in python38.withPackages (ps: [ps.numpy my_toolz])
 ).env
 ```
 
 Executing `nix-shell` will result in an environment in which you can use
-Python 3.11 and the `toolz` package. As you can see we had to explicitly mention
+Python 3.9 and the `toolz` package. As you can see we had to explicitly mention
 for which Python version we want to build a package.
 
 So, what did we do here? Well, we took the Nix expression that we used earlier
@@ -459,39 +442,21 @@ The following example shows which arguments are given to `buildPythonPackage` in
 order to build [`datashape`](https://github.com/blaze/datashape).
 
 ```nix
-{ lib
-, buildPythonPackage
-, fetchPypi
-
-# dependencies
-, numpy, multipledispatch, python-dateutil
-
-# tests
-, pytest
-}:
+{ lib, buildPythonPackage, fetchPypi, numpy, multipledispatch, python-dateutil, pytest }:
 
 buildPythonPackage rec {
   pname = "datashape";
   version = "0.4.7";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
     hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
   };
 
-  propagatedBuildInputs = [
-    multipledispatch
-    numpy
-    python-dateutil
-  ];
-
-  nativeCheckInputs = [
-    pytest
-  ];
+  nativeCheckInputs = [ pytest ];
+  propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];
 
   meta = with lib; {
-    changelog = "https://github.com/blaze/datashape/releases/tag/${version}";
     homepage = "https://github.com/ContinuumIO/datashape";
     description = "A data description language";
     license = licenses.bsd2;
@@ -501,9 +466,9 @@ buildPythonPackage rec {
 ```
 
 We can see several runtime dependencies, `numpy`, `multipledispatch`, and
-`python-dateutil`. Furthermore, we have `nativeCheckInputs` with `pytest`.
-`pytest` is a test runner and is only used during the `checkPhase` and is
-therefore not added to `propagatedBuildInputs`.
+`python-dateutil`. Furthermore, we have one `nativeCheckInputs`, i.e. `pytest`. `pytest` is a
+test runner and is only used during the `checkPhase` and is therefore not added
+to `propagatedBuildInputs`.
 
 In the previous case we had only dependencies on other Python packages to consider.
 Occasionally you have also system libraries to consider. E.g., `lxml` provides
@@ -511,29 +476,20 @@ Python bindings to `libxml2` and `libxslt`. These libraries are only required
 when building the bindings and are therefore added as `buildInputs`.
 
 ```nix
-{ lib
-, pkgs
-, buildPythonPackage
-, fetchPypi
-}:
+{ lib, pkgs, buildPythonPackage, fetchPypi }:
 
 buildPythonPackage rec {
   pname = "lxml";
   version = "3.4.4";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
     hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
   };
 
-  buildInputs = [
-    pkgs.libxml2
-    pkgs.libxslt
-  ];
+  buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
 
   meta = with lib; {
-    changelog = "https://github.com/lxml/lxml/releases/tag/lxml-${version}";
     description = "Pythonic binding for the libxml2 and libxslt libraries";
     homepage = "https://lxml.de";
     license = licenses.bsd3;
@@ -553,47 +509,30 @@ The bindings don't expect to find each of them in a different folder, and
 therefore we have to set `LDFLAGS` and `CFLAGS`.
 
 ```nix
-{ lib
-, pkgs
-, buildPythonPackage
-, fetchPypi
-
-# dependencies
-, numpy
-, scipy
-}:
+{ lib, pkgs, buildPythonPackage, fetchPypi, numpy, scipy }:
 
 buildPythonPackage rec {
   pname = "pyFFTW";
   version = "0.9.2";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
     hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
   };
 
-  buildInputs = [
-    pkgs.fftw
-    pkgs.fftwFloat
-    pkgs.fftwLongDouble
-  ];
+  buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
 
-  propagatedBuildInputs = [
-    numpy
-    scipy
-  ];
+  propagatedBuildInputs = [ numpy scipy ];
+
+  # Tests cannot import pyfftw. pyfftw works fine though.
+  doCheck = false;
 
   preConfigure = ''
     export LDFLAGS="-L${pkgs.fftw.dev}/lib -L${pkgs.fftwFloat.out}/lib -L${pkgs.fftwLongDouble.out}/lib"
     export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
   '';
 
-  # Tests cannot import pyfftw. pyfftw works fine though.
-  doCheck = false;
-
   meta = with lib; {
-    changelog = "https://github.com/pyFFTW/pyFFTW/releases/tag/v${version}";
     description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
     homepage = "http://hgomersall.github.com/pyFFTW";
     license = with licenses; [ bsd2 bsd3 ];
@@ -651,7 +590,7 @@ To filter tests using pytest, one can do the following:
   checkPhase = ''
     runHook preCheck
 
-    pytest tests/ --ignore=tests/integration -k 'not download and not update' --ignore=tests/test_failing.py
+    pytest tests/ --ignore=tests/integration -k 'not download and not update'
 
     runHook postCheck
   '';
@@ -679,15 +618,10 @@ 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
-  ];
+  nativeCheckInputs = [ pytestCheckHook ];
 
   # requires additional data
-  pytestFlagsArray = [
-    "tests/"
-    "--ignore=tests/integration"
-  ];
+  pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
 
   disabledTests = [
     # touches network
@@ -729,10 +663,7 @@ To help ensure the package still works, `pythonImportsCheck` can attempt to impo
 the listed modules.
 
 ```
-  pythonImportsCheck = [
-    "requests"
-    "urllib"
-  ];
+  pythonImportsCheck = [ "requests" "urllib" ];
 ```
 
 roughly translates to:
@@ -773,16 +704,9 @@ pkg3>=1.0,<=2.0
 we can do:
 
 ```
-  nativeBuildInputs = [
-    pythonRelaxDepsHook
-  ];
-  pythonRelaxDeps = [
-    "pkg1"
-    "pkg3"
-  ];
-  pythonRemoveDeps = [
-    "pkg2"
-  ];
+  nativeBuildInputs = [ pythonRelaxDepsHook ];
+  pythonRelaxDeps = [ "pkg1" "pkg3" ];
+  pythonRemoveDeps = [ "pkg2" ];
 ```
 
 which would result in the following `requirements.txt` file:
@@ -825,13 +749,9 @@ with the exception of `other` (see `format` in
 `unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:
 
 ```
-  nativeCheckInputs = [
-    unittestCheckHook
-  ];
+  nativeCheckInputs = [ unittestCheckHook ];
 
-  unittestFlagsArray = [
-    "-s" "tests" "-v"
-  ];
+  unittestFlagsArray = [ "-s" "tests" "-v" ];
 ```
 
 #### Using sphinxHook {#using-sphinxhook}
@@ -896,7 +816,7 @@ If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
 is a local source, and if the local source has a `setup.py`, then development
 mode is activated.
 
-In the following example, we create a simple environment that has a Python 3.11
+In the following example, we create a simple environment that has a Python 3.9
 version of our package in it, as well as its dependencies and other packages we
 like to have in the environment, all specified with `propagatedBuildInputs`.
 Indeed, we can just add any package we like to have in our environment to
@@ -904,16 +824,12 @@ Indeed, we can just add any package we like to have in our environment to
 
 ```nix
 with import <nixpkgs> {};
-with python311Packages;
+with python39Packages;
 
 buildPythonPackage rec {
   name = "mypackage";
   src = ./path/to/package/source;
-  propagatedBuildInputs = [
-    pytest
-    numpy
-    pkgs.libsndfile
-  ];
+  propagatedBuildInputs = [ pytest numpy pkgs.libsndfile ];
 }
 ```
 
@@ -941,14 +857,11 @@ Let's split the package definition from the environment definition.
 We first create a function that builds `toolz` in `~/path/to/toolz/release.nix`
 
 ```nix
-{ lib
-, buildPythonPackage
-}:
+{ lib, buildPythonPackage }:
 
 buildPythonPackage rec {
   pname = "toolz";
   version = "0.10.0";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
@@ -956,7 +869,6 @@ buildPythonPackage rec {
   };
 
   meta = with lib; {
-    changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
     homepage = "https://github.com/pytoolz/toolz/";
     description = "List processing tools and functional utilities";
     license = licenses.bsd3;
@@ -973,13 +885,9 @@ with import <nixpkgs> {};
 
 ( let
     toolz = callPackage /path/to/toolz/release.nix {
-      buildPythonPackage = python310
-Packages.buildPythonPackage;
+      buildPythonPackage = python38Packages.buildPythonPackage;
     };
-  in python310.withPackages (ps: [
-    ps.numpy
-    toolz
-  ])
+  in python38.withPackages (ps: [ ps.numpy toolz ])
 ).env
 ```
 
@@ -987,17 +895,17 @@ Important to remember is that the Python version for which the package is made
 depends on the `python` derivation that is passed to `buildPythonPackage`. Nix
 tries to automatically pass arguments when possible, which is why generally you
 don't explicitly define which `python` derivation should be used. In the above
-example we use `buildPythonPackage` that is part of the set `python3Packages`,
-and in this case the `python3` interpreter is automatically used.
+example we use `buildPythonPackage` that is part of the set `python38Packages`,
+and in this case the `python38` interpreter is automatically used.
 
 ## Reference {#reference}
 
 ### Interpreters {#interpreters}
 
-Versions 2.7, 3.8, 3.9, 3.10 and 3.11 of the CPython interpreter are available
-as respectively `python27`, `python38`, `python39`, `python310` and `python311`.
+Versions 2.7, 3.7, 3.8, 3.9 and 3.10 of the CPython interpreter are available
+as respectively `python27`, `python37`, `python38`, `python39` and `python310`.
 The aliases `python2` and `python3` correspond to respectively `python27` and
-`python310`. The attribute `python` maps to `python2`. The PyPy interpreters
+`python39`. The attribute `python` maps to `python2`. The PyPy interpreters
 compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
 aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix
 expressions for the interpreters can be found in
@@ -1020,7 +928,7 @@ Each interpreter has the following attributes:
 - `buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
 - `withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
 - `sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
-- `executable`. Name of the interpreter executable, e.g. `python3.10`.
+- `executable`. Name of the interpreter executable, e.g. `python3.8`.
 - `pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
 
 ### Optimizations {#optimizations}
@@ -1060,7 +968,7 @@ attribute set is created for each available Python interpreter. The available
 sets are
 
 * `pkgs.python27Packages`
-* `pkgs.python3Packages`
+* `pkgs.python37Packages`
 * `pkgs.python38Packages`
 * `pkgs.python39Packages`
 * `pkgs.python310Packages`
@@ -1070,7 +978,7 @@ sets are
 and the aliases
 
 * `pkgs.python2Packages` pointing to `pkgs.python27Packages`
-* `pkgs.python3Packages` pointing to `pkgs.python310Packages`
+* `pkgs.python3Packages` pointing to `pkgs.python39Packages`
 * `pkgs.pythonPackages` pointing to `pkgs.python2Packages`
 
 #### `buildPythonPackage` function {#buildpythonpackage-function}
@@ -1082,28 +990,11 @@ using setup hooks.
 The following is an example:
 
 ```nix
-{ lib
-, buildPythonPackage
-, fetchPypi
-
-# build-system
-, setuptools-scm
-
-# dependencies
-, attrs
-, pluggy
-, py
-, setuptools
-, six
-
-# tests
-, hypothesis
- }:
+{ lib, buildPythonPackage, fetchPypi, hypothesis, setuptools-scm, attrs, py, setuptools, six, pluggy }:
 
 buildPythonPackage rec {
   pname = "pytest";
   version = "3.3.1";
-  format = "setuptools";
 
   src = fetchPypi {
     inherit pname version;
@@ -1115,35 +1006,20 @@ buildPythonPackage rec {
     rm testing/test_argcomplete.py
   '';
 
-  nativeBuildInputs = [
-    setuptools-scm
-  ];
-
-  propagatedBuildInputs = [
-    attrs
-    py
-    setuptools
-    six
-    pluggy
-  ];
-
-  nativeCheckInputs = [
-    hypothesis
-  ];
+  nativeCheckInputs = [ hypothesis ];
+  nativeBuildInputs = [ setuptools-scm ];
+  propagatedBuildInputs = [ attrs py setuptools six pluggy ];
 
   meta = with lib; {
-    changelog = "https://github.com/pytest-dev/pytest/releases/tag/${version}";
-    description = "Framework for writing tests";
-    homepage = "https://github.com/pytest-dev/pytest";
-    license = licenses.mit;
     maintainers = with maintainers; [ domenkozar lovek323 madjar lsix ];
+    description = "Framework for writing tests";
   };
 }
 ```
 
 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
@@ -1229,7 +1105,7 @@ with import <nixpkgs> {};
     packageOverrides = self: super: {
       pandas = super.pandas.overridePythonAttrs(old: rec {
         version = "0.19.1";
-        src =  fetchPypi {
+        src =  super.fetchPypi {
           pname = "pandas";
           inherit version;
           hash = "sha256-JQn+rtpy/OA2deLszSKEuxyttqBzcAil50H+JDHUdCE=";
@@ -1238,10 +1114,10 @@ with import <nixpkgs> {};
     };
   in pkgs.python3.override {inherit packageOverrides; self = python;};
 
-in python.withPackages(ps: [ ps.blaze ])).env
+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
@@ -1284,25 +1160,18 @@ called with `callPackage` and passed `python` or `pythonPackages` (possibly
 specifying an interpreter version), like this:
 
 ```nix
-{ lib
-, python3
-, fetchPypi
-}:
+{ lib, python3 }:
 
 python3.pkgs.buildPythonApplication rec {
   pname = "luigi";
   version = "2.7.9";
-  format = "setuptools";
 
-  src = fetchPypi {
+  src = python3.pkgs.fetchPypi {
     inherit pname version;
     hash  = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
   };
 
-  propagatedBuildInputs = with python3.pkgs; [
-    tornado
-    python-daemon
-  ];
+  propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
 
   meta = with lib; {
     ...
@@ -1384,10 +1253,7 @@ running `nix-shell` with the following `shell.nix`
 with import <nixpkgs> {};
 
 (python3.buildEnv.override {
-  extraLibs = with python3Packages; [
-    numpy
-    requests
-  ];
+  extraLibs = with python3Packages; [ numpy requests ];
 }).env
 ```
 
@@ -1413,7 +1279,7 @@ example for the Pyramid Web Framework environment can be written like this:
 ```nix
 with import <nixpkgs> {};
 
-python.withPackages (ps: [ ps.pyramid ])
+python.withPackages (ps: [ps.pyramid])
 ```
 
 `withPackages` passes the correct package set for the specific interpreter
@@ -1423,7 +1289,7 @@ version as an argument to the function. In the above example, `ps` equals
 ```nix
 with import <nixpkgs> {};
 
-python3.withPackages (ps: [ ps.pyramid ])
+python3.withPackages (ps: [ps.pyramid])
 ```
 
 Now, `ps` is set to `python3Packages`, matching the version of the interpreter.
@@ -1435,10 +1301,7 @@ thus be also written like this:
 ```nix
 with import <nixpkgs> {};
 
-(python3.withPackages (ps: with ps; [
-  numpy
-  requests
-])).env
+(python38.withPackages (ps: [ps.numpy ps.requests])).env
 ```
 
 In contrast to `python.buildEnv`, `python.withPackages` does not support the
@@ -1514,6 +1377,10 @@ Note: There is a boolean value `lib.inNixShell` set to `true` if nix-shell is in
 Packages inside nixpkgs are written by hand. However many tools exist in
 community to help save time. No tool is preferred at the moment.
 
+- [pypi2nix](https://github.com/nix-community/pypi2nix): Generate Nix
+  expressions for your Python project. Note that [sharing derivations from
+  pypi2nix with nixpkgs is possible but not
+  encouraged](https://github.com/nix-community/pypi2nix/issues/222#issuecomment-443497376).
 - [nixpkgs-pytools](https://github.com/nix-community/nixpkgs-pytools)
 - [poetry2nix](https://github.com/nix-community/poetry2nix)
 
@@ -1526,7 +1393,7 @@ has security implications and is relevant for those using Python in a
 
 When the environment variable `DETERMINISTIC_BUILD` is set, all bytecode will
 have timestamp 1. The `buildPythonPackage` function sets `DETERMINISTIC_BUILD=1`
-and [PYTHONHASHSEED=0](https://docs.python.org/3.11/using/cmdline.html#envvar-PYTHONHASHSEED).
+and [PYTHONHASHSEED=0](https://docs.python.org/3.8/using/cmdline.html#envvar-PYTHONHASHSEED).
 Both are also exported in `nix-shell`.
 
 ### Automatic tests {#automatic-tests}
@@ -1541,27 +1408,22 @@ example of such a situation is when `py.test` is used.
 #### Common issues {#common-issues}
 
 * Non-working tests can often be deselected. By default `buildPythonPackage`
-  runs `python setup.py test`. which is deprecated. Most Python modules however
-  do follow the standard test protocol where the pytest runner can be used
-  instead. `pytest` supports the `-k` and `--ignore` parameters to ignore test
-  methods or classes as well as whole files. For `pytestCheckHook` these are
-  conveniently exposed as `disabledTests` and `disabledTestPaths` respectively.
+  runs `python setup.py test`. Most Python modules follows the standard test
+  protocol where the pytest runner can be used instead. `py.test` supports a
+  `-k` parameter to ignore test methods or classes:
 
   ```nix
   buildPythonPackage {
     # ...
-    nativeCheckInputs = [
-      pytestCheckHook
-    ];
+    # assumes the tests are located in tests
+    nativeCheckInputs = [ pytest ];
+    checkPhase = ''
+      runHook preCheck
 
-    disabledTests = [
-      "function_name"
-      "other_function"
-    ];
+      py.test -k 'not function_name and not other_function' tests
 
-    disabledTestPaths = [
-      "this/file.py"
-    ];
+      runHook postCheck
+    '';
   }
   ```
 
@@ -1589,13 +1451,9 @@ with import <nixpkgs> {};
     packageOverrides = self: super: {
       pandas = super.pandas.overridePythonAttrs(old: {name="foo";});
     };
-  in pkgs.python310.override {
-    inherit packageOverrides;
-  };
+  in pkgs.python38.override {inherit packageOverrides;};
 
-in python.withPackages (ps: [
-  ps.pandas
-])).env
+in python.withPackages(ps: [ps.pandas])).env
 ```
 
 Using `nix-build` on this expression will build an environment that contains the
@@ -1615,11 +1473,7 @@ with import <nixpkgs> {};
     packageOverrides = self: super: {
       scipy = super.scipy_0_17;
     };
-  in (pkgs.python310.override {
-    inherit packageOverrides;
-  }).withPackages (ps: [
-    ps.blaze
-  ])
+  in (pkgs.python38.override {inherit packageOverrides;}).withPackages (ps: [ps.blaze])
 ).env
 ```
 
@@ -1633,11 +1487,11 @@ If you want the whole of Nixpkgs to use your modifications, then you can use
 let
   pkgs = import <nixpkgs> {};
   newpkgs = import pkgs.path { overlays = [ (self: super: {
-    python310 = let
+    python38 = let
       packageOverrides = python-self: python-super: {
         numpy = python-super.numpy_1_18;
       };
-    in super.python310.override {inherit packageOverrides;};
+    in super.python38.override {inherit packageOverrides;};
   } ) ]; };
 in newpkgs.inkscape
 ```
@@ -1692,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
 ```
 
@@ -1947,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.
@@ -1967,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.
 
@@ -1982,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/qt.section.md

@@ -10,22 +10,37 @@ pure and explicit at build-time, at the cost of introducing an extra indirection
 
 ## Nix expression for a Qt package (default.nix) {#qt-default-nix}
 
-```nix
-{ stdenv, lib, qtbase, wrapQtAppsHook }:
+```{=docbook}
+<programlisting>
+{ stdenv, lib, qtbase, wrapQtAppsHook }: <co xml:id='qt-default-nix-co-1' />
 
 stdenv.mkDerivation {
   pname = "myapp";
   version = "1.0";
 
   buildInputs = [ qtbase ];
-  nativeBuildInputs = [ wrapQtAppsHook ];
+  nativeBuildInputs = [ wrapQtAppsHook ]; <co xml:id='qt-default-nix-co-2' />
 }
+</programlisting>
+
+ <calloutlist>
+  <callout arearefs='qt-default-nix-co-1'>
+   <para>
+    Import Qt modules directly, that is: <literal>qtbase</literal>, <literal>qtdeclarative</literal>, etc.
+    <emphasis>Do not</emphasis> import Qt package sets such as <literal>qt5</literal>
+    because the Qt versions of dependencies may not be coherent, causing build and runtime failures.
+   </para>
+  </callout>
+  <callout arearefs='qt-default-nix-co-2'>
+    <para>
+      All Qt packages must include <literal>wrapQtAppsHook</literal> in
+      <literal>nativeBuildInputs</literal>, or you must explicitly set
+      <literal>dontWrapQtApps</literal>.
+    </para>
+  </callout>
+ </calloutlist>
 ```
 
-It is important to import Qt modules directly, that is: `qtbase`, `qtdeclarative`, etc. *Do not* import Qt package sets such as `qt5` because the Qt versions of dependencies may not be coherent, causing build and runtime failures.
-
-Additionally all Qt packages must include `wrapQtAppsHook` in `nativeBuildInputs`, or you must explicitly set `dontWrapQtApps`.
-
 ## Locating runtime dependencies {#qt-runtime-dependencies}
 
 Qt applications must be wrapped to find runtime dependencies.

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}
 
@@ -535,9 +530,7 @@ directory of the `tokenizers` project's source archive, we use
 ```nix
 { fetchFromGitHub
 , buildPythonPackage
-, cargo
 , rustPlatform
-, rustc
 , setuptools-rust
 }:
 
@@ -560,12 +553,11 @@ buildPythonPackage rec {
 
   sourceRoot = "source/bindings/python";
 
-  nativeBuildInputs = [
-    cargo
-    rustPlatform.cargoSetupHook
-    rustc
-    setuptools-rust
-  ];
+  nativeBuildInputs = [ setuptools-rust ] ++ (with rustPlatform; [
+    cargoSetupHook
+    rust.cargo
+    rust.rustc
+  ]);
 
   # ...
 }
@@ -650,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
@@ -814,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
@@ -876,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/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/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/meta.chapter.md

@@ -70,7 +70,7 @@ A list of the maintainers of this Nix expression. Maintainers are defined in [`n
 
 ### `mainProgram` {#var-meta-mainProgram}
 
-The name of the main binary for the package. This affects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"`
+The name of the main binary for the package. This effects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"`
 
 ### `priority` {#var-meta-priority}
 
@@ -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`.
 
@@ -128,9 +111,9 @@ Prefer `passthru.tests` for tests that are introduced in nixpkgs because:
 * we can run `passthru.tests` independently
 * `installCheckPhase` adds overhead to each build
 
-For more on how to write and run package tests, see [](#sec-package-tests).
+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:
 
@@ -182,7 +165,7 @@ runCommand "my-package-test" {
 
 ### `timeout` {#var-meta-timeout}
 
-A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, Hydra will fail it due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
+A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
 
 `meta` attributes are not stored in the instantiated derivation.
 Therefore, this setting may be lost when the package is used as a dependency.
@@ -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;
 }
@@ -105,11 +101,11 @@ To build a `stdenv` package in a [`nix-shell`](https://nixos.org/manual/nix/unst
 
 ```bash
 nix-shell '<nixpkgs>' -A some_package
-eval "${unpackPhase:-unpackPhase}"
+eval ${unpackPhase:-unpackPhase}
 cd $sourceRoot
-eval "${patchPhase:-patchPhase}"
-eval "${configurePhase:-configurePhase}"
-eval "${buildPhase:-buildPhase}"
+eval ${patchPhase:-patchPhase}
+eval ${configurePhase:-configurePhase}
+eval ${buildPhase:-buildPhase}
 ```
 
 To modify a [phase](#sec-stdenv-phases), first print it with
@@ -257,7 +253,7 @@ propagated-dep(mapOffset(h0, t0, h1),
 ```
 let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
 
-dep(h0, t0, A, B)
+dep(h0, _, A, B)
 propagated-dep(h1, t1, B, C)
 h0 + h1 in {-1, 0, 1}
 h0 + t1 in {-1, 0, -1}
@@ -286,7 +282,7 @@ This is where “sum-like” comes in from above: We can just sum all of the hos
 
 Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In the former case, the motivation for `mapOffset` is that since its host and target platforms are the same, no transitive dependency of it should be able to “discover” an offset greater than its reduced target offsets. `mapOffset` effectively “squashes” all its transitive dependencies’ offsets so that none will ever be greater than the target offset of the original `h = t` package. In the other case, `h + 1` is skipped over between the host and target offsets. Instead of squashing the offsets, we need to “rip” them apart so no transitive dependencies’ offset is that one.
 
-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 depending 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 unforgeable 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.
+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}
 
@@ -384,107 +380,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 +635,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.
 
@@ -971,8 +899,7 @@ to `~/.gdbinit`. GDB will then be able to find debug information installed via `
 
 The installCheck phase checks whether the package was installed correctly by running its test suite against the installed directories. The default `installCheck` calls `make installcheck`.
 
-It is often better to add tests that are not part of the source distribution to `passthru.tests` (see
-[](#var-meta-tests)). This avoids adding overhead to every build and enables us to run them independently.
+It is often better to add tests that are not part of the source distribution to `passthru.tests` (see <xref linkend="var-meta-tests"/>). This avoids adding overhead to every build and enables us to run them independently.
 
 #### Variables controlling the installCheck phase {#variables-controlling-the-installcheck-phase}
 
@@ -1100,15 +1027,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\>.
 
@@ -1205,7 +1132,7 @@ Nix itself considers a build-time dependency as merely something that should pre
 
 In order to alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
 
-The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
+The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the letter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
 
 The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency. For example, the C compiler wrapper’s setup hook feeds itself flags for each dependency that contains relevant libraries and headers. This is done by defining a bash function, and appending its name to one of `envBuildBuildHooks`, `envBuildHostHooks`, `envBuildTargetHooks`, `envHostHostHooks`, `envHostTargetHooks`, or `envTargetTargetHooks`. These 6 bash variables correspond to the 6 sorts of dependencies by platform (there’s 12 total but we ignore the propagated/non-propagated axis).
 
@@ -1235,7 +1162,7 @@ This runs the strip command on installed binaries and libraries. This removes un
 
 This setup hook patches installed scripts to add Nix store paths to their shebang interpreter as found in the build environment. The [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line tells a Unix-like operating system which interpreter to use to execute the script's contents.
 
-::: {.note}
+::: note
 The [generic builder][generic-builder] populates `PATH` from inputs of the derivation.
 :::
 
@@ -1249,7 +1176,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
@@ -1257,7 +1184,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
@@ -1273,7 +1200,7 @@ patchShebangs --build configure
 
 Interpreter paths that point to a valid Nix store location are not changed.
 
-::: {.note}
+::: note
 A script file must be marked as executable, otherwise it will not be
 considered.
 :::
@@ -1344,7 +1271,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).
@@ -1402,7 +1329,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.
@@ -123,11 +123,7 @@ rec {
          { x = "a"; y = "b"; }
        => { x = "a"; xa = "a"; y = "b"; yb = "b"; }
   */
-  concatMapAttrs = f: v:
-    foldl' mergeAttrs { }
-      (attrValues
-        (mapAttrs f v)
-      );
+  concatMapAttrs = f: flip pipe [ (mapAttrs f) attrValues (foldl' mergeAttrs { }) ];
 
 
   /* Update or set specific paths of an attribute set.
@@ -337,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:

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;

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
@@ -100,7 +100,7 @@ let
       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
@@ -117,11 +117,10 @@ let
     inherit (self.meta) addMetaAttrs dontDistribute setName updateName
       appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
       hiPrioSet getLicenseFromSpdxId getExe;
-    inherit (self.filesystem) pathType pathIsDirectory pathIsRegularFile;
-    inherit (self.sources) cleanSourceFilter
+    inherit (self.sources) pathType pathIsDirectory cleanSourceFilter
       cleanSource sourceByRegex sourceFilesBySuffices
       commitIdFromGitRepo cleanSourceWith pathHasContext
-      canCleanSource pathIsGitRepo;
+      canCleanSource pathIsRegularFile pathIsGitRepo;
     inherit (self.modules) evalModules setDefaultModuleLocation
       unifyModuleSyntax applyModuleArgsIfFunction mergeModules
       mergeModules' mergeOptionDecls evalOptionValue mergeDefinitions
@@ -146,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/derivations.nix

@@ -31,7 +31,7 @@ in
 
         (lazyDerivation { inherit derivation; meta.foo = true; }).meta
 
-    In these expressions, `derivation` _will_ be evaluated:
+    In these expressions, it `derivation` _will_ be evaluated:
 
         "${lazyDerivation { inherit derivation }}"