58 files changed, 142 insertions, 84 deletions

diff --git a/doc/build-helpers.md b/doc/build-helpers.md
new file mode 100644
index 0000000000000..06737e1667602
--- /dev/null
+++ b/doc/build-helpers.md
@@ -0,0 +1,28 @@
+# Build helpers {#part-builders}
+
+A build helper is a function that produces derivations.
+
+:::{.warning}
+This is not to be confused with the [`builder` argument of the Nix `derivation` primitive](https://nixos.org/manual/nix/unstable/language/derivations.html), which refers to the executable that produces the build result, or [remote builder](https://nixos.org/manual/nix/stable/advanced-topics/distributed-builds.html), which refers to a remote  machine that could run such an executable.
+:::
+
+Such a function is usually designed to abstract over a typical workflow for a given programming language or framework.
+This allows declaring a build recipe by setting a limited number of options relevant to the particular use case instead of using the `derivation` function directly.
+
+[`stdenv.mkDerivation`](#part-stdenv) is the most widely used build helper, and serves as a basis for many others.
+In addition, it offers various options to customize parts of the builds.
+
+There is no uniform interface for build helpers.
+[Trivial build helpers](#chap-trivial-builders) and [fetchers](#chap-pkgs-fetchers) have various input types for convenience.
+[Language- or framework-specific build helpers](#chap-language-support) usually follow the style of `stdenv.mkDerivation`, which accepts an attribute set or a fixed-point function taking an attribute set.
+
+```{=include=} chapters
+build-helpers/fetchers.chapter.md
+build-helpers/trivial-build-helpers.chapter.md
+build-helpers/testers.chapter.md
+build-helpers/special.md
+build-helpers/images.md
+hooks/index.md
+languages-frameworks/index.md
+packages/index.md
+```
diff --git a/doc/builders/fetchers.chapter.md b/doc/build-helpers/fetchers.chapter.md
index 7bd1bbd6de029..7bd1bbd6de029 100644
--- a/doc/builders/fetchers.chapter.md
+++ b/doc/build-helpers/fetchers.chapter.md
diff --git a/doc/builders/images.md b/doc/build-helpers/images.md
index 5596784bfa487..5596784bfa487 100644
--- a/doc/builders/images.md
+++ b/doc/build-helpers/images.md
diff --git a/doc/builders/images/appimagetools.section.md b/doc/build-helpers/images/appimagetools.section.md
index 0c72315a26e88..0c72315a26e88 100644
--- a/doc/builders/images/appimagetools.section.md
+++ b/doc/build-helpers/images/appimagetools.section.md
diff --git a/doc/builders/images/binarycache.section.md b/doc/build-helpers/images/binarycache.section.md
index 62e47dad7c66f..62e47dad7c66f 100644
--- a/doc/builders/images/binarycache.section.md
+++ b/doc/build-helpers/images/binarycache.section.md
diff --git a/doc/builders/images/dockertools.section.md b/doc/build-helpers/images/dockertools.section.md
index 42d6e297f529c..42d6e297f529c 100644
--- a/doc/builders/images/dockertools.section.md
+++ b/doc/build-helpers/images/dockertools.section.md
diff --git a/doc/builders/images/makediskimage.section.md b/doc/build-helpers/images/makediskimage.section.md
index e50479c4e83e4..e50479c4e83e4 100644
--- a/doc/builders/images/makediskimage.section.md
+++ b/doc/build-helpers/images/makediskimage.section.md
diff --git a/doc/builders/images/ocitools.section.md b/doc/build-helpers/images/ocitools.section.md
index c35f65bce0073..c35f65bce0073 100644
--- a/doc/builders/images/ocitools.section.md
+++ b/doc/build-helpers/images/ocitools.section.md
diff --git a/doc/builders/images/portableservice.section.md b/doc/build-helpers/images/portableservice.section.md
index 5400928b158f8..5400928b158f8 100644
--- a/doc/builders/images/portableservice.section.md
+++ b/doc/build-helpers/images/portableservice.section.md
diff --git a/doc/builders/images/snaptools.section.md b/doc/build-helpers/images/snaptools.section.md
index 259fa1b061808..259fa1b061808 100644
--- a/doc/builders/images/snaptools.section.md
+++ b/doc/build-helpers/images/snaptools.section.md
diff --git a/doc/builders/special.md b/doc/build-helpers/special.md
index 6d07fa87f3f3e..f88648207fdcd 100644
--- a/doc/builders/special.md
+++ b/doc/build-helpers/special.md
@@ -1,11 +1,10 @@
-# Special builders {#chap-special}
+# Special build helpers {#chap-special}
 
-This chapter describes several special builders.
+This chapter describes several special build helpers.
 
 ```{=include=} sections
 special/fhs-environments.section.md
 special/makesetuphook.section.md
 special/mkshell.section.md
-special/darwin-builder.section.md
 special/vm-tools.section.md
 ```
diff --git a/doc/builders/special/fhs-environments.section.md b/doc/build-helpers/special/fhs-environments.section.md
index 8145fbd730f7e..8145fbd730f7e 100644
--- a/doc/builders/special/fhs-environments.section.md
+++ b/doc/build-helpers/special/fhs-environments.section.md
diff --git a/doc/builders/special/makesetuphook.section.md b/doc/build-helpers/special/makesetuphook.section.md
index eb042412137b8..e83164b7eb701 100644
--- a/doc/builders/special/makesetuphook.section.md
+++ b/doc/build-helpers/special/makesetuphook.section.md
@@ -1,6 +1,6 @@
 # pkgs.makeSetupHook {#sec-pkgs.makeSetupHook}
 
-`pkgs.makeSetupHook` is a builder that produces hooks that go in to `nativeBuildInputs`
+`pkgs.makeSetupHook` is a build helper that produces hooks that go in to `nativeBuildInputs`
 
 ## Usage {#sec-pkgs.makeSetupHook-usage}
 
diff --git a/doc/builders/special/mkshell.section.md b/doc/build-helpers/special/mkshell.section.md
index 96d43535955fa..96d43535955fa 100644
--- a/doc/builders/special/mkshell.section.md
+++ b/doc/build-helpers/special/mkshell.section.md
diff --git a/doc/builders/special/vm-tools.section.md b/doc/build-helpers/special/vm-tools.section.md
index 8feab04902d8f..8feab04902d8f 100644
--- a/doc/builders/special/vm-tools.section.md
+++ b/doc/build-helpers/special/vm-tools.section.md
diff --git a/doc/builders/testers.chapter.md b/doc/build-helpers/testers.chapter.md
index b2a581c3dd8d9..b2a581c3dd8d9 100644
--- a/doc/builders/testers.chapter.md
+++ b/doc/build-helpers/testers.chapter.md
diff --git a/doc/builders/trivial-builders.chapter.md b/doc/build-helpers/trivial-build-helpers.chapter.md
index 2cb1f2debcb8e..a0cda86a66071 100644
--- a/doc/builders/trivial-builders.chapter.md
+++ b/doc/build-helpers/trivial-build-helpers.chapter.md
@@ -1,4 +1,4 @@
-# Trivial builders {#chap-trivial-builders}
+# Trivial build helpers {#chap-trivial-builders}
 
 Nixpkgs provides a couple of functions that help with building derivations. The most important one, `stdenv.mkDerivation`, has already been documented above. The following functions wrap `stdenv.mkDerivation`, making it easier to use in certain cases.
 
diff --git a/doc/builders.md b/doc/builders.md
deleted file mode 100644
index 2e959422405b2..0000000000000
--- a/doc/builders.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Builders {#part-builders}
-
-```{=include=} chapters
-builders/fetchers.chapter.md
-builders/trivial-builders.chapter.md
-builders/testers.chapter.md
-builders/special.md
-builders/images.md
-hooks/index.md
-languages-frameworks/index.md
-builders/packages/index.md
-```
diff --git a/doc/functions/fileset.section.md b/doc/functions/fileset.section.md
index 08b9ba9eaedc0..c42337feaba4f 100644
--- a/doc/functions/fileset.section.md
+++ b/doc/functions/fileset.section.md
@@ -6,11 +6,8 @@ The [`lib.fileset`](#sec-functions-library-fileset) library allows you to work w
 A file set is a mathematical set of local files that can be added to the Nix store for use in Nix derivations.
 File sets are easy and safe to use, providing obvious and composable semantics with good error messages to prevent mistakes.
 
-These sections apply to the entire library.
 See the [function reference](#sec-functions-library-fileset) for function-specific documentation.
 
-The file set library is currently somewhat limited but is being expanded to include more functions over time.
-
 ## Implicit coercion from paths to file sets {#sec-fileset-path-coercion}
 
 All functions accepting file sets as arguments can also accept [paths](https://nixos.org/manual/nix/stable/language/values.html#type-path) as arguments.
diff --git a/doc/hooks/autopatchelf.section.md b/doc/hooks/autopatchelf.section.md
index 008a90d46140c..995204b902199 100644
--- a/doc/hooks/autopatchelf.section.md
+++ b/doc/hooks/autopatchelf.section.md
@@ -6,6 +6,6 @@ You can also specify a `runtimeDependencies` variable which lists dependencies t
 
 In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
 
-By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
+By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to `[ "*" ]` to ignore all missing dependencies.
 
 The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.
diff --git a/doc/languages-frameworks/agda.section.md b/doc/languages-frameworks/agda.section.md
index ff3d70ef0c626..cb1f12eec234a 100644
--- a/doc/languages-frameworks/agda.section.md
+++ b/doc/languages-frameworks/agda.section.md
@@ -146,7 +146,7 @@ agdaPackages.mkDerivation {
 
 ### Building Agda packages {#building-agda-packages}
 
-The default build phase for `agdaPackages.mkDerivation` simply runs `agda` on the `Everything.agda` file.
+The default build phase for `agdaPackages.mkDerivation` runs `agda` on the `Everything.agda` file.
 If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.
 Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.
 `agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.
@@ -250,7 +250,7 @@ Usually, the maintainers will answer within a week or two with a new release.
 Bumping the version of that reverse dependency should be a further commit on your PR.
 
 In the rare case that a new release is not to be expected within an acceptable time,
-simply mark the broken package as broken by setting `meta.broken = true;`.
+mark the broken package as broken by setting `meta.broken = true;`.
 This will exclude it from the build test.
 It can be added later when it is fixed,
 and does not hinder the advancement of the whole package set in the meantime.
diff --git a/doc/languages-frameworks/beam.section.md b/doc/languages-frameworks/beam.section.md
index 2cb4863fc53be..1e83d4b93c7c5 100644
--- a/doc/languages-frameworks/beam.section.md
+++ b/doc/languages-frameworks/beam.section.md
@@ -44,7 +44,7 @@ There is also a `buildMix` helper, whose behavior is closer to that of `buildErl
 
 ## How to Install BEAM Packages {#how-to-install-beam-packages}
 
-BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.
+BEAM builders are not registered at the top level, because they are not relevant to the vast majority of Nix users.
 To use any of those builders into your environment, refer to them by their attribute path under `beamPackages`, e.g. `beamPackages.rebar3`:
 
 ::: {.example #ex-beam-ephemeral-shell}
diff --git a/doc/languages-frameworks/dart.section.md b/doc/languages-frameworks/dart.section.md
index 8d9c062f4220f..9da43714a164d 100644
--- a/doc/languages-frameworks/dart.section.md
+++ b/doc/languages-frameworks/dart.section.md
@@ -8,7 +8,7 @@ It fetches its Dart dependencies automatically through `fetchDartDeps`, and (thr
 
 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)).
+`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, 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.
 
diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md
index 6b9ce32d17362..b0b5f5c3bb2f1 100644
--- a/doc/languages-frameworks/haskell.section.md
+++ b/doc/languages-frameworks/haskell.section.md
@@ -177,7 +177,7 @@ exactly one version. Those versions need to satisfy all the version constraints
 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
+It will 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).
 
@@ -780,7 +780,7 @@ there instead.
 The top level `pkgs.haskell-language-server` attribute is just a convenience
 wrapper to make it possible to install HLS for multiple GHC versions at the
 same time. If you know, that you only use one GHC version, e.g., in a project
-specific `nix-shell` you can simply use
+specific `nix-shell` you can use
 `pkgs.haskellPackages.haskell-language-server` or
 `pkgs.haskell.packages.*.haskell-language-server` from the package set you use.
 
diff --git a/doc/languages-frameworks/javascript.section.md b/doc/languages-frameworks/javascript.section.md
index f35fd83cc5949..79cb09572503b 100644
--- a/doc/languages-frameworks/javascript.section.md
+++ b/doc/languages-frameworks/javascript.section.md
@@ -209,6 +209,7 @@ In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json
 * `npmPackFlags`: Flags to pass to `npm pack`.
 * `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`.
 * `makeWrapperArgs`: Flags to pass to `makeWrapper`, added to executable calling the generated `.js` with `node` as an interpreter. These scripts are defined in `package.json`.
+* `nodejs`: The `nodejs` package to build against, using the corresponding `npm` shipped with that version of `node`. Defaults to `pkgs.nodejs`.
 
 #### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
 
diff --git a/doc/languages-frameworks/lisp.section.md b/doc/languages-frameworks/lisp.section.md
index 8712c34120645..09193093b08fa 100644
--- a/doc/languages-frameworks/lisp.section.md
+++ b/doc/languages-frameworks/lisp.section.md
@@ -66,7 +66,7 @@ buildPhase = ''
 To save some work of writing Nix expressions, there is a script that imports all
 the packages distributed by Quicklisp into `imported.nix`. This works by parsing
 its `releases.txt` and `systems.txt` files, which are published every couple of
-months on [quicklisp.org](http://beta.quicklisp.org/dist/quicklisp.txt).
+months on [quicklisp.org](https://beta.quicklisp.org/dist/quicklisp.txt).
 
 The import process is implemented in the `import` directory as Common Lisp
 code in the `org.lispbuilds.nix` ASDF system. To run the script, one can
@@ -268,7 +268,7 @@ getting an environment variable for `ext:getenv`. This will load the
 
 ### Loading systems {#lisp-loading-systems}
 
-There, you can simply use `asdf:load-system`. This works by setting the right
+There, you can 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.
diff --git a/doc/languages-frameworks/maven.section.md b/doc/languages-frameworks/maven.section.md
index 7e287a097c7e0..b86733a758984 100644
--- a/doc/languages-frameworks/maven.section.md
+++ b/doc/languages-frameworks/maven.section.md
@@ -53,7 +53,7 @@ After setting `maven.buildMavenPackage`, we then do standard Java `.jar` install
 
 Maven defines default versions for its core plugins, e.g. `maven-compiler-plugin`. If your project does not override these versions, an upgrade of Maven will change the version of the used plugins, and therefore the derivation and hash.
 
-When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will simply be built on the derivation of old plugins, and fail because the requested plugins are missing.
+When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will be built on the derivation of old plugins, and fail because the requested plugins are missing.
 
 This clearly prevents automatic upgrades of Maven: a manual effort must be made throughout nixpkgs by any maintainer wishing to push the upgrades.
 
diff --git a/doc/languages-frameworks/php.section.md b/doc/languages-frameworks/php.section.md
index 377e3947b2a29..154d8174f9aaf 100644
--- a/doc/languages-frameworks/php.section.md
+++ b/doc/languages-frameworks/php.section.md
@@ -58,7 +58,7 @@ php.withExtensions ({ enabled, all }:
   ++ [ all.imagick ])
 ```
 
-To build your list of extensions from the ground up, you can simply
+To build your list of extensions from the ground up, you can
 ignore `enabled`:
 
 ```nix
@@ -140,7 +140,7 @@ Example of building `composer` with additional extensions:
 ### Overriding PHP packages {#ssec-php-user-guide-overriding-packages}
 
 `php-packages.nix` form a scope, allowing us to override the packages defined
-within. For example, to apply a patch to a `mysqlnd` extension, you can simply
+within. For example, to apply a patch to a `mysqlnd` extension, you can
 pass an overlay-style function to `php`’s `packageOverrides` argument:
 
 ```nix
@@ -191,7 +191,7 @@ using the `bin` attribute in `composer.json`, these binaries will be
 automatically linked and made accessible in the derivation. In this context,
 "binaries" refer to PHP scripts that are intended to be executable.
 
-To use the helper effectively, simply add the `vendorHash` attribute, which
+To use the helper effectively, add the `vendorHash` attribute, which
 enables the wrapper to handle the heavy lifting.
 
 Internally, the helper operates in three stages:
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index cdd5c806912e1..19d4496eef516 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -9,8 +9,8 @@
 | python27   | python2, python | CPython 2.7 |
 | python38   |                 | CPython 3.8 |
 | python39   |                 | CPython 3.9 |
-| python310  | python3         | CPython 3.10 |
-| python311  |                 | CPython 3.11 |
+| python310  |                 | CPython 3.10 |
+| python311  | python3         | CPython 3.11 |
 | python312  |                 | CPython 3.12 |
 | python313  |                 | CPython 3.13 |
 | pypy27     | pypy2, pypy     | PyPy2.7 |
@@ -64,12 +64,14 @@ sets are
 * `pkgs.python39Packages`
 * `pkgs.python310Packages`
 * `pkgs.python311Packages`
+* `pkgs.python312Packages`
+* `pkgs.python313Packages`
 * `pkgs.pypyPackages`
 
 and the aliases
 
 * `pkgs.python2Packages` pointing to `pkgs.python27Packages`
-* `pkgs.python3Packages` pointing to `pkgs.python310Packages`
+* `pkgs.python3Packages` pointing to `pkgs.python311Packages`
 * `pkgs.pythonPackages` pointing to `pkgs.python2Packages`
 
 #### `buildPythonPackage` function {#buildpythonpackage-function}
@@ -142,7 +144,7 @@ buildPythonPackage rec {
 
 The `buildPythonPackage` mainly does four things:
 
-* In the [`buildPhase`](#build-phase), it calls `${python.pythonForBuild.interpreter} setup.py bdist_wheel` to
+* In the [`buildPhase`](#build-phase), it calls `${python.pythonOnBuildForHost.interpreter} setup.py bdist_wheel` to
   build a wheel binary zipfile.
 * In the [`installPhase`](#ssec-install-phase), it installs the wheel file using `pip install *.whl`.
 * In the [`postFixup`](#var-stdenv-postFixup) phase, the `wrapPythonPrograms` bash function is called to
@@ -262,7 +264,7 @@ python3MyBlas = pkgs.python3.override {
 ```
 
 This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.
-Note that using simply `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in
+Note that using `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in
 compilation issues, because scipy dependencies need to use the same blas implementation as well.
 
 #### `buildPythonApplication` function {#buildpythonapplication-function}
@@ -278,16 +280,16 @@ the packages with the version of the interpreter. Because this is irrelevant for
 applications, the prefix is omitted.
 
 When packaging a Python application with [`buildPythonApplication`](#buildpythonapplication-function), it should be
-called with `callPackage` and passed `python` or `pythonPackages` (possibly
+called with `callPackage` and passed `python3` or `python3Packages` (possibly
 specifying an interpreter version), like this:
 
 ```nix
 { lib
-, python3
+, python3Packages
 , fetchPypi
 }:
 
-python3.pkgs.buildPythonApplication rec {
+python3Packages.buildPythonApplication rec {
   pname = "luigi";
   version = "2.7.9";
   pyproject = true;
@@ -298,13 +300,13 @@ python3.pkgs.buildPythonApplication rec {
   };
 
   nativeBuildInputs = [
-    python3.pkgs.setuptools
-    python3.pkgs.wheel
+    python3Packages.setuptools
+    python3Packages.wheel
   ];
 
-  propagatedBuildInputs = with python3.pkgs; [
-    tornado
-    python-daemon
+  propagatedBuildInputs = [
+    python3Packages.tornado
+    python3Packages.python-daemon
   ];
 
   meta = with lib; {
@@ -320,7 +322,7 @@ luigi = callPackage ../applications/networking/cluster/luigi { };
 ```
 
 Since the package is an application, a consumer doesn't need to care about
-Python versions or modules, which is why they don't go in `pythonPackages`.
+Python versions or modules, which is why they don't go in `python3Packages`.
 
 #### `toPythonApplication` function {#topythonapplication-function}
 
@@ -336,7 +338,7 @@ the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
 applied to the reference:
 
 ```nix
-youtube-dl = with pythonPackages; toPythonApplication youtube-dl;
+youtube-dl = with python3Packages; toPythonApplication youtube-dl;
 ```
 
 #### `toPythonModule` function {#topythonmodule-function}
@@ -365,8 +367,8 @@ Saving the following as `default.nix`
 ```nix
 with import <nixpkgs> {};
 
-python.buildEnv.override {
-  extraLibs = [ pythonPackages.pyramid ];
+python3.buildEnv.override {
+  extraLibs = [ python3Packages.pyramid ];
   ignoreCollisions = true;
 }
 ```
@@ -431,7 +433,7 @@ python3.withPackages (ps: [ ps.pyramid ])
 
 Now, `ps` is set to `python3Packages`, matching the version of the interpreter.
 
-As [`python.withPackages`](#python.withpackages-function) simply uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also
+As [`python.withPackages`](#python.withpackages-function) uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also
 supports the `env` attribute. The `shell.nix` file from the previous section can
 thus be also written like this:
 
@@ -496,9 +498,9 @@ Given a `default.nix`:
 ```nix
 with import <nixpkgs> {};
 
-pythonPackages.buildPythonPackage {
+python3Packages.buildPythonPackage {
   name = "myproject";
-  buildInputs = with pythonPackages; [ pyramid ];
+  buildInputs = with python3Packages; [ pyramid ];
 
   src = ./.;
 }
@@ -510,7 +512,7 @@ the package would be built with `nix-build`.
 Shortcut to setup environments with C headers/libraries and Python packages:
 
 ```shell
-nix-shell -p pythonPackages.pyramid zlib libjpeg git
+nix-shell -p python3Packages.pyramid zlib libjpeg git
 ```
 
 ::: {.note}
@@ -525,7 +527,7 @@ There is a boolean value `lib.inNixShell` set to `true` if nix-shell is invoked.
 
 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
+interpreter, which is currently CPython 3.11. 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
 the default PyPy interpreter.
@@ -543,7 +545,7 @@ 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 `python3.pkgs.toolz`, and the CPython 3.11 version is `python311.pkgs.toolz`.
 The main package set contains aliases to these package sets, e.g.
 `pythonPackages` refers to `python.pkgs` and `python311Packages` to
 `python311.pkgs`.
@@ -680,7 +682,7 @@ b = np.array([3,4])
 print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
 ```
 
-Then we simply execute it, without requiring any environment setup at all!
+Then we execute it, without requiring any environment setup at all!
 
 ```sh
 $ ./foo.py
@@ -1682,7 +1684,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.pythonOnBuildForHost.interpreter} setup.py install_data --install-dir=$out --root=$out
 sed -i '/ = data\_files/d' setup.py
 ```
 
@@ -1711,7 +1713,7 @@ This is an example of a `default.nix` for a `nix-shell`, which allows to consume
 a virtual environment created by `venv`, and install Python modules through
 `pip` the traditional way.
 
-Create this `default.nix` file, together with a `requirements.txt` and simply
+Create this `default.nix` file, together with a `requirements.txt` and
 execute `nix-shell`.
 
 ```nix
@@ -1835,7 +1837,7 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
   };
 ```
 
-`pythonPackages.twisted` is now globally overridden.
+`python3Packages.twisted` is now globally overridden.
 All packages and also all NixOS services that reference `twisted`
 (such as `services.buildbot-worker`) now use the new definition.
 Note that `python-super` refers to the old package set and `python-self`
@@ -1845,7 +1847,7 @@ To modify only a Python package set instead of a whole Python derivation, use
 this snippet:
 
 ```nix
-  myPythonPackages = pythonPackages.override {
+  myPythonPackages = python3Packages.override {
     overrides = self: super: {
       twisted = ...;
     };
@@ -2025,7 +2027,9 @@ The following rules are desired to be respected:
   disabled individually. Try to avoid disabling the tests altogether. In any
   case, when you disable tests, leave a comment explaining why.
 * Commit names of Python libraries should reflect that they are Python
-  libraries, so write for example `pythonPackages.numpy: 1.11 -> 1.12`.
+  libraries, so write for example `python311Packages.numpy: 1.11 -> 1.12`.
+  It is highly recommended to specify the current default version to enable
+  automatic build by ofborg.
 * Attribute names in `python-packages.nix` as well as `pname`s should match the
   library's name on PyPI, but be normalized according to [PEP
   0503](https://www.python.org/dev/peps/pep-0503/#normalized-names). This means
diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md
index d3b896686c067..920c84eee689c 100644
--- a/doc/languages-frameworks/ruby.section.md
+++ b/doc/languages-frameworks/ruby.section.md
@@ -94,7 +94,7 @@ $ bundle lock
 $ bundix
 ```
 
-If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.
+If you already have a `Gemfile.lock`, you can run `bundix` and it will work the same.
 
 To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.
 
@@ -251,7 +251,7 @@ source 'https://rubygems.org' do
 end
 ```
 
-If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.
+If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by running the `bundle lock` and `bundix` steps again.
 
 Now you can also make a `default.nix` that looks like this:
 
diff --git a/doc/languages-frameworks/swift.section.md b/doc/languages-frameworks/swift.section.md
index 1cc452cc9b9bf..213d444f499fa 100644
--- a/doc/languages-frameworks/swift.section.md
+++ b/doc/languages-frameworks/swift.section.md
@@ -32,7 +32,7 @@ look for the following directories:
   (If not targeting macOS, replace `macosx` with the Xcode platform name.)
 - On other platforms: `lib/swift/linux/x86_64`
   (Where `linux` and `x86_64` are from lowercase `uname -sm`.)
-- For convenience, Nixpkgs also adds simply `lib/swift` to the search path.
+- For convenience, Nixpkgs also adds `lib/swift` to the search path.
   This can save a bit of work packaging Swift modules, because many Nix builds
   will produce output for just one target any way.
 
@@ -123,7 +123,7 @@ swiftpmFlags = [ "--disable-dead-strip" ];
 
 The default `buildPhase` already passes `-j` for parallel building.
 
-If these two customization options are insufficient, simply provide your own
+If these two customization options are insufficient, provide your own
 `buildPhase` that invokes `swift build`.
 
 ### Running tests {#ssec-swiftpm-running-tests}
diff --git a/doc/languages-frameworks/texlive.section.md b/doc/languages-frameworks/texlive.section.md
index 777e94c16f18b..2ba846dc492d9 100644
--- a/doc/languages-frameworks/texlive.section.md
+++ b/doc/languages-frameworks/texlive.section.md
@@ -2,6 +2,46 @@
 
 Since release 15.09 there is a new TeX Live packaging that lives entirely under attribute `texlive`.
 
+## User's guide (experimental new interface) {#sec-language-texlive-user-guide-experimental}
+
+Release 23.11 ships with a new interface that will eventually replace `texlive.combine`.
+
+- For basic usage, use some of the prebuilt environments available at the top level, such as `texliveBasic`, `texliveSmall`. For the full list of prebuilt environments, inspect `texlive.schemes`.
+
+- Packages cannot be used directly but must be assembled in an environment. To create or add packages to an environment, use
+  ```nix
+  texliveSmall.withPackages (ps: with ps; [ collection-langkorean algorithms cm-super ])
+  ```
+  The function `withPackages` can be called multiple times to add more packages.
+
+  - **Note.** Within Nixpkgs, packages should only use prebuilt environments as inputs, such as `texliveSmall` or `texliveInfraOnly`, and should not depend directly on `texlive`. Further dependencies should be added by calling `withPackages`. This is to ensure that there is a consistent and simple way to override the inputs.
+
+- `texlive.withPackages` uses the same logic as `buildEnv`. Only parts of a package are installed in an environment: its 'runtime' files (`tex` output), binaries (`out` output), and support files (`tlpkg` output). Moreover, man and info pages are assembled into separate `man` and `info` outputs. To add only the TeX files of a package, or its documentation (`texdoc` output), just specify the outputs:
+  ```nix
+  texlive.withPackages (ps: with ps; [
+    texdoc # recommended package to navigate the documentation
+    perlPackages.LaTeXML.tex # tex files of LaTeXML, omit binaries
+    cm-super
+    cm-super.texdoc # documentation of cm-super
+  ])
+  ```
+
+- All packages distributed by TeX Live, which contains most of CTAN, are available and can be found under `texlive.pkgs`:
+  ```ShellSession
+  $ nix repl
+  nix-repl> :l <nixpkgs>
+  nix-repl> texlive.pkgs.[TAB]
+  ```
+  Note that the packages in `texlive.pkgs` are only provided for search purposes and must not be used directly.
+
+- **Experimental and subject to change without notice:** to add the documentation for all packages in the environment, use
+  ```nix
+  texliveSmall.__overrideTeXConfig { withDocs = true; }
+  ```
+  This can be applied before or after calling `withPackages`.
+
+  The function currently support the parameters `withDocs`, `withSources`, and `requireTeXPackages`.
+
 ## User's guide {#sec-language-texlive-user-guide}
 
 - For basic usage just pull `texlive.combined.scheme-basic` for an environment with basic LaTeX support.
diff --git a/doc/manual.md.in b/doc/manual.md.in
index 6b8d351380f95..52971ff526c28 100644
--- a/doc/manual.md.in
+++ b/doc/manual.md.in
@@ -9,7 +9,7 @@ preface.chapter.md
 using-nixpkgs.md
 lib.md
 stdenv.md
-builders.md
+build-helpers.md
 development.md
 contributing.md
 ```
diff --git a/doc/builders/packages/cataclysm-dda.section.md b/doc/packages/cataclysm-dda.section.md
index f401e9b9efa53..f401e9b9efa53 100644
--- a/doc/builders/packages/cataclysm-dda.section.md
+++ b/doc/packages/cataclysm-dda.section.md
diff --git a/doc/builders/packages/citrix.section.md b/doc/packages/citrix.section.md
index bcf0924249bce..bcf0924249bce 100644
--- a/doc/builders/packages/citrix.section.md
+++ b/doc/packages/citrix.section.md
diff --git a/doc/builders/special/darwin-builder.section.md b/doc/packages/darwin-builder.section.md
index e37fabe01a353..89c2445667dcc 100644
--- a/doc/builders/special/darwin-builder.section.md
+++ b/doc/packages/darwin-builder.section.md
@@ -1,10 +1,10 @@
 # darwin.linux-builder {#sec-darwin-builder}
 
-`darwin.linux-builder` provides a way to bootstrap a Linux builder on a macOS machine.
+`darwin.linux-builder` provides a way to bootstrap a Linux remote builder on a macOS machine.
 
 This requires macOS version 12.4 or later.
 
-The builder runs on host port 31022 by default.
+The remote builder runs on host port 31022 by default.
 You can change it by overriding `virtualisation.darwin-builder.hostPort`.
 See the [example](#sec-darwin-builder-example-flake).
 
@@ -15,7 +15,7 @@ words, your `/etc/nix/nix.conf` should have something like:
 extra-trusted-users = <your username goes here>
 ```
 
-To launch the builder, run the following flake:
+To launch the remote builder, run the following flake:
 
 ```ShellSession
 $ nix run nixpkgs#darwin.linux-builder
@@ -57,7 +57,7 @@ builders = ssh-ng://builder@linux-builder ${ARCH}-linux /etc/nix/builder_ed25519
 builders-use-substitutes = true
 ```
 
-To allow Nix to connect to a builder not running on port 22, you will also need to create a new file at `/etc/ssh/ssh_config.d/100-linux-builder.conf`:
+To allow Nix to connect to a remote builder not running on port 22, you will also need to create a new file at `/etc/ssh/ssh_config.d/100-linux-builder.conf`:
 
 ```
 Host linux-builder
@@ -130,11 +130,11 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
 }
 ```
 
-## Reconfiguring the builder {#sec-darwin-builder-reconfiguring}
+## Reconfiguring the remote 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.
+Initially you should not change the remote builder configuration else you will not be
+able to use the binary cache. However, after you have the remote builder running locally
+you may use it to build a modified remote 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.
diff --git a/doc/builders/packages/dlib.section.md b/doc/packages/dlib.section.md
index bd5b1a20a4d46..bd5b1a20a4d46 100644
--- a/doc/builders/packages/dlib.section.md
+++ b/doc/packages/dlib.section.md
diff --git a/doc/builders/packages/eclipse.section.md b/doc/packages/eclipse.section.md
index e19510e131a09..e19510e131a09 100644
--- a/doc/builders/packages/eclipse.section.md
+++ b/doc/packages/eclipse.section.md
diff --git a/doc/builders/packages/elm.section.md b/doc/packages/elm.section.md
index 063dd73d9de43..063dd73d9de43 100644
--- a/doc/builders/packages/elm.section.md
+++ b/doc/packages/elm.section.md
diff --git a/doc/builders/packages/emacs.section.md b/doc/packages/emacs.section.md
index c50c7815537dc..c50c7815537dc 100644
--- a/doc/builders/packages/emacs.section.md
+++ b/doc/packages/emacs.section.md
diff --git a/doc/builders/packages/etc-files.section.md b/doc/packages/etc-files.section.md
index 94a769ed33555..94a769ed33555 100644
--- a/doc/builders/packages/etc-files.section.md
+++ b/doc/packages/etc-files.section.md
diff --git a/doc/builders/packages/firefox.section.md b/doc/packages/firefox.section.md
index 46bc0457a3dc2..46bc0457a3dc2 100644
--- a/doc/builders/packages/firefox.section.md
+++ b/doc/packages/firefox.section.md
diff --git a/doc/builders/packages/fish.section.md b/doc/packages/fish.section.md
index 85b57acd1090f..85b57acd1090f 100644
--- a/doc/builders/packages/fish.section.md
+++ b/doc/packages/fish.section.md
diff --git a/doc/builders/packages/fuse.section.md b/doc/packages/fuse.section.md
index 6deea6b5626ed..6deea6b5626ed 100644
--- a/doc/builders/packages/fuse.section.md
+++ b/doc/packages/fuse.section.md
diff --git a/doc/builders/packages/ibus.section.md b/doc/packages/ibus.section.md
index 817e55d56f1f9..817e55d56f1f9 100644
--- a/doc/builders/packages/ibus.section.md
+++ b/doc/packages/ibus.section.md
diff --git a/doc/builders/packages/index.md b/doc/packages/index.md
index 1f44357024064..1f45018ffc4a0 100644
--- a/doc/builders/packages/index.md
+++ b/doc/packages/index.md
@@ -4,6 +4,7 @@ This chapter contains information about how to use and maintain the Nix expressi
 
 ```{=include=} sections
 citrix.section.md
+darwin-builder.section.md
 dlib.section.md
 eclipse.section.md
 elm.section.md
diff --git a/doc/builders/packages/kakoune.section.md b/doc/packages/kakoune.section.md
index 8e054777a7578..8e054777a7578 100644
--- a/doc/builders/packages/kakoune.section.md
+++ b/doc/packages/kakoune.section.md
diff --git a/doc/builders/packages/linux.section.md b/doc/packages/linux.section.md
index b64da85791a0d..b64da85791a0d 100644
--- a/doc/builders/packages/linux.section.md
+++ b/doc/packages/linux.section.md
diff --git a/doc/builders/packages/locales.section.md b/doc/packages/locales.section.md
index 3a983f13a396e..3a983f13a396e 100644
--- a/doc/builders/packages/locales.section.md
+++ b/doc/packages/locales.section.md
diff --git a/doc/builders/packages/nginx.section.md b/doc/packages/nginx.section.md
index 0704b534e5f72..0704b534e5f72 100644
--- a/doc/builders/packages/nginx.section.md
+++ b/doc/packages/nginx.section.md
diff --git a/doc/builders/packages/opengl.section.md b/doc/packages/opengl.section.md
index f4d282267a079..f4d282267a079 100644
--- a/doc/builders/packages/opengl.section.md
+++ b/doc/packages/opengl.section.md
diff --git a/doc/builders/packages/shell-helpers.section.md b/doc/packages/shell-helpers.section.md
index e7c2b0abebfca..e7c2b0abebfca 100644
--- a/doc/builders/packages/shell-helpers.section.md
+++ b/doc/packages/shell-helpers.section.md
diff --git a/doc/builders/packages/steam.section.md b/doc/packages/steam.section.md
index 25728aa52aef0..a1e88b0d97103 100644
--- a/doc/builders/packages/steam.section.md
+++ b/doc/packages/steam.section.md
@@ -11,7 +11,7 @@ Nix problems and constraints:
 - The `steam.sh` script in `$HOME` cannot be patched, as it is checked and rewritten by steam.
 - The steam binary cannot be patched, it's also checked.
 
-The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented [here](http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html). This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
+The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented [here](https://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html). This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
 
 ## How to play {#sec-steam-play}
 
diff --git a/doc/builders/packages/urxvt.section.md b/doc/packages/urxvt.section.md
index 507feaa6fd861..7aff0997dd2b4 100644
--- a/doc/builders/packages/urxvt.section.md
+++ b/doc/packages/urxvt.section.md
@@ -34,7 +34,7 @@ $ nix repl
 map (p: p.name) pkgs.rxvt-unicode.plugins
 ```
 
-Alternatively, if your shell is bash or zsh and have completion enabled, simply type `nixpkgs.rxvt-unicode.plugins.<tab>`.
+Alternatively, if your shell is bash or zsh and have completion enabled, type `nixpkgs.rxvt-unicode.plugins.<tab>`.
 
 In addition to `plugins` the options `extraDeps` and `perlDeps` can be used to install extra packages. `extraDeps` can be used, for example, to provide `xsel` (a clipboard manager) to the clipboard plugin, without installing it globally:
 
diff --git a/doc/builders/packages/weechat.section.md b/doc/packages/weechat.section.md
index 755b6e6ad1ea4..755b6e6ad1ea4 100644
--- a/doc/builders/packages/weechat.section.md
+++ b/doc/packages/weechat.section.md
diff --git a/doc/builders/packages/xorg.section.md b/doc/packages/xorg.section.md
index ae885f9234677..ae885f9234677 100644
--- a/doc/builders/packages/xorg.section.md
+++ b/doc/packages/xorg.section.md
diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md
index 1dfe25f02654f..26c43bd9e943c 100644
--- a/doc/stdenv/stdenv.chapter.md
+++ b/doc/stdenv/stdenv.chapter.md
@@ -319,7 +319,7 @@ let f(h, h + 1, i) = i + (if i <= 0 then h else h)
 let f(h, h + 1, i) = i + h
 ```
 
-This is where “sum-like” comes in from above: We can just sum all of the host offsets to get the host offset of the transitive dependency. The target offset is the transitive dependency is simply the host offset + 1, just as it was with the dependencies composed to make this transitive one; it can be ignored as it doesn’t add any new information.
+This is where “sum-like” comes in from above: We can just sum all of the host offsets to get the host offset of the transitive dependency. The target offset is the transitive dependency is the host offset + 1, just as it was with the dependencies composed to make this transitive one; it can be ignored as it doesn’t add any new information.
 
 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.
 
@@ -528,7 +528,7 @@ If the returned array contains exactly one object (e.g. `[{}]`), all values are
 ```
 :::
 
-### Recursive attributes in `mkDerivation` {#mkderivation-recursive-attributes}
+### Fixed-point arguments of `mkDerivation` {#mkderivation-recursive-attributes}
 
 If you pass a function to `mkDerivation`, it will receive as its argument the final arguments, including the overrides when reinvoked via `overrideAttrs`. For example:
 
@@ -649,7 +649,7 @@ Zip files are unpacked using `unzip`. However, `unzip` is not in the standard en
 
 #### Directories in the Nix store {#directories-in-the-nix-store}
 
-These are simply copied to the current directory. The hash part of the file name is stripped, e.g. `/nix/store/1wydxgby13cz...-my-sources` would be copied to `my-sources`.
+These are copied to the current directory. The hash part of the file name is stripped, e.g. `/nix/store/1wydxgby13cz...-my-sources` would be copied to `my-sources`.
 
 Additional file types can be supported by setting the `unpackCmd` variable (see below).
 
@@ -788,7 +788,7 @@ Hook executed at the end of the configure phase.
 
 ### The build phase {#build-phase}
 
-The build phase is responsible for actually building the package (e.g. compiling it). The default `buildPhase` simply calls `make` if a file named `Makefile`, `makefile` or `GNUmakefile` exists in the current directory (or the `makefile` is explicitly set); otherwise it does nothing.
+The build phase is responsible for actually building the package (e.g. compiling it). The default `buildPhase` calls `make` if a file named `Makefile`, `makefile` or `GNUmakefile` exists in the current directory (or the `makefile` is explicitly set); otherwise it does nothing.
 
 #### Variables controlling the build phase {#variables-controlling-the-build-phase}
 
@@ -1317,7 +1317,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 latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and 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).
 
diff --git a/doc/using/overlays.chapter.md b/doc/using/overlays.chapter.md
index 6ee52215a4e18..1bec6586f28e1 100644
--- a/doc/using/overlays.chapter.md
+++ b/doc/using/overlays.chapter.md
@@ -77,7 +77,7 @@ In Nixpkgs, we have multiple implementations of the BLAS/LAPACK numerical linear
 
     The Nixpkgs attribute is `openblas` for ILP64 (integer width = 64 bits) and `openblasCompat` for LP64 (integer width = 32 bits).  `openblasCompat` is the default.
 
--   [LAPACK reference](http://www.netlib.org/lapack/) (also provides BLAS and CBLAS)
+-   [LAPACK reference](https://www.netlib.org/lapack/) (also provides BLAS and CBLAS)
 
     The Nixpkgs attribute is `lapack-reference`.
 
@@ -156,7 +156,7 @@ All programs that are built with [MPI](https://en.wikipedia.org/wiki/Message_Pas
 
 -   [MVAPICH](https://mvapich.cse.ohio-state.edu/), attribute name `mvapich`
 
-To provide MPI enabled applications that use `MPICH`, instead of the default `Open MPI`, simply use the following overlay:
+To provide MPI enabled applications that use `MPICH`, instead of the default `Open MPI`, use the following overlay:
 
 ```nix
 self: super: