doc, pkgs: Fix typos (#434909)

doc/README.md

···
 # Contributing to the Nixpkgs reference manual
 
-This directory houses the sources files for the Nixpkgs reference manual.
+This directory houses the source files for the Nixpkgs reference manual.
 
 > [!IMPORTANT]
 > We are actively restructuring our documentation to follow the [Diátaxis framework](https://diataxis.fr/)
···
 
 #### Inline Anchors
 
-Allow linking arbitrary place in the text (e.g. individual list items, sentences…).
+Allow linking to an arbitrary place in the text (e.g. individual list items, sentences…).
 
 They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called [bracketed spans](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/bracketed_spans.md):
 
···
 
 In an effort to keep the Nixpkgs manual in a consistent style, please follow the conventions below, unless they prevent you from properly documenting something.
 In that case, please open an issue about the particular documentation convention and tag it with a "needs: documentation" label.
-When needed, each convention explain why it exists, so you can make a decision whether to follow it or not based on your particular case.
+When needed, each convention explains why it exists, so you can make a decision whether to follow it or not based on your particular case.
 Note that these conventions are about the **structure** of the manual (and its source files), not about the content that goes in it.
 You, as the writer of documentation, are still in charge of its content.
 

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

···
   This can be seen as an equivalent of `FROM fromImage` in a `Dockerfile`.
   A value of `null` can be seen as an equivalent of `FROM scratch`.
 
-  If specified, the layer created by `buildImage` will be appended to the layers defined in the base image, resulting in an image with at least two layers (one or more layers from the base image, and the layer created by `buildImage`).
-  Otherwise, the resulting image with contain the single layer created by `buildImage`.
+  If specified, the layer created by `buildImage` will be appended to the layers defined in the base image, resulting in an image with at least two layers (one or more layers from the base image and the layer created by `buildImage`).
+  Otherwise, the resulting image will contain the single layer created by `buildImage`.
 
   :::{.note}
   Only **Env** configuration is inherited from the base image.
···
   This can be seen as an equivalent of `ADD contents/ /` in a `Dockerfile`.
 
   All the contents specified by `contents` will be added as a final layer in the generated image.
-  They will be added as links to the actual files (e.g. links to the store paths).
+  They will be added as links to the actual files (e.g., links to the store paths).
   The actual files will be added in previous layers.
 
   _Default value:_ `[]`
···
 `gname` (String; _optional_) []{#dockerTools-buildLayeredImage-arg-gname}
 
 : Credentials for Nix store ownership.
-  Can be overridden to e.g. `1000` / `1000` / `"user"` / `"user"` to enable building a container where Nix can be used as an unprivileged user in single-user mode.
+  Can be overridden to, e.g., `1000` / `1000` / `"user"` / `"user"` to enable building a container where Nix can be used as an unprivileged user in single-user mode.
 
   _Default value:_ `0` / `0` / `"root"` / `"root"`
 

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

···
 - automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space
 - multiple partition table layouts: EFI, legacy, legacy + GPT, hybrid, none through `partitionTableType` parameter
 - OVMF or EFI firmwares and variables templates can be customized
-- root filesystem `fsType` can be customized to whatever `mkfs.${fsType}` exist during operations
+- root filesystem `fsType` can be customized to whatever `mkfs.${fsType}` exists during operations
 - root filesystem label can be customized, defaults to `nix-store` if it's a Nix store image, otherwise `nixpkgs/nixos`
 - arbitrary code can be executed after disk image was produced with `postVM`
 - 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
···
 
 Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
 
-- bootloader installation have timestamps
-- SQLite Nix store database contain registration times
+- bootloader installation has timestamps
+- SQLite Nix store database contains registration times
 - `/etc/shadow` is in a non-deterministic order
 
 A `deterministic` flag is available for best efforts determinism.

doc/build-helpers/testers.chapter.md

···
 
 This is a wrapper around `pkgs.runCommandWith`, which
 - produces a fixed-output derivation, enabling the command(s) to access the network ;
-- salts the derivation's name based on its inputs, ensuring the command is re-run whenever the inputs changes.
+- salts the derivation's name based on its inputs, ensuring the command is re-run whenever the inputs change.
 
 It accepts the following attributes:
 - the derivation's `name` ;

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

···
 [allowSubstitutes]: https://nix.dev/manual/nix/latest/language/advanced-attributes.html#adv-attr-allowSubstitutes
 [preferLocalBuild]: https://nix.dev/manual/nix/latest/language/advanced-attributes.html#adv-attr-preferLocalBuild
 [substituter]: https://nix.dev/manual/nix/latest/glossary#gloss-substituter
-[substitutes]: https://nix.dev/manual/nix/2.23/glossary#gloss-substitute
+[substitutes]: https://nix.dev/manual/nix/latest/glossary#gloss-substitute
 
 ::: {.example #ex-runcommandwith}
 # Invocation of `runCommandWith`

doc/functions/prefer-remote-fetch.section.md

···
 # prefer-remote-fetch overlay {#sec-prefer-remote-fetch}
 
-`prefer-remote-fetch` is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
+`prefer-remote-fetch` is an overlay that downloads sources on a remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster, directly from the source. To use it, put the following snippet as a new overlay:
 
 ```nix
 self: super: (super.prefer-remote-fetch self super)
 ```
 
-A full configuration example for that sets the overlay up for your own account, could look like this
+A full configuration example that sets the overlay up for your own account could look like this
 
 ```ShellSession
 $ mkdir ~/.config/nixpkgs/overlays/

doc/hooks/autopatchelf.section.md

···
 
 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`.
 
-You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime.
+You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to the rpath of all executables. This is useful for programs that use `dlopen` to load libraries at runtime.
 
 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.
 

doc/hooks/bmake.section.md

···
 # bmake {#bmake-hook}
 
 [bmake](https://www.crufty.net/help/sjg/bmake.html) is the portable variant of
-NetBSD make utility.
+NetBSD `make` utility.
 
 In Nixpkgs, `bmake` comes with a hook that overrides the default build, check,
 install and dist phases.

doc/hooks/breakpoint.section.md

···
 # breakpointHook {#breakpointhook}
 
-This hook makes a build pause instead of stopping when a failure occurs. It prevents Nix from cleaning up the build environment immediately and allows the user to attach to the build environment. Upon a build error, it will print instructions that can be used to enter the environment for debugging. breakpointHook is only available on Linux. To use it, add `breakpointHook` to `nativeBuildInputs` in the package to be inspected.
+This hook makes a build pause instead of stopping when a failure occurs. It prevents Nix from cleaning up the build environment immediately and allows the user to attach to the build environment. Upon a build error, it will print instructions that can be used to enter the environment for debugging. The `breakpointHook` is only available on Linux. To use it, add `breakpointHook` to `nativeBuildInputs` in the package to be inspected.
 
 ```nix
 { nativeBuildInputs = [ breakpointHook ]; }

doc/hooks/cernlib.section.md

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

doc/hooks/cmake.section.md

···
 Directory where CMake will put intermediate files.
 
 Setting this can be useful for debugging multiple CMake builds while in the same source directory, for example, when building for different platforms.
-Different values for each build will prevent build artefacts from interefering with each other.
+Different values for each build will prevent build artifacts from interfering with each other.
 This setting has no tangible effect when running the build in a sandboxed derivation.
 
 The default value is `build`.

doc/hooks/haredo.section.md

···
 
 This hook uses [the `haredo` command runner](https://sr.ht/~autumnull/haredo/) to build, check, and install the package. It overrides `buildPhase`, `checkPhase`, and `installPhase` by default.
 
-The hook builds its targets in parallel if [`config.enableParallelBuilding`](#var-stdenv-enableParallelBuilding) is set to `true`.
+The hook builds its targets in parallel if [`enableParallelBuilding`](#var-stdenv-enableParallelBuilding) is set to `true`.
 
 ## `buildPhase` {#haredo-hook-buildPhase}
 

doc/hooks/installShellFiles.section.md

···
 {
   nativeBuildInputs = [ installShellFiles ];
 
-  # Sometimes the file has an undersirable name. It should be renamed before
+  # Sometimes the file has an undesirable name. It should be renamed before
   # being installed via installBin
   postInstall = ''
     mv a.out delmar
···
 {
   nativeBuildInputs = [ installShellFiles ];
 
-  # Sometimes the manpage file has an undersirable name; e.g. it conflicts with
+  # Sometimes the manpage file has an undesirable name; e.g., it conflicts with
   # another software with an equal name. It should be renamed before being
   # installed via installManPage
   postInstall = ''

doc/hooks/just.section.md

···
 
 ## `checkPhase` {#just-hook-checkPhase}
 
-This phase attempts to invoke the `just test` recipe, if it is available. This can be overrided by setting `checkTarget` to a string.
+This phase attempts to invoke the `just test` recipe, if it is available. This can be overridden by setting `checkTarget` to a string.
 
 []{#just-hook-dontUseJustCheck} This behavior can be disabled by setting `dontUseJustCheck` to `true`.
 

doc/hooks/meson.section.md

···
 Directory where Meson will put intermediate files.
 
 Setting this can be useful for debugging multiple Meson builds while in the same source directory, for example, when building for different platforms.
-Different values for each build will prevent build artefacts from interefering with each other.
+Different values for each build will prevent build artifacts from interfering with each other.
 This setting has no tangible effect when running the build in a sandboxed derivation.
 
 The default value is `build`.
···
 #### `mesonWrapMode` {#meson-wrap-mode}
 
 Which value is passed as
-[`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options)
-to. In Nixpkgs the default value is `nodownload`, so that no subproject will be
+[`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options).
+In Nixpkgs, the default value is `nodownload`, so that no subproject will be
 downloaded (since network access is already disabled during deployment in
 Nixpkgs).
 
···
 
 Which value is passed as
 [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to
-`meson setup` during configure phase. In Nixpkgs the default value is `plain`.
+`meson setup` during configure phase. In Nixpkgs, the default value is `plain`.
 
 #### `mesonAutoFeatures` {#meson-auto-features}
 
 Which value is passed as
 [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options)
-to `meson setup` during configure phase. In Nixpkgs the default value is
+to `meson setup` during configure phase. In Nixpkgs, the default value is
 `enabled`, meaning that every feature declared as "auto" by the meson scripts
 will be enabled.
 
···
 [`--tags`](https://mesonbuild.com/Installing.html#installation-tags) during
 install phase.
 
-Note: `mesonInstallTags` should be a list of strings, that will be converted to
+Note: `mesonInstallTags` should be a list of strings that will be converted to
 a comma-separated string that is recognized to `--tags`.
 Example: `mesonInstallTags = [ "emulator" "assembler" ];` will be converted to
 `--tags emulator,assembler`.

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

···
 
 This hook can be used to setup a check phase that
 requires running a MPI application. It detects the
-used present MPI implementation type and exports
-the neceesary environment variables to use
+present MPI implementation type and exports
+the necessary environment variables to use
 `mpirun` and `mpiexec` in a Nix sandbox.
 
 

doc/hooks/ninja.section.md

···
 # 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.
+Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.
 
 Note that if the [Meson setup hook](#meson) is also active, Ninja's install and check phases will be disabled in favor of Meson's.

doc/hooks/patch-rc-path-hooks.section.md

···
  - `patchRcPathBash`: [Bash](https://www.gnu.org/software/bash/), [ksh](http://www.kornshell.org/), [zsh](https://www.zsh.org/) and other shells supporting the Bash-like parameter expansions.
  - `patchRcPathCsh`: Csh scripts, such as those targeting [tcsh](https://www.tcsh.org/).
  - `patchRcPathFish`: [Fish](https://fishshell.com/) scripts.
- - `patchRcPathPosix`: POSIX-conformant shells supporting the limited parameter expansions specified by the POSIX standard. Current implementation uses the parameter expansion `${foo-}` only.
+ - `patchRcPathPosix`: POSIX-conformant shells supporting the limited parameter expansions specified by the POSIX standard. The current implementation uses the parameter expansion `${foo-}` only.
 
 For each supported shell, it modifies the script with a `PATH` prefix that is later removed when the script ends.
 It allows nested patching, which guarantees that a patched script may source another patched script.

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

···
 
 ## Hooks {#sec-postgresqlTestHook-hooks}
 
-A number of additional hooks are ran in postgresqlTestHook
+A number of additional hooks are run in postgresqlTestHook
 
- - `postgresqlTestSetupPost`: ran after postgresql has been set up.
+ - `postgresqlTestSetupPost`: run after postgresql has been set up.
 
 ## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp}
 

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

···
 
 Bash-only variables:
 
- - `redisTestPort`: Port to use by Redis. Defaults to `6379`
+- `redisTestPort`: Port to use by Redis. Defaults to `6379`
 
 Example usage:
 

doc/hooks/udevCheckHook.section.md

···
 
 The `udevCheckHook` derivation adds `udevCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase),
 which finds all udev rules in all outputs and verifies them using `udevadm verify --resolve-names=never --no-style`.
-It should be used in any package that has udev rules outputs to ensure the rules are and stay valid.
+It should be used in any package that has udev rules outputs to ensure the rules are and remain valid.
 
 The hook runs in `installCheckPhase`, requiring `doInstallCheck` is enabled for the hook to take effect:
 ```nix

doc/hooks/validatePkgConfig.section.md

···
 # 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.
+The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catch some common errors in pkg-config files, such as undefined variables.

doc/hooks/waf.section.md

···
 
 #### `wafFlags` {#waf-flags}
 
-Controls the flags passed to waf tool during build and install phases. For settings specific to build or install phases, use `wafBuildFlags` or `wafInstallFlags` respectively.
+Controls the flags passed to waf tool during build and install phases. For settings specific to build or install phases, use `wafBuildFlags` or `wafInstallFlags`, respectively.
 
 #### `dontUseWafConfigure` {#dont-use-waf-configure}
 

doc/interoperability/cyclonedx.md

···
 The `nix:fod:method` property is required and must be accompanied by a `nix:store_path` property within the same property list.
 All other properties in this namespace are method-specific.
 To reproduce the build of a component the `nix:fod:method` value is resolved to an [appropriate function](#chap-pkgs-fetchers) within Nixpkgs whose arguments intersect with the given properties.
-When generating `nix:fod` properties the method selected should be a stable function with a minimal number arguments.
+When generating `nix:fod` properties the method selected should be a stable function with a minimal number of arguments.
 For example, the `fetchFromGitHub` is commonly used within Nixpkgs but should be reduced to a call to the function by which it is implemented, `fetchzip`.
 
 | Property         | Description |
 |------------------|-------------|
-| `nix:fod:method` | Nixpkg function that produces this FOD. Required. Examples: `"fetchzip"`, `"fetchgit"` |
+| `nix:fod:method` | Nixpkgs function that produces this FOD. Required. Examples: `"fetchzip"`, `"fetchgit"` |
 | `nix:fod:name`   | Derivation name, present when method is `"fetchzip"` |
 | `nix:fod:ref`    | [Git ref](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrefaref), present when method is `"fetchgit"` |
 | `nix:fod:rev`    | [Git rev](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrevisionarevision), present when method is `"fetchgit"` |

doc/languages-frameworks/agda.section.md

···
 1. Always work together.
 2. Are as up-to-date as possible.
 
-While the Haskell ecosystem is huge, and Stackage is highly automatised,
+While the Haskell ecosystem is huge, and Stackage is highly automated,
 the Agda package set is small and can (still) be maintained by hand.
 
 ### Adding Agda packages to Nixpkgs {#adding-agda-packages-to-nixpkgs}
···
 could use a similar set as in your `default.nix` from [Writing Agda Packages](#writing-agda-packages) with
 `agdaPackages.mkDerivation` replaced with `mkDerivation`.
 
-When writing an Agda package it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://github.com/agda/agda/issues/4613).
+Here is an example skeleton derivation for iowa-stdlib:
+
+```nix
+mkDerivation {
+  version = "1.5.0";
+  pname = "iowa-stdlib";
+
+  src = <...>;
+
+  libraryFile = "";
+  libraryName = "IAL-1.3";
+
+  buildPhase = ''
+    runHook preBuild
+
+    patchShebangs find-deps.sh
+    make
+
+    runHook postBuild
+  '';
+}
+```
+
+This library has a file called `.agda-lib`, and so we give an empty string to `libraryFile` as nothing precedes `.agda-lib` in the filename. This file contains `name: IAL-1.3`, and so we let `libraryName =  "IAL-1.3"`. This library does not use an `Everything.agda` file and instead has a Makefile, so there is no need to set `everythingFile` and we set a custom `buildPhase`.
+
+When writing an Agda package, it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://githcub.com/agda/agda/issues/4613).
 
 In the pull request adding this library,
 you can test whether it builds correctly by writing in a comment:

doc/languages-frameworks/android.section.md

···
 { buildInputs = [ androidStudioPackages.stable.full ]; }
 ```
 
-Alternatively, you can pass composeAndroidPackages to the `withSdk` passthru:
+Alternatively, you can pass composeAndroidPackages to the `withSdk` passthrough:
 
 ```nix
 {
···
 `local.properties` file with `sdk.dir` set to $ANDROID_HOME if one does not already
 exist. If you are using the NDK as well, you may have to add `ndk.dir` to this file.
 
-An example shell.nix that does all this for you is provided in examples/shell.nix.
+An example `shell.nix` that does all this for you is provided in `examples/shell.nix`.
 This shell.nix includes a shell hook that overwrites local.properties with the correct
 sdk.dir and ndk.dir values. This will ensure that the SDK and NDK directories will
 both be correct when you run Android Studio inside nix-shell.

doc/languages-frameworks/astal.section.md

···
 
 ## Bundling {#astal-bundling}
 
-Bundling Astal application is done using `ags` tool, you can use it like this:
+Bundling an Astal application is done using the `ags` tool. You can use it like this:
 
 ```nix
 ags.bundle {
···
   entry = "app.ts";
 
   dependencies = [
-    # list here astal modules, that your package depends on
+    # list here astal modules that your package depends on
     # `astal3`, `astal4` and `astal.io` are automatically included
     astal.apps
     astal.battery

doc/languages-frameworks/beam.section.md

···
 
 ### Elixir {#elixir}
 
-nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/elixir/compatibility-and-deprecations.html) and keeps the last 5 released versions of Elixir available.
+Nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/elixir/compatibility-and-deprecations.html) and keeps the last 5 released versions of Elixir available.
 
 ## Structure {#beam-structure}
 
···
 
 #### mixRelease - Elixir Phoenix example {#mix-release-elixir-phoenix-example}
 
-there are 3 steps, frontend dependencies (javascript), backend dependencies (elixir) and the final derivation that puts both of those together
+there are 3 steps: frontend dependencies (javascript), backend dependencies (elixir), and the final derivation that puts both of those together
 
 ##### mixRelease - Frontend dependencies (javascript) {#mix-release-javascript-deps}
 
-For phoenix projects, inside of nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
+For phoenix projects, inside of Nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
 
 ##### mixRelease - backend dependencies (mix) {#mix-release-mix-deps}
 
···
 
 ###### mix2nix {#mix2nix}
 
-`mix2nix` is a cli tool available in nixpkgs. it will generate a nix expression from a mix.lock file. It is quite standard in the 2nix tool series.
+`mix2nix` is a cli tool available in Nixpkgs. It will generate a Nix expression from a `mix.lock` file. It is quite standard in the 2nix tool series.
 
 Note that currently mix2nix can't handle git dependencies inside the mix.lock file. If you have git dependencies, you can either add them manually (see [example](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/pleroma/default.nix#L20)) or use the FOD method.
 
···
 
 ##### mixRelease - example {#mix-release-example}
 
-Here is how your `default.nix` file would look for a phoenix project.
+Here is how your `default.nix` file would look for a Phoenix project.
 
 ```nix
 with import <nixpkgs> { };
···
 
 ### Creating a Shell {#creating-a-shell}
 
-Usually, we need to create a `shell.nix` file and do our development inside of the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example with Elixir:
+Usually, we need to create a `shell.nix` file and do our development inside the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example, with Elixir:
 
 ```nix
 {
···
 
 ### Using an overlay {#beam-using-overlays}
 
-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:
+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}
 
···
 - create the db `createdb db`
 - start the postgres instance `pg_ctl -l "$PGDATA/server.log" start`
 - add the `/db` folder to your `.gitignore`
-- you can start your phoenix server and get a shell with `iex -S mix phx.server`
+- you can start your Phoenix server and get a shell with `iex -S mix phx.server`

doc/languages-frameworks/bower.section.md

···
 
 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.
+   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.
 

doc/languages-frameworks/chicken.section.md

···
 ## Override Scope {#sec-chicken-override-scope}
 
 The chicken package and its eggs, respectively, reside in a scope. This means,
-the scope can be overridden to effect other packages in it.
+the scope can be overridden to affect other packages in it.
 
 This example shows how to use a local copy of `srfi-180` and have it affect
 all the other eggs:
···
 let
   myChickenPackages = pkgs.chickenPackages.overrideScope (
     self: super: {
-      # The chicken package itself can be overridden to effect the whole ecosystem.
+      # The chicken package itself can be overridden to affect the whole ecosystem.
       # chicken = super.chicken.overrideAttrs {
       #   src = ...
       # };

doc/languages-frameworks/coq.section.md

···
 
 ## Coq derivation: `coq` {#coq-derivation-coq}
 
-The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following
+The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following:
 
 * `version` (optional, defaults to the latest version of Coq selected for nixpkgs, see `pkgs/top-level/coq-packages` to witness this choice), which follows the conventions explained in the `coqPackages` section below,
 * `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).

doc/languages-frameworks/cuda.section.md

···
 
 #### Using docker-compose {#cuda-using-docker-compose}
 
-It's possible to expose GPU's to a `docker-compose` environment as well. With a `docker-compose.yaml` file like follows:
+It's possible to expose GPUs to a `docker-compose` environment as well. With a `docker-compose.yaml` file like follows:
 
 ```yaml
 services:

doc/languages-frameworks/dart.section.md

···
 
 If the package has Git package dependencies, the hashes must be provided in the `gitHashes` set. If a hash is missing, an error message prompting you to add it will be shown.
 
-The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
+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`.
+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
 {
···
 #### Entering the shell {#ssec-dart-flutter-nix-shell-enter}
 
 By default, dependencies for only the `targetFlutterPlatform` are available in the
-build environment. This is useful for keeping closures small, but be problematic
+build environment. This is useful for keeping closures small but can be problematic
 during development. It's common, for example, to build Web apps for Linux during
 development to take advantage of native features such as stateful hot reload.
 

doc/languages-frameworks/dhall.section.md

···
   sha256:26b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
 ```
 
-… and if the import is cached then the interpreter will load the import from
-cache instead of fetching the URL.
+… and if the import is cached, then the interpreter will load the import from
+the cache instead of fetching the URL.
 
 Nixpkgs uses this trick to add all of a Dhall expression's dependencies into the
 cache so that the Dhall interpreter never needs to resolve any remote URLs.  In
···
   ```
 
 The `source.dhall` file is only present for packages that specify
-`source = true;`.  By default, Dhall packages omit the `source.dhall` in order
-to conserve disk space when they are used exclusively as dependencies.  For
+`source = true;`. By default, Dhall packages omit the `source.dhall` in order
+to conserve disk space when they are used exclusively as dependencies. For
 example, if we build the Prelude package it will only contain the binary
 encoding of the expression:
 
···
 ```
 
 Typically, you only specify `source = true;` for the top-level Dhall expression
-of interest (such as our example `true.nix` Dhall package).  However, if you
+of interest (such as our example `true.nix` Dhall package). However, if you
 wish to specify `source = true` for all Dhall packages, then you can amend the
 Dhall overlay like this:
 
···
 * `src`: The directory containing Dhall code that you want to turn into a Dhall
   package
 
-* `file`: The top-level file (`package.dhall` by default) that is the entrypoint
+* `file`: The top-level file (`package.dhall` by default) that is the entry point
   to the rest of the package
 
 * `document`: Set to `true` to generate documentation for the package
···
   directory other than the root of the repository)
 
 * `file`: The top-level file (`${directory}/package.dhall` by default) that is
-  the entrypoint to the rest of the package
+  the entry point to the rest of the package
 
 * `document`: Set to `true` to generate documentation for the package
 
···
 ```
 
 … because the default Prelude selected by Nixpkgs revision
-`94b2848559b12a8ed1fe433084686b2a81123c99is` is version 20.1.0, which doesn't
-have the same integrity check as version 19.0.0.  This means that version
-19.0.0 is not cached and the interpreter is not allowed to fall back to
+`94b2848559b12a8ed1fe433084686b2a81123c99` is version 20.1.0, which doesn't
+have the same integrity check as version 19.0.0. This means that version
+19.0.0 is not cached, and the interpreter is not allowed to fall back to
 importing the URL.
 
 However, we can override the default Prelude version by using `dhall-to-nixpkgs`

doc/languages-frameworks/dlang.section.md

···
 Also note that running `dub test` is disabled by default. You can enable it by setting `doCheck = true`.
 
 ## Lockfiles {#dub-lockfiles}
-Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash based.
+Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash-based.
 
 A lockfile can be generated using the `dub-to-nix` helper package.
-* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`
-* Then navigate to the root of the source of the program you want to package
-* Finally, run `dub-to-nix` and it will print the lockfile to stdout. You could pipe stdout into a text file or just copy the output manually into a file.
+* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`.
+* Then navigate to the root of the source of the program you want to package.
+* Finally, run `dub-to-nix`, and it will print the lockfile to stdout. You can pipe stdout into a text file or just copy the output manually into a file.
 
 ## `buildDubPackage` parameters {#builddubpackage-parameters}
 

doc/languages-frameworks/dotnet.section.md

···
 }
 ```
 
-This will produce a dotnet installation that has the dotnet 8.0 9.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 8.0 9.0 sdk. The first sdk listed will have its cli utility present in the resulting environment. Example info output:
 
 ```ShellSession
 $ dotnet --info
···
 * `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 .NET.
 * `useAppHost` will enable creation of a binary executable that runs the .NET application using the specified root. More info in [Microsoft docs](https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent). Enabled by default.
-* `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the users' .NET runtime.
+* `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the user's .NET runtime.
 * `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used. You can also set this to the result of `dotnetSdkPackages.combinePackages`, if the project uses multiple SDKs to build.
 * `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
 * `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this. Note that if set, only tests from this project are executed.
···
   Restored /home/ggg/git-credential-manager/src/shared/Git-Credential-Manager/Git-Credential-Manager.csproj (in 1.21 sec).
 ```
 
-Next, use `nuget-to-json` tool provided in nixpkgs to generate a lockfile to `deps.json` from
+Next, use the `nuget-to-json` tool provided in Nixpkgs to generate a lockfile to `deps.json` from
 the packages inside the `out` directory.
 
 ```bash
 $ nuget-to-json out > deps.json
 ```
-Which `nuget-to-json` will generate an output similar to below
+The `nuget-to-json` tool will generate an output similar to the one below
 ```json
 [
   {

doc/languages-frameworks/factor.section.md

···
 `work` is routed to `/var/lib/factor` and is not shipped nor referenced in the nix store, see the section on [scaffolding](#ssec-factor-scaffolding).
 You should usually use `extra`, but you can use the other roots to overwrite built-in vocabularies.
 Be aware that vocabularies in `core` are part of the Factor image which the development environment is run from.
-This means the code in those vocabularies is not loaded from the sources, such that you need to call `refresh-all` to re-compile and load the changed definitions.
+This means the code in those vocabularies is not loaded from the sources, such that you need to call `refresh-all` to recompile and load the changed definitions.
 In these instances, it is advised to override the `factor-unwrapped` package directly, which compiles and packages the core Factor libraries into the default Factor
 image.
 
···
 ```
 
 The vocabulary goes to `lib/factor/extra`, extra files, like licenses etc. would go to `share/` as usual and could be added to the output via a `postInstall` phase.
-In case the vocabulary binds to a shared library or calls a binary that needs to be present in the runtime environment of its users, add `extraPaths` and `extraLibs` attributes respectively.
+In case the vocabulary binds to a shared library or calls a binary that needs to be present in the runtime environment of its users, add `extraPaths` and `extraLibs` attributes, respectively.
 They are then picked up by the `buildFactorApplication` function and added as runtime dependencies.
 
 ## Building Applications {#ssec-factor-applications}
···
 })
 ```
 
-The use of the `src.name` and`sourceRoot` attributes conveniently establish the necessary `painter` vocabulary directory that is needed for the deployment to work.
+The use of the `src.name` and `sourceRoot` attributes conveniently establish the necessary `painter` vocabulary directory that is needed for the deployment to work.
 
 It requires the packager to specify the full set of binaries to be made available at runtime.
 This enables the standard pattern for application packages to specify all runtime dependencies explicitly without the Factor runtime interfering.

doc/languages-frameworks/go.section.md

···
 You can read more about [vendoring in the Go documentation](https://go.dev/ref/mod#vendoring).
 
 To obtain the hash, set `vendorHash = lib.fakeHash;` and run the build. ([more details here](#sec-source-hashes)).
-Another way is to use use `nix-prefetch` to obtain the hash. The following command gets the value of `vendorHash` for package `pet`:
+Another way is to use `nix-prefetch` to obtain the hash. The following command gets the value of `vendorHash` for package `pet`:
 
 
 ```sh
···
 ### `modPostBuild` {#var-go-modPostBuild}
 
 Shell commands to run after the build of the goModules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash`.
-Note that if you change this attribute, you need to update `vendorHash` attribute.
+Note that if you change this attribute, you need to update the `vendorHash` attribute.
 
 
 ### `modRoot` {#var-go-modRoot}
···
 
 Beside `buildGoModule`, there are also versioned builders available that pin a specific Go version, like `buildGo124Module` for Go 1.24.
 Similar, versioned toolchains are available, like `go_1_24` for Go 1.24.
-Both builder and toolchain of a certain version will be removed as soon as the Go version reaches end of life.
+Both builder and toolchain of a certain version will be removed as soon as the Go version reaches its end of life.
 
 As toolchain updates in nixpkgs cause mass rebuilds and must go through the staging cycle, it can take a while until a new Go minor version is available to consumers of nixpkgs.
 If you want quicker access to the latest minor, use `go_latest` toolchain and `buildGoLatestModule` builder.
···
 
 ### `env.CGO_ENABLED` {#var-go-CGO_ENABLED}
 
-When set to `0`, the [cgo](https://pkg.go.dev/cmd/cgo) command is disabled. As consequence, the build
+When set to `0`, the [cgo](https://pkg.go.dev/cmd/cgo) command is disabled. As a consequence, the build
 program can't link against C libraries anymore, and the resulting binary is statically linked.
 
 When building with CGO enabled, Go will likely link some packages from the Go standard library against C libraries,

doc/languages-frameworks/gradle.section.md

···
 
 ## Building a Gradle package {#building-a-gradle-package}
 
-Here's how a typical derivation will look like:
+Here's how a typical derivation will look:
 
 ```nix
 stdenv.mkDerivation (finalAttrs: {
···
 expression (for example, if your package isn't located in nixpkgs, or if
 you want to override some of its attributes), you will usually have to
 pass `pkg` instead of `pname` to `gradle.fetchDeps`. There are two ways
-of doing it.
+of doing so.
 
 The first is to add the derivation arguments required for getting the
 package. Using the pdftk example above:

doc/languages-frameworks/haskell.section.md

···
 * `ghc` is the default version of GHC
 * Language specific tools: `cabal-install`, `stack`, `hpack`, …
 
-Many “normal” user facing packages written in Haskell, like `niv` or `cachix`,
+Many “normal” user-facing packages written in Haskell, like `niv` or `cachix`,
 are also exposed at the top level, and there is nothing Haskell specific to
 installing and using them.
 
···
 Each of those compiler versions has a corresponding attribute set `packages` built with
 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.8 is `haskell.packages.ghc948`. In fact `haskellPackages` (at the time of writing) is just an alias
+9.4.8 is `haskell.packages.ghc948`. In fact, `haskellPackages` (at the time of writing) is just an alias
 for `haskell.packages.ghc984`:
 
 Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
···
 
 Normally when you build Haskell packages with `cabal-install`, `cabal-install`
 does dependency resolution. It will look at all Haskell package versions known
-on Hackage and tries to pick for every (transitive) dependency of your build
+on Hackage and try to pick for every (transitive) dependency of your build
 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 take as input packages with names off the desired dependencies
+It will take as input packages with names of 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).
 
···
 ### Limitations {#haskell-limitations}
 
 Our main objective with `haskellPackages` is to package Haskell software in
-nixpkgs. This entails some limitations, partially due to self-imposed
-restrictions of nixpkgs, partially in the name of maintainability:
+Nixpkgs. This entails some limitations, partially due to self-imposed
+restrictions of Nixpkgs, partially in the name of maintainability:
 
 * Only the packages built with the default compiler see extensive testing of the
   whole package set. For other GHC versions only a few essential packages are
···
 
 ## `haskellPackages.mkDerivation` {#haskell-mkderivation}
 
-Every haskell package set has its own haskell-aware `mkDerivation` which is used
+Every Haskell package set has its own Haskell-aware `mkDerivation` which is used
 to build its packages. Generally you won't have to interact with this builder
 since [cabal2nix](#haskell-cabal2nix) can generate packages
 using it for an arbitrary cabal package definition. Still it is useful to know
···
 [override](#haskell-overriding-haskell-packages) a generated Nix expression.
 
 `haskellPackages.mkDerivation` is a wrapper around `stdenv.mkDerivation` which
-re-defines the default phases to be haskell aware and handles dependency
+re-defines the default phases to be Haskell-aware and handles dependency
 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.
···
 
 ## Development environments {#haskell-development-environments}
 
-In addition to building and installing Haskell software, nixpkgs can also
+In addition to building and installing Haskell software, Nixpkgs can also
 provide development environments for Haskell projects. This has the obvious
 advantage that you benefit from `cache.nixos.org` and no longer need to compile
 all project dependencies yourself. While it is often very useful, this is not
···
 
 ### haskell-language-server {#haskell-language-server}
 
-To use HLS in short: Install `pkgs.haskell-language-server` e.g. in
+To use HLS in short: Install `pkgs.haskell-language-server`, e.g. in
 `nativeBuildInputs` in `shellFor` and use the `haskell-language-server-wrapper`
 command to run it. See the [HLS user guide] on how to configure your text
 editor to use HLS and how to test your setup.
···
 
 Be careful when installing HLS globally and using a pinned nixpkgs for a
 Haskell project in a `nix-shell`. If the nixpkgs versions deviate to much
-(e.g., use different `glibc` versions) the `haskell-language-server-?.?.?`
+(e.g., use different `glibc` versions) the `haskell-language-server-?.?.?`
 executable will try to detect these situations and refuse to start. It is
 recommended to obtain HLS via `nix-shell` from the nixpkgs version pinned in
 there instead.

doc/languages-frameworks/hy.section.md

···
 
 ### Installation with packages {#installation-with-packages}
 
-Creating `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. Attribute `hy` provides function `withPackages` that creates custom `hy` derivation with specified packages.
+Creating a `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. The attribute `hy` provides the function `withPackages` that creates a custom `hy` derivation with specified packages.
 
-For example if you want to create shell with `matplotlib` and `numpy`, you can do it like so:
+For example, if you want to create a shell with `matplotlib` and `numpy`, you can do it like so:
 
 ```ShellSession
 $ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])"

doc/languages-frameworks/idris2.section.md

···
 lspLibPkg.library { withSource = true; }
 ```
 
-The above results in a derivation with the installed library results (with sourcecode).
+The above results in a derivation with the installed library results (with source code).
 
 A slightly more involved example of a fully packaged executable would be the [`idris2-lsp`](https://github.com/idris-community/idris2-lsp) which is an Idris2 language server that uses the `LSP-lib` found above.
 ```nix

doc/languages-frameworks/ios.section.md

···
 It also possible 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
+* `target` specifies which `xcodebuild` target to build. By default it takes the target
   that has the same name as the app.
 * The `configuration` parameter can be overridden if desired. By default, it
   will do a debug build for the simulator and a release build for real devices.
···
 
 * `certificateFile` refers to a P12 certificate file.
 * `certificatePassword` specifies the password of the P12 certificate.
-* `provisioningProfile` refers to the provision profile needed to sign the app
+* `provisioningProfile` refers to the provisioning profile needed to sign the app
 * `signMethod` should refer to `ad-hoc` for signing the app with an ad-hoc
   certificate, `enterprise` for enterprise certificates and `app-store` for App
   store certificates.

doc/languages-frameworks/java.section.md

···
 Using it, however, does not always guarantee reproducibility.
 
 JAR files that are intended to be used by other packages should be
-installed in `$out/share/java`. JDKs have a stdenv setup hook that add
+installed in `$out/share/java`. JDKs have a `stdenv` setup hook that adds
 any JARs in the `share/java` directories of the build inputs to the
 `CLASSPATH` environment variable. For instance, if the package `libfoo`
 installs a JAR named `foo.jar` in its `share/java` directory, and
···
 Java distributions typically no longer ship with a general-purpose JRE:
 instead, they allow generating a JRE with only the modules required for
 your application(s). Because we can't predict what modules will be
-needed on a general-purpose system, the default jre package is the full
+needed on a general-purpose system, the default `jre` package is the full
 JDK. When building a minimal system/image, you can override the
 `modules` parameter on `jre_minimal` to build a JRE with only the
 modules relevant for you:

doc/languages-frameworks/javascript.section.md

···
 
 ## Introduction {#javascript-introduction}
 
-This contains instructions on how to package javascript applications.
+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.
+Finally, some tool-specific instructions will be given.
 
 ## Getting unstuck / finding code examples {#javascript-finding-examples}
 
-If you find you are lacking inspiration for packaging javascript applications, the links below might prove useful.
+If you find you are lacking inspiration for packaging 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}
···
 Guidelines of package managers, recommend to commit those lock files to the repos.
 If a particular lock file is present, it is a strong indication of which package manager is used upstream.
 
-It's better to try to use a Nix tool that understand the lock file.
-Using a different tool might give you hard to understand error because different packages have been installed.
+It's better to try to use a Nix tool that understands the lock file.
+Using a different tool might give you a hard-to-understand error because different packages have been installed.
 An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).
 Upstream use npm, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
 
-Using a different tool forces to commit a lock file to the repository.
-Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
+Using a different tool forces you to commit a lock file to the repository.
+These files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
 
 Exceptions to this rule are:
 
-- When you encounter one of the bugs from a Nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general `yarn2nix` has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed.
+- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to re-create a lock file and commit it to Nixpkgs. In general `yarn2nix` has fewer known problems, and so a simple search in Nixpkgs will reveal many `yarn.lock` files committed.
 - Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
 - The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
 
···
 
 Exceptions to this rule are:
 
-- Sometimes the upstream repo assumes some dependencies be installed globally. In that case you can add them manually to the upstream package.json (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools. (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
+- Sometimes the upstream repo assumes some dependencies should be installed globally. In that case, you can add them manually to the upstream `package.json` (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
 - Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version by removing the `^`.
 - Sometimes the script defined in the package.json does not work as is. Some scripts for example use CLI tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into,
 
···
 
 The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [npm packages](https://npmjs.com/) that can be installed with the Nix package manager.
 
-As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities.
+As a rule of thumb, the package set should only provide _end-user_ software packages, such as command-line utilities.
 Libraries should only be added to the package set if there is a non-npm package that requires it.
 
 When it is desired to use npm libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
···
 }
 ```
 
-### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
+### Adding and updating JavaScript packages in Nixpkgs {#javascript-adding-or-updating-packages}
 
-To add a package from npm to nixpkgs:
+To add a package from npm to Nixpkgs:
 
 1. Modify [pkgs/development/node-packages/node-packages.json](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/node-packages.json) to add, update or remove package entries to have it included in `nodePackages` and `nodePackages_latest`.
 2. Run the script:
···
 
 For more information about the generation process, consult the [README.md](https://github.com/svanderburg/node2nix) file of the `node2nix` tool.
 
-To update npm packages in nixpkgs, run the same `generate.sh` script:
+To update npm packages in Nixpkgs, run the same `generate.sh` script:
 
 ```sh
 ./pkgs/development/node-packages/generate.sh
···
 git config --global url."https://github.com/".insteadOf git://github.com/
 ```
 
-## Tool specific instructions {#javascript-tool-specific}
+## Tool-specific instructions {#javascript-tool-specific}
 
 ### buildNpmPackage {#javascript-buildNpmPackage}
 
···
 will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
 
 :::{.note}
-Commands like `npm install` & `npm add` that writes packages & executables needs to be used with `--package-lock-only`.
+Commands like `npm install` & `npm add` that write packages & executables need to be used with `--package-lock-only`.
 
 This means `npm` installs dependencies by writing into `package-lock.json` without modifying the `node_modules` folder. Installation happens through reloading the devShell.
 This might be best practice since it gives the `nix shell` virtually exclusive ownership over your `node_modules` folder.
···
 
 Pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8` and `pnpm_9`, which support different sets of lock file versions.
 
-When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The functions `pnpm_8.fetchDeps` and `pnpm_9.fetchDeps` can create this pnpm store derivation. In conjunction, the setup hooks `pnpm_8.configHook` and `pnpm_9.configHook` will prepare the build environment to install the prefetched dependencies store. Here is an example for a package that contains a `package.json` and a `pnpm-lock.yaml` files using the above `pnpm_` attributes:
+When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The functions `pnpm_8.fetchDeps` and `pnpm_9.fetchDeps` can create this pnpm store derivation. In conjunction, the setup hooks `pnpm_8.configHook` and `pnpm_9.configHook` will prepare the build environment to install the pre-fetched dependencies store. Here is an example for a package that contains `package.json` and a `pnpm-lock.yaml` files using the above `pnpm_` attributes:
 
 ```nix
 {
···
 })
 ```
 
-NOTE: It is highly recommended to use a pinned version of pnpm (i.e. `pnpm_8` or `pnpm_9`), to increase future reproducibility. It might also be required to use an older version, if the package needs support for a certain lock file version.
+NOTE: It is highly recommended to use a pinned version of pnpm (i.e., `pnpm_8` or `pnpm_9`), to increase future reproducibility. It might also be required to use an older version if the package needs support for a certain lock file version.
 
-In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e. `inherit (finalAttrs) patches`.
+In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e., `inherit (finalAttrs) patches`.
 
 `pnpm.configHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array:
 
···
 The above would make `pnpm.fetchDeps` call only install dependencies for the `@astrojs/language-server` workspace package.
 Note that you do not need to set `sourceRoot` to make this work.
 
-Usually in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
+Usually, in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
 
 ```nix
 {
···
 
 ##### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
 
-`mkYarnPackage` will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React, WebPack, ...), you will need to explicitly override the build step with your instructions.
+`mkYarnPackage` will by default try to generate a binary. For packages only generating static assets (Svelte, Vue, React, Webpack, ...), you will need to explicitly override the build step with your instructions.
 
 It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
 
···
 { doDist = false; }
 ```
 
-The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
+The configure phase can sometimes fail because it makes many assumptions that may not always apply. One common override is:
 
 ```nix
 {
···
 ##### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
 
 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.
+If you have to build a derivation for an integrated web framework (Rails, Phoenix, etc.), this is probably the easiest way.
 
 #### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}
 
···
 Internally, this uses a patched version of Yarn to ensure git dependencies are re-packed and any attempted downloads fail immediately.
 
 ##### Patching upstream `package.json` or `yarn.lock` files {#javascript-yarnBerry-patching}
-In case patching the upstream `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e. `inherit (finalAttrs) patches`.
+In case patching the upstream `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e., `inherit (finalAttrs) patches`.
 
 ##### Missing hashes in the `yarn.lock` file {#javascript-yarnBerry-missing-hashes}
 Unfortunately, `yarn.lock` files do not include hashes for optional/platform-specific dependencies. This is [by design](https://github.com/yarnpkg/berry/issues/6759).
···
 ## Outside Nixpkgs {#javascript-outside-nixpkgs}
 
 There are some other tools available, which are written in the Nix language.
-These that can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
+These can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
 
 If you are packaging something outside Nixpkgs, consider the following:
 

doc/languages-frameworks/julia.section.md

···
   different CPUs.
 
   Why? Julia will detect the CPU microarchitecture of the build machine and include this information in the precompiled
-  `*.ji` files. Starting in 1.10 Julia became more strict about checking the CPU target compatibility, so it may reject
+  `*.ji` files. Starting in 1.10, Julia became more strict about checking the CPU target compatibility, so it may reject
   your precompiled files if they were compiled on a different machine.
   A good option to provide wide compatibility is to set this to `"generic"`, although this may reduce performance.
   You can also set a semicolon-separated list of multiple different targets. See the Julia documentation for details.

doc/languages-frameworks/lisp.section.md

···
 [runnable wrappers](#lisp-building-wrappers), with a pinned and pre-built
 [ASDF FASL](#lisp-loading-asdf) available in the `ASDF` environment variable,
 and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` configured to
-[find the desired systems on runtime](#lisp-loading-systems).
+[find the desired systems at runtime](#lisp-loading-systems).
 
 In addition, Lisps have the `withOverrides` function, which can be used to
 [substitute](#lisp-including-external-pkg-in-scope) any package in the scope of
···
 
 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
+load cleanly, because one will contain FASLs of itself but not the other, and
 vice versa.
 
 To package slashy systems, use `overrideLispAttrs`, like so:
···
 
 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.
+files. Unfortunately, in this case an ad-hoc solution becomes necessary.
 
 ## Building Wrappers {#lisp-building-wrappers}
 
···
 
 ### Loading ASDF {#lisp-loading-asdf}
 
-For best results, avoid calling `(require 'asdf)` When using the
+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

doc/languages-frameworks/maven.section.md

···
 # Maven {#maven}
 
-Maven is a well-known build tool for the Java ecosystem however it has some challenges when integrating into the Nix build system.
+Maven is a well-known build tool for the Java ecosystem; however, it has some challenges when integrating into the Nix build system.
 
 The following provides a list of common patterns with how to package a Maven project (or any JVM language that can export to Maven) as a Nix package.
 
···
 │       │   ├── classworlds-1.1.jar
 ```
 
-If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over-time your output hash will change since the resolved dependencies may change. Hence this method is less recommended then using `buildMaven`.
+If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over time, your output hash will change since the resolved dependencies may change. Hence this method is less recommended than using `buildMaven`.
 
 ### Building a JAR {#building-a-jar}
 

doc/languages-frameworks/neovim.section.md

···
 # Neovim {#neovim}
 
-Install `neovim-unwrapped` to get a barebone neovim to configure imperatively.
+Install `neovim-unwrapped` to get a bare-bones Neovim to configure imperatively.
 This is the closest to what you encounter on other distributions.
 
-`neovim` is a wrapper around neovim with some extra configuration to for
-instance set the various language providers like python.
+`neovim` is a wrapper around Neovim with some extra configuration, for
+instance, to set the various language providers like Python.
 The wrapper can be further configured to include your favorite plugins and
 configurations for a reproducible neovim across machines.
 See the next section for more details.
···
 ```
 
 You can use the new unstable wrapper but the interface may change:
-- `autoconfigure`: certain plugins need a custom configuration to work with nix.
+- `autoconfigure`: certain plugins need a custom configuration to work with Nix.
 For instance, `sqlite-lua` needs `g:sqlite_clib_path` to be set to work. Nixpkgs historically patched these in the plugins with several drawbacks: harder maintenance and making upstream work harder. Per convention, these mandatory bits of configuration are bookmarked in nixpkgs in `passthru.initLua`. Enabling `autoconfigure` automatically adds the snippets required for the plugins to work.
 - `autowrapRuntimeDeps`: Appends plugin's runtime dependencies to `PATH`. For instance, `rest.nvim` requires `curl` to work. Enabling `autowrapRuntimeDeps` adds it to the `PATH` visible by your Neovim wrapper (but not your global `PATH`).
 - `luaRcContent`: Extra lua code to add to the generated `init.lua`.
···
 
 #### LuaRocks based plugins {#neovim-luarocks-based-plugins}
 
-In order to automatically handle plugin dependencies, several neovim plugins
+In order to automatically handle plugin dependencies, several Neovim plugins
 upload their package to [LuaRocks](https://www.luarocks.org). This means less work for nixpkgs maintainers in the long term as dependencies get updated automatically.
-This means several neovim plugins are first packaged as nixpkgs [lua
+This means several Neovim plugins are first packaged as nixpkgs [lua
 packages](#packaging-a-library-on-luarocks), and converted via `buildNeovimPlugin` in
-a vim plugin. This conversion is necessary because neovim expects lua folders to be
-top-level while luarocks installs them in various subfolders by default.
+a vim plugin. This conversion is necessary because Neovim expects lua folders to be
+top-level while LuaRocks installs them in various subfolders by default.
 
 For instance:
 ```nix
···
 ### Testing Neovim plugins {#testing-neovim-plugins}
 
 #### neovimRequireCheck {#testing-neovim-plugins-neovim-require-check}
-`neovimRequireCheck` is a simple test which checks if Neovim can requires lua modules without errors. This is often enough to catch missing dependencies.
+`neovimRequireCheck` is a simple test which checks if Neovim can require lua modules without errors. This is often enough to catch missing dependencies.
 
 It accepts a single string for a module, or a list of module strings to test.
 - `nvimRequireCheck = MODULE;`
···
   };
 }
 ```
-Some plugins will have lua modules that require a user configuration to function properly or can contain optional lua modules that we dont want to test requiring.
+Some plugins will have lua modules that require a user configuration to function properly or can contain optional lua modules that we don't want to test by requiring.
 We can skip specific modules using `nvimSkipModules`. Similar to `nvimRequireCheck`, it accepts a list of strings.
 - `nvimSkipModules = [ MODULE1 MODULE2 ];`
 

doc/languages-frameworks/ocaml.section.md

···
 
 - 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
-  complete, but only if the Ocaml version is at at least `"4.05"`.
+  complete, but only if the OCaml version is at at least `"4.05"`.
 
 - It uses the package `ocaml-syntax-shims` as a build input, `alcotest` and
   `ppx_let` as check inputs (because they are needed to run the tests), and

doc/languages-frameworks/octave.section.md

···
 Nixpkgs provides a function `buildOctavePackage`, a generic package builder function for any Octave package that complies with the Octave's current packaging format.
 
 All Octave packages are defined in [pkgs/top-level/octave-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/octave-packages.nix) rather than `pkgs/all-packages.nix`.
-Each package is defined in their own file in the [pkgs/development/octave-modules](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules) directory.
+Each package is defined in its own file in the [pkgs/development/octave-modules](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules) directory.
 Octave packages are made available through `all-packages.nix` through both the attribute `octavePackages` and `octave.pkgs`.
 You can test building an Octave package as follows:
 
···
 
 1. Sets the environment variable `OCTAVE_HISTFILE` to `/dev/null` during package compilation so that the commands run through the Octave interpreter directly are not logged.
 2. Skips the configuration step, because the packages are stored as gzipped tarballs, which Octave itself handles directly.
-3. Change the hierarchy of the tarball so that only a single directory is at the top-most level of the tarball.
+3. Changes the hierarchy of the tarball so that only a single directory is at the top-most level of the tarball.
 4. Use Octave itself to run the `pkg build` command, which unzips the tarball, extracts the necessary files written in Octave, and compiles any code written in C++ or Fortran, and places the fully compiled artifact in `$out`.
 
 `buildOctavePackage` is built on top of `stdenv` in a standard way, allowing most things to be customized.
···
 
 By default, the `buildOctavePackage` function does _not_ install the requested package into Octave for use.
 The function will only build the requested package.
-This is due to Octave maintaining an text-based database about which packages are installed where.
+This is due to Octave maintaining a text-based database about which packages are installed where.
 To this end, when all the requested packages have been built, the Octave package and all its add-on packages are put together into an environment, similar to Python.
 
 1. First, all the Octave binaries are wrapped with the environment variable `OCTAVE_SITE_INITFILE` set to a file in `$out`, which is required for Octave to be able to find the non-standard package database location.
···
 3. The path down to the default install location of Octave packages is recreated so that Nix-operated Octave can install the packages.
 4. Install the packages into the `$out` environment while writing package entries to the database file.
 This database file is unique for each different (according to Nix) environment invocation.
-5. Rewrite the Octave-wide startup file to read from the list of packages installed in that particular environment.
+5. Rewrites the Octave-wide startup file to read from the list of packages installed in that particular environment.
 6. Wrap any programs that are required by the Octave packages so that they work with all the paths defined within the environment.

doc/languages-frameworks/php.section.md

···
 it deals with "packages" or libraries, but it manages them on a per-project
 basis, installing them in a directory (e.g. `vendor`) inside your project. By
 default, it does not install anything globally. This idea is not new and
-Composer is strongly inspired by node's `npm` and ruby's `bundler`.
+Composer is strongly inspired by Node's `npm` and Ruby's `bundler`.
 
 Currently, there is no other PHP tool that offers the same functionality as
 Composer. Consequently, incorporating a helper in Nix to facilitate building

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

···
 Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
 They should also use `testers.hasPkgConfigModules` to check that the final built package matches that list,
 and optionally check that the pkgconf modules' version metadata matches the derivation's.
-Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig), will do extra checks on to-be-installed pkg-config modules.
+Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig) will do extra checks on to-be-installed pkg-config modules.
 
 A good example of all these things is miniz:
 

doc/languages-frameworks/python.section.md

···
 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.13. The attribute `python` refers to
-CPython 2.7 for backwards-compatibility. It is also possible to refer to
-specific versions, e.g. `python313` refers to CPython 3.13, and `pypy` refers to
+CPython 2.7 for backwards compatibility. It is also possible to refer to
+specific versions, e.g., `python313` refers to CPython 3.13, and `pypy` refers to
 the default PyPy interpreter.
 
 Python is used a lot, and in different ways. This affects also how it is
···
 
 If the dependencies are not available on the host where `foo.py` is executed, it
 will build or download them from a Nix binary cache prior to starting up, prior
-that it is executed on a machine with a multi-user nix installation.
+that it is executed on a machine with a multi-user Nix installation.
 
 This provides a way to ship a self bootstrapping Python script, akin to a
 statically linked binary, where it can be run on any machine (provided nix is
···
 system.
 
 By default it is pulling the import checkout of Nixpkgs itself from our nix
-channel, which is nice as it cache aligns with our other package builds, but we
+channel, which is nice as it cache-aligns with our other package builds, but we
 can make it fully reproducible by pinning the `nixpkgs` import:
 
 ```python
···
 
 This will create a unified environment that has not just our Python interpreter
 and its Python dependencies, but also tools like `black` or `mypy` and libraries
-like `libffi` the `openssl` in scope. This is generic and can span any number of
+like `libffi` and `openssl` in scope. This is generic and can span any number of
 tools or languages across the Nixpkgs ecosystem.
 
 ##### Installing environments globally on the system {#installing-environments-globally-on-the-system}

doc/languages-frameworks/qt.section.md

···
 # Qt {#sec-language-qt}
 
-Writing Nix expressions for Qt libraries and applications is largely similar as for other C++ software.
+Writing Nix expressions for Qt libraries and applications is largely similar to that for other C++ software.
 This section assumes some knowledge of the latter.
 
 The major caveat with Qt applications is that Qt uses a plugin system to load additional modules at runtime.
···
 
 ## Locating additional runtime dependencies {#qt-runtime-dependencies}
 
-Add entries to `qtWrapperArgs` are to modify the wrappers created by
+Add entries to `qtWrapperArgs` to modify the wrappers created by
 `wrapQtAppsHook`:
 
 ```nix

doc/languages-frameworks/ruby.section.md

···
 
 Now that you know how to get a working Ruby environment with Nix, it's time to go forward and start actually developing with Ruby. We will first have a look at how Ruby gems are packaged on Nix. Then, we will look at how you can use development mode with your code.
 
-All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible to each other.
+All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible with each other.
 
 In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
 
···
 
 ### Packaging applications {#packaging-applications}
 
-A common task is to add a ruby executable to nixpkgs, popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables, otherwise the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
+A common task is to add a Ruby executable to Nixpkgs; popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables. Otherwise, the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
 
 The absolute easiest way to do that is to write a `Gemfile` along these lines:
 
···
 
 #### Packaging executables that require wrapping {#packaging-executables-that-require-wrapping}
 
-Sometimes your app will depend on other executables at runtime, and tries to find it through the `PATH` environment variable.
+Sometimes your app will depend on other executables at runtime and try to find them through the `PATH` environment variable.
 
 In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
 

doc/languages-frameworks/rust.section.md

···
 # Rust {#rust}
 
-To install the rust compiler and cargo put
+To install the Rust compiler and cargo, put
 
 ```nix
 {
···
 into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
 
 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),
+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).
 
 ## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
···
 { cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8="; }
 ```
 
-If this method does not work, you can resort to copying the `Cargo.lock` file into nixpkgs
+If this method does not work, you can resort to copying the `Cargo.lock` file into Nixpkgs
 and importing it as described in the [next section](#importing-a-cargo.lock-file).
 
-Both types of hashes are permitted when contributing to nixpkgs. The
+Both types of hashes are permitted when contributing to Nixpkgs. The
 Cargo hash is obtained by inserting a fake checksum into the
 expression and building the package once. The correct checksum can
 then be taken from the failed build. A fake hash can be used for
···
 ### Cross compilation {#cross-compilation}
 
 By default, Rust packages are compiled for the host platform, just like any
-other package is.  The `--target` passed to rust tools is computed from this.
+other package is. The `--target` passed to Rust tools is computed from this.
 By default, it takes the `stdenv.hostPlatform.config` and replaces components
 where they are known to differ. But there are ways to customize the argument:
 
···
 ### Building a crate with an absent or out-of-date Cargo.lock file {#building-a-crate-with-an-absent-or-out-of-date-cargo.lock-file}
 
 `buildRustPackage` needs a `Cargo.lock` file to get all dependencies in the
-source code in a reproducible way. If it is missing or out-of-date one can use
+source code in a reproducible way. If it is missing or out of date, one can use
 the `cargoPatches` attribute to update or add it.
 
 ```nix
···
 ## Using community maintained Rust toolchains {#using-community-maintained-rust-toolchains}
 
 ::: {.note}
-The following projects cannot be used within Nixpkgs since [Import From Derivation](https://nixos.org/manual/nix/unstable/language/import-from-derivation) (IFD) is disallowed in Nixpkgs.
+The following projects cannot be used within Nixpkgs, since [Import From Derivation](https://nixos.org/manual/nix/unstable/language/import-from-derivation) (IFD) is disallowed in Nixpkgs.
 To package things that require Rust nightly, `RUSTC_BOOTSTRAP = true;` can sometimes be used as a hack.
 :::
 
···
 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.
+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

doc/languages-frameworks/scheme.section.md

···
 in a derivation's `buildInputs`, work inside of `nix-shell`, and
 are tested using [Chez](https://www.scheme.com/) &
 [Chibi](https://synthcode.com/wiki/chibi-scheme)
-Scheme during build time.
+Scheme at build time.
 
 Including a package as a build input is done in the typical Nix fashion.
 For example, to include

doc/languages-frameworks/swift.section.md

···
   (Where `linux` and `x86_64` are from lowercase `uname -sm`.)
 - 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.
+  will produce output for just one target anyway.
 
 ## Core libraries {#ssec-swift-core-libraries}
 
 In addition to the standard library, the Swift toolchain contains some
 additional 'core libraries' that, on Apple platforms, are normally distributed
-as part of the OS or Xcode. These are packaged separately in Nixpkgs, and can
+as part of the OS or Xcode. These are packaged separately in Nixpkgs and can
 be found (for use in `buildInputs`) as:
 
 - `swiftPackages.Dispatch`
···
 
 The `swift` package has a separate `lib` output containing just the Swift
 standard library, to prevent Swift applications needing a dependency on the
-full Swift compiler at run-time. Linking with the Nixpkgs Swift toolchain
+full Swift compiler at runtime. Linking with the Nixpkgs Swift toolchain
 already ensures binaries correctly reference the `lib` output.
 
 Sometimes, Swift is used only to compile part of a mixed codebase, and the

doc/languages-frameworks/texlive.section.md

···
   ```
   This can be applied before or after calling `withPackages`.
 
-  The function currently support the parameters `withDocs`, `withSources`, and `requireTeXPackages`.
+  The function currently supports the parameters `withDocs`, `withSources`, and `requireTeXPackages`.
 
 ## User's guide {#sec-language-texlive-user-guide}
 
···
   nix-repl> texlive.collection-[TAB]
   ```
 
-- Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example `scheme-basic`, into the combination.
+- Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example, `scheme-basic`, into the combination.
 
 - TeX Live packages are also available under `texlive.pkgs` as derivations with outputs `out`, `tex`, `texdoc`, `texsource`, `tlpkg`, `man`, `info`. They cannot be installed outside of `texlive.combine` but are available for other uses. To repackage a font, for instance, use
 

doc/languages-frameworks/vim.section.md

···
 nix-shell -p vimPluginsUpdater --run 'vim-plugins-updater update "nvim-treesitter" "LazyVim"'
 ```
 
-## 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? {#vim-out-of-tree-overlays}
 
 You can use the updater script to generate basic packages out of a custom vim
 plugin list:

doc/packages/cataclysm-dda.section.md

···
 an alias to `cataclysmDDA.stable.tiles`.
 
 If you like access to a development build of your favorite git revision,
-override `cataclysm-dda-git` (or `cataclysmDDA.git.curses` if you like curses
+override `cataclysm-dda-git` (or `cataclysmDDA.git.curses` if you like the curses
 build):
 
 ```nix

doc/packages/citrix.section.md

···
 
 ## Citrix Self-service {#sec-citrix-selfservice}
 
-The [self-service](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
+The [self-service](https://support.citrix.com/article/CTX200337) is an application for managing Citrix desktops and applications. Please note that this feature only works with at least `citrix_workspace_20_06_0` and later versions.
 
 In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
 
···
 
 ## Custom certificates {#sec-citrix-custom-certs}
 
-The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
+The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however, this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
 
 ```nix
 with import <nixpkgs> { config.allowUnfree = true; };

doc/packages/dlib.section.md

···
 
 Especially older CPUs don't support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
 
-On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:
+On the affected hardware, errors like `Illegal instruction` will occur. In those cases, AVX support needs to be disabled:
 
 ```nix
 self: super: { dlib = super.dlib.override { avxSupport = false; }; }

doc/packages/eclipse.section.md

···
 
 The Nix expressions related to the Eclipse platform and IDE are in [`pkgs/applications/editors/eclipse`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse).
 
-Nixpkgs provides a number of packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages and multiple version are often available. It is possible to list available Eclipse packages by issuing the command:
+Nixpkgs provides several packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages, and multiple versions are often available. It is possible to list available Eclipse packages by issuing the command:
 
 ```ShellSession
 $ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
 ```
 
-Once an Eclipse variant is installed, it can be run using the `eclipse` command, as expected. From within Eclipse, it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
+Once an Eclipse variant is installed, it can be run using the `eclipse` command, as expected. From within Eclipse, it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resembles a manually installed Eclipse.
 
-If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
+If you prefer to install plugins in a more declarative manner, then Nixpkgs also offers several Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as an argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
 
 ```nix
 {
···
 }
 ```
 
-to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running:
+to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward running Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running:
 
 ```ShellSession
 $ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description

doc/packages/emacs.section.md

···
 
 ## Configuring Emacs {#sec-emacs-config}
 
-The Emacs package comes with some extra helpers to make it easier to configure. `emacs.pkgs.withPackages` allows you to manage packages from ELPA. This means that you will not have to install that packages from within Emacs. For instance, if you wanted to use `company` `counsel`, `flycheck`, `ivy`, `magit`, `projectile`, and `use-package` you could use this as a `~/.config/nixpkgs/config.nix` override:
+The Emacs package comes with some extra helpers to make it easier to configure. `emacs.pkgs.withPackages` allows you to manage packages from ELPA. This means that you will not have to install those packages from within Emacs. For instance, if you wanted to use `company`, `counsel`, `flycheck`, `ivy`, `magit`, `projectile`, and `use-package`, you could use this as a `~/.config/nixpkgs/config.nix` override:
 
 ```nix
 {
···
 }
 ```
 
-You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
+You can install it like any other package via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
 
 ```nix
 {

doc/packages/etc-files.section.md

···
 
 Certain calls in glibc require access to runtime files found in `/etc` such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
 
-On non-NixOS distributions these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
+On non-NixOS distributions, these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
 
 If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your `buildInputs`, then it will set the environment variables `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a setup hook.
 
···
 NIX_ETC_PROTOCOLS=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/protocols
 ```
 
-Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`.
+Nixpkgs's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`.

doc/packages/firefox.section.md

···
 Nix installed add-ons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded add-ons are checksummed and manual add-ons can't be installed. Also, make sure that the `name` field of `fetchFirefoxAddon` is unique. If you remove an add-on from the `nixExtensions` array, rebuild and start Firefox: the removed add-on will be completely removed with all of its settings.
 
 ## Troubleshooting {#sec-firefox-troubleshooting}
-If add-ons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for add-ons thus nix add-ons get disabled by the normal Firefox binary.
+If add-ons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for add-ons; thus, Nix add-ons get disabled by the normal Firefox binary.
 
 If add-ons do not appear installed despite being defined in your nix configuration file, reset the local add-on state of your Firefox profile by clicking `Help -> More Troubleshooting Information -> Refresh Firefox`. This can happen if you switch from manual add-on mode to nix add-on mode and then back to manual mode and then again to nix add-on mode.

doc/packages/fish.section.md

···
 When the `programs.fish.enable` and
 `programs.fish.vendor.{completions,config,functions}.enable` options from the
 NixOS Fish module are set to true, those paths are symlinked in the current
-system environment and automatically loaded by Fish.
+system environment and are automatically loaded by Fish.
 
 
 ## Packaging Fish plugins {#sec-fish-plugins-pkg}

doc/packages/fuse.section.md

···
 [FUSE](https://www.kernel.org/doc/html/latest/filesystems/fuse.html) to provide
 support for additional filesystems not supported by the kernel.
 
-In general, FUSE software are primarily developed for Linux but many of them can
+In general, FUSE software is primarily developed for Linux but many of them can
 also run on macOS. Nixpkgs supports FUSE packages on macOS, but it requires
 [macFUSE](https://osxfuse.github.io) to be installed outside of Nix. macFUSE
-currently isn't packaged in Nixpkgs mainly because it includes a kernel
+currently isn't packaged in Nixpkgs, mainly because it includes a kernel
 extension, which isn't supported by Nix outside of NixOS.
 
 If a package fails to run on macOS with an error message similar to the
···
     checking for fuse.h... no
     configure: error: No fuse.h found.
 
-This happens on autoconf based projects that use `AC_CHECK_HEADERS` or
+This happens on autoconf-based projects that use `AC_CHECK_HEADERS` or
 `AC_CHECK_LIBS` to detect libfuse, and will occur even when the `fuse` package
 is included in `buildInputs`. It happens because libfuse headers throw an error
 on macOS if the `FUSE_USE_VERSION` macro is undefined. Many projects do define

doc/packages/inkscape.section.md

···
 [nix-shell:~]$ inkscape
 ```
 
-All available extension can be enabled by passing `inkscapeExtensions = null;`.
+All available extensions can be enabled by passing `inkscapeExtensions = null;`.
 
 ::: {.note}
 Loading the Inkscape extensions stand-alone (without using `override`) does not affect Inkscape at all.

doc/packages/locales.section.md

···
 # Locales {#locales}
 
-To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
+To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on the `LOCALE_ARCHIVE` environment variable.
 
 On non-NixOS distributions, this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.

doc/packages/nginx.section.md

···
 
 Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g., a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
 
-The nginx package in Nixpkgs is patched such that when nginx serves a file out of `/nix/store`, the hash in the store path is used as the `ETag` header in the HTTP response, thus providing proper caching functionality. With NixOS 24.05 and later, the `ETag` additionally includes the response content length, to ensure files served with static compression do not share `ETag`s with their uncompressed version. This `ETag` functionality is enabled automatically; you do not need to do modify any configuration to get this behavior.
+The nginx package in Nixpkgs is patched such that when nginx serves a file out of `/nix/store`, the hash in the store path is used as the `ETag` header in the HTTP response, thus providing proper caching functionality. With NixOS 24.05 and later, the `ETag` additionally includes the response content length, to ensure files served with static compression do not share `ETag`s with their uncompressed version. This `ETag` functionality is enabled automatically; you do not need to modify any configuration to get this behavior.

doc/packages/python-tree-sitter.section.md

···
 print(tree.root_node)
 ```
 
-The `tree_sitter_rust.language()` function references the Rust grammar loaded in the Nix shell. The resulting tree allows you to inspect the structure of the code programmatically.
+The `tree_sitter_rust.language()` function references the Rust grammar loaded in the Nix shell. The resulting tree allows you to programmatically inspect the structure of the code.
 

doc/packages/shell-helpers.section.md

···
 # Interactive shell helpers {#sec-shell-helpers}
 
-Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn't have a standard `share` directory location. This is why a bunch `PACKAGE-share` scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:
+Some packages provide shell integration to be more useful. But unlike other systems, nix doesn't have a standard `share` directory location. This is why a bunch of `PACKAGE-share` scripts are shipped that print the location of the corresponding shared folder. The current list of such packages is as follows:
 
 - `fzf` : `fzf-share`
 

doc/packages/steam.section.md

···
 
 ## Steam in Nix {#sec-steam-nix}
 
-Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in `$HOME`.
+Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is ultimately responsible for launching the steam binary, which is also in `$HOME`.
 
 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](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.
+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}
 

doc/packages/urxvt.section.md

···
 
 ## Packaging urxvt plugins {#sec-urxvt-pkg}
 
-Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin, create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
+Urxvt plugins reside in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin, create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
 
-A plugin can be any kind of derivation, the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples.
+A plugin can be any kind of derivation; the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples.
 
 If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
 

doc/packages/vcpkg.section.md

···
 # VCPKG {#sec-vcpkg}
 
-The `vcpkg-tool` package  has a wrapper around the `vcpkg` executable to avoid writing to the nix store.
+The `vcpkg-tool` package has a wrapper around the `vcpkg` executable to avoid writing to the nix store.
 The wrapper will also be present in `vcpkg`, unless you specify `vcpkg.override { vcpkg-tool = vcpkg-tool-unwrapped; }`
 
-The wrapper has been made in a way so that it will provide default cli arguments, but tries not to interfere if the user provides the same arguments.
+The wrapper has been made in a way so that it will provide default cli arguments but tries not to interfere if the user provides the same arguments.
 The arguments also have corresponding environment variables that can be used as an alternative way of overriding these paths.
 
 Run the wrapper with the environment variable `NIX_VCPKG_DEBUG_PRINT_ENVVARS=true` to get a full list of corresponding environment variables.
 
 ## Nix specific environment variables {#sec-vcpkg-nix-envvars}
 
-The wrapper also provides some new nix-specific environment variables that lets you control some of the wrapper functionality.
+The wrapper also provides some new nix-specific environment variables that let you control some of the wrapper functionality.
 
 - `NIX_VCPKG_WRITABLE_PATH = <path>`
 

doc/packages/weechat.section.md

···
 
 The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and `lua`.
 
-The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
+The Python and Perl plugins allow the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
 
 ```nix
 weechat.override {

doc/packages/xorg.section.md

···
 # X.org {#sec-xorg}
 
-The Nix expressions for the X.org packages reside in `pkgs/servers/x11/xorg/default.nix`. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file `pkgs/servers/x11/xorg/overrides.nix`, in which you can override or add to the derivations produced by the generator.
+The Nix expressions for the X.org packages reside in `pkgs/servers/x11/xorg/default.nix`. This file is automatically generated from lists of tarballs in an X.org release. As such, it should not be modified directly; rather, you should modify the lists, the generator script, or the file `pkgs/servers/x11/xorg/overrides.nix`, in which you can override or add to the derivations produced by the generator.
 
 ## Katamari Tarballs {#katamari-tarballs}
 

doc/preface.chapter.md

···
 package manager on most GNU/Linux distributions as well as [NixOS](https://nixos.org/nixos).
 
 This document is the user [_reference_](https://nix.dev/contributing/documentation/diataxis#reference) manual for Nixpkgs.
-It describes entire public interface of Nixpkgs in a concise and orderly manner, and all relevant behaviors, with examples and cross-references.
+It describes the entire public interface of Nixpkgs in a concise and orderly manner, and all relevant behaviors, with examples and cross-references.
 
 To discover other kinds of documentation:
 - [nix.dev](https://nix.dev/): Tutorials and guides for getting things done with Nix
···
 `nixpkgs-unstable`. Users of NixOS generally use one of the `nixos-*` channels,
 e.g. `nixos-22.11`, which includes all packages and modules for the stable NixOS
 22.11. Stable NixOS releases are generally only given
-security updates. More up to date packages and modules are available via the
+security updates. More up-to-date packages and modules are available via the
 `nixos-unstable` channel.
 
 Both `nixos-unstable` and `nixpkgs-unstable` follow the `master` branch of the

doc/release-notes/release-notes.md

···
 # Release Notes {#chap-release-notes}
 
-This section lists the release notes for each stable version of Nixpkgs and current unstable revision.
+This section lists the release notes for each stable version of Nixpkgs and the current unstable revision.
 
 ```{=include=} sections
 rl-2511.section.md

doc/release-notes/rl-2505.section.md

···
 
 - Emacs has been updated to 30.1.
   This introduces some backwards‐incompatible changes; see the NEWS for details.
-  NEWS can been viewed from Emacs by typing `C-h n`, or by clicking `Help->Emacs News` from the menu bar.
+  NEWS can be viewed from Emacs by typing `C-h n`, or by clicking `Help->Emacs News` from the menu bar.
   It can also be browsed [online](https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30).
 
 - The `intel` video driver for X.org (from the xf86-video-intel package, which was previously removed because it was non-functional) has been fixed and the driver has been re-introduced.
···
   rather than a port. See [Migrating from version 1.x](https://github.com/roehling/postsrsd/blob/2.0.10/README.rst#migrating-from-version-1x) and [Postfix Setup](https://github.com/roehling/postsrsd?tab=readme-ov-file#postfix-setup) for details.
 
 - `renovate` was updated to v39. See the [upstream release notes](https://github.com/renovatebot/renovate/releases/tag/39.0.0) for breaking changes.
-  Like upstream's docker images, renovate now runs on NodeJS 22.
+  Like upstream's Docker images, renovate now runs on NodeJS 22.
 
-- The hand written `perlPackages.SearchXapian` bindings have been dropped in favor of the (mostly compatible)
+- The handwritten `perlPackages.SearchXapian` bindings have been dropped in favor of the (mostly compatible)
   `perlPackages.Xapian`.
 
 - `varnish` was updated from 7.5.0 to 7.7.0, see [Varnish 7.6.0 upgrade guide](https://varnish-cache.org/docs/7.6/whats-new/upgrading-7.6.html) and
···
   Cargo 1.84.0 changed the format of `cargo vendor` output, which invalidated all existing `rustPlatform.fetchCargoTarball` hashes.
   To preserve Nix’s invariants, it has been replaced with `rustPlatform.fetchCargoVendor`, an independent implementation prioritizing format stability.
   `rustPlatform.buildRustPackage` now uses `rustPlatform.fetchCargoVendor` by default; a hash mismatch error is expected in third‐party Rust packages when updating to Nixpkgs 25.05.
-  Packages wishing to maintain compatibility with Nixpkgs 24.11 must set `useFetchCargoVendor` to `true` explicitly.
+  Packages wishing to maintain compatibility with Nixpkgs 24.11 must explicitly set `useFetchCargoVendor` to `true`.
   `rustPlatform.importCargoLock` may also be appropriate in some circumstances.
 
 - `cassandra_3_0` and `cassandra_3_11` have been removed as they have reached end-of-life. Please update to `cassandra_4`. See the [changelog](https://github.com/apache/cassandra/blob/cassandra-4.0.17/NEWS.txt) for more information about the upgrade process.
···
   the [release announcement](https://kafka.apache.org/blog#apache_kafka_400_release_announcement)
   for more details.
 
-- `ast-grep` remove `sg` command to prevent conflict with `sg` command from shadow-utils. If you need legacy sg command compatibility with old code, you can use `ast-grep.override { enableLegacySg = true; }`
+- `ast-grep` removes the `sg` command to prevent conflict with the `sg` command from shadow-utils. If you need legacy sg command compatibility with old code, you can use `ast-grep.override { enableLegacySg = true; }`
 
 - rename package `wtf` to `wtfutil`.
 
···
 
 - `wastebin` has been updated to 3.0.0. See the [Changelog](https://github.com/matze/wastebin/blob/master/CHANGELOG.md#300) for breaking changes to the configuration.
 
-- `binwalk` was updated to 3.1.0, which has been rewritten in rust. The python module is no longer available.
+- `binwalk` was updated to 3.1.0, which has been rewritten in Rust. The Python module is no longer available.
   See the release notes of [3.1.0](https://github.com/ReFirmLabs/binwalk/releases/tag/v3.1.0) for more information.
 
 - `pkgs.nextcloud28` and `pkgs.nextcloud29` have been removed since they are out of support upstream.
···
 - `buildGoModule` now supports a `goSum` attribute (`null` by default) to optionally provide a path to `go.sum` and correctly enabling rebuilds when the file changes.
 
 - The newly added aliases `go_latest` and `buildGoLatestModule` are now available and can be use to prevent packages like `gopls` from breaking whenever the default toolchain minor version is lagging behind.
-  It can also be used _outside of nixpkgs_ to get fast access to new Go minor versions without having to wait for a staging cycle that will update the default builder/toolchain.
+  It can also be used _outside of Nixpkgs_ to get fast access to new Go minor versions without having to wait for a staging cycle that will update the default builder/toolchain.
 
-- A [policy documenting the details of Go toolchain and builder upgrades](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md#go-toolchainbuilder-upgrade-policy) in nixpkgs, as well as rules related to using non-default builders like `buildGo1xxModule` and `buildGoLatestModule` has been added in-tree.
+- A [policy documenting the details of Go toolchain and builder upgrades](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md#go-toolchainbuilder-upgrade-policy) in Nixpkgs, as well as rules related to using non-default builders like `buildGo1xxModule` and `buildGoLatestModule` has been added in-tree.
 
 - top-level `playwright` now refers to the github Microsoft/playwright package
   instead of the python tester launcher. You can still refer to the python
···
 - `ps3-disc-dumper` was updated to 4.2.5, which removed the CLI project and now exclusively offers the GUI
 
 - `kmonad` is now hardened by default using common `systemd` settings.
-  If KMonad is used to execute shell commands, hardening may make some of them fail.  In that case, you can disable hardening using {option}`services.kmonad.keyboards.<name>.enableHardening` option.
+  If KMonad is used to execute shell commands, hardening may make some of them fail.  In that case, you can disable hardening using the {option}`services.kmonad.keyboards.<name>.enableHardening` option.
 
 - `isd` was updated from 0.2.0 to 0.5.1, the new version may crash with a previously generated config, try moving or deleting `~/.config/isd/schema.json`.
 
···
 
 - `dwarf-fortress-packages` now only contains one minor version for each major version since version 0.44. Saves should still be compatible, but you may have to change which minor version you were using if it was one other than the newest.
 
-- `tpm2-pkcs11` now is compiled without abrmd (Access Broker and Resource Manager Daemon) support by default, preferring the kernel resource manager. Use `tpm2-pkcs11.abrmd` if you would like a version with abrmd support. Note that the NixOS module picks the correct one automatically based on `security.tpm2.abrmd`.
+- `tpm2-pkcs11` now is compiled without `abrmd` (Access Broker and Resource Manager Daemon) support by default, preferring the kernel resource manager. Use `tpm2-pkcs11.abrmd` if you would like a version with `abrmd` support. Note that the NixOS module picks the correct one automatically based on `security.tpm2.abrmd`.
 
 - `zig_0_9` and `zig_0_10` have been removed, you should upgrade to `zig_0_13` (also available as just `zig`), `zig_0_12` or `zig_0_11` instead.
 
···
   [Prisma ORM upgrade guide](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6)
   for more information.
 
-- `dependency-track` no longer bundes the UI inside the jar. This bundling
+- `dependency-track` no longer bundles the UI inside the jar. This bundling
   functionality is deprecated by upstream and causes UI assets not being served
   after weeks of runtime.
 
···
 
 - `confluent-cli` was updated from 3.60.0 to 4.16.0, which includes several breaking changes as detailed in [Confluent's release notes](https://docs.confluent.io/confluent-cli/current/release-notes.html).
 
-- `siduck76-st` has been renamed to `st-snazzy`, like the project's [flake](https://github.com/siduck/st/blob/main/flake.nix).
+- `siduck76-st` has been renamed to `st-snazzy`, like the project's [flake](https://github.com/siduck/st/blob/main/flake.nix). An alias for the old name has been added.
 
 - `python3Packages.jax` now directly depends on `python3Packages.jaxlib`.
   As a result, packages that depend on jax no longer need to include jaxlib to their dependencies.
-  There is also a breaking change in the handling of CUDA. Instead of using a CUDA compatible jaxlib
+  There is also a breaking change in the handling of CUDA. Instead of using a CUDA-compatible jaxlib
   as before, you can use plugins like `python3Packages.jax-cuda12-plugin`.
 
 - Added `allowVariants` to gate availability of package sets like `pkgsLLVM`, `pkgsMusl`, `pkgsZig`, etc. This was done in an effort to
···
 
 - The `stackclashprotection` hardening flag has been enabled by default on compilers that support it.
 
-- In `dovecot` package removed hard coding path to module directory.
+- In `dovecot` package, the hardcoded path to the module directory has been removed.
 
 - `authelia` version 4.39.0 has made some changes which deprecate older configurations.
   They are still expected to be working until future version 5.0.0, but will generate warnings in logs.
···
 
 - `hddfancontrol` has been updated to major release 2. See the [migration guide](https://github.com/desbma/hddfancontrol/tree/master?tab=readme-ov-file#migrating-from-v1x), as there are breaking changes.
 
-- `nextcloud-news-updater` is unmaintained and was removed from nixpkgs.
+- `nextcloud-news-updater` is unmaintained and was removed from Nixpkgs.
 
 - KDE Partition Manager `partitionmanager`'s support for ReiserFS is removed.
   ReiserFS has not been actively maintained for many years. It has been marked as obsolete since Linux 6.6, and

doc/release-notes/rl-2511.section.md

···
 - `gentium` package now provides `Gentium-*.ttf` files, and not `GentiumPlus-*.ttf` files like before. The font identifiers `Gentium Plus*` are available in the `gentium-plus` package, and if you want to use the more recently updated package `gentium` [by sil](https://software.sil.org/gentium/), you should update your configuration files to use the `Gentium` font identifier.
 - `space-orbit` package has been removed due to lack of upstream maintenance. Debian upstream stopped tracking it in 2011.
 
-- Derivations setting both `separateDebugInfo` and one of `allowedReferences`, `allowedRequistes`, `disallowedReferences` or `disallowedRequisites` must now set `__structuredAttrs` to `true`. The effect of reference whitelisting or blacklisting will be disabled on the `debug` output created by `separateDebugInfo`.
+- Derivations setting both `separateDebugInfo` and one of `allowedReferences`, `allowedRequisites`, `disallowedReferences` or `disallowedRequisites` must now set `__structuredAttrs` to `true`. The effect of reference whitelisting or blacklisting will be disabled on the `debug` output created by `separateDebugInfo`.
+
 - `victoriametrics` no longer contains VictoriaLogs components. These have been separated into the new package `victorialogs`.
 
-- `mx-puppet-discord` was removed from nixpkgs along with its NixOS module as it was unmaintained and was the only user of sha1 hashes in tree.
+- `mx-puppet-discord` was removed from Nixpkgs along with its NixOS module as it was unmaintained and was the only user of sha1 hashes in tree.
 
 - `kbd` package's `outputs` now include a `man` and `scripts` outputs. The `unicode_start` and `unicode_stop` Bash scripts are now part of the `scripts` output, allowing most usages of the `kbd` package to not pull in `bash`.
 
···
 
 - `telegram-desktop` packages now uses `Telegram` for its binary. The previous name was `telegram-desktop`. This is due to [an upstream decision](https://github.com/telegramdesktop/tdesktop/commit/56ff5808a3d766f892bc3c3305afb106b629ef6f) to make the name consistent with other platforms.
 
-- `podofo` has been updated from `0.9.8` to `1.0.0`. These releases are by nature very incompatable due to major api changes. The legacy versions can be found under `podofo_0_10` and `podofo_0_9`.
+- `podofo` has been updated from `0.9.8` to `1.0.0`. These releases are by nature very incompatible due to major API changes. The legacy versions can be found under `podofo_0_10` and `podofo_0_9`.
   Changelog: https://github.com/podofo/podofo/blob/1.0.0/CHANGELOG.md, API-Migration-Guide: https://github.com/podofo/podofo/blob/1.0.0/API-MIGRATION.md.
 
 - NetBox was updated to `>= 4.3.0`. Have a look at the breaking changes
···
 
 - `rocmPackages.triton` has been removed in favor of `python3Packages.triton`.
 
-- `go-mockery` has been updated to v3. For migration instructions see the [upstream documentation](https://vektra.github.io/mockery/latest/v3/). If v2 is still required `go-mockery_v2` has been added but will be removed on or before 2029-12-31 in-line with it's [upstream support lifecycle](https://vektra.github.io/mockery/
+- `go-mockery` has been updated to v3. For migration instructions see the [upstream documentation](https://vektra.github.io/mockery/latest/v3/). If v2 is still required `go-mockery_v2` has been added but will be removed on or before 2029-12-31 in-line with its [upstream support lifecycle](https://vektra.github.io/mockery/)
 
 - [private-gpt](https://github.com/zylon-ai/private-gpt) service has been removed by lack of maintenance upstream.
 
···
 
 <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
 
-- `mealie` has been updated to 3.0.2: This update introduces breaking changes in some API endpoints (see the [release changelog](https://github.com/mealie-recipes/mealie/releases/tag/v3.0.0))
+- `mealie` has been updated to 3.0.2: This update introduces breaking changes in some API endpoints (see the [release changelog](https://github.com/mealie-recipes/mealie/releases/tag/v3.0.0)).
 
 ### Breaking changes {#sec-nixpkgs-release-25.11-lib-breaking}
 

doc/stdenv/cross-compilation.chapter.md

···
 
 Nixpkgs follows the [conventions of GNU autoconf](https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html). We distinguish between 3 types of platforms when building a derivation: _build_, _host_, and _target_. In summary, _build_ is the platform on which a package is being built, _host_ is the platform on which it will run. The third attribute, _target_, is relevant only for certain specific compilers and build tools.
 
-In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:
+In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like this:
 
 ```nix
 {
···
 
 `config`
 
-: This is a 3- or 4- component shorthand for the platform. Examples of this would be `x86_64-unknown-linux-gnu` and `aarch64-apple-darwin14`. This is a standard format called the "LLVM target triple", as they are pioneered by LLVM. In the 4-part form, this corresponds to `[cpu]-[vendor]-[os]-[abi]`. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than `config`!
+: This is a 3- or 4- component shorthand for the platform. Examples of this would be `x86_64-unknown-linux-gnu` and `aarch64-apple-darwin14`. This is a standard format called the "LLVM target triple", as it was pioneered by LLVM. In the 4-part form, this corresponds to `[cpu]-[vendor]-[os]-[abi]`. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than `config`!
 
 `parsed`
 
···
 `cannot find -lc: No such file or directory`
 
 ::: {.note}
-At the time of writing it is assumed the issue only happens on `glibc` because it splits the static libraries in to a different output.
+At the time of writing, it is assumed the issue only happens on `glibc` because it splits the static libraries into a different output.
 
 ::: {.note}
 You may want to look in to using `stdenvAdapters.makeStatic` or `pkgsStatic` or a `isStatic = true` platform.

doc/stdenv/passthru.chapter.md

···
 - They can be run and debugged without rebuilding the package, which is useful if that takes a long time
 - They don't add overhead to each build, as opposed checks added to the [`installCheckPhase`](#ssec-installCheck-phase), such as [`versionCheckHook`](#versioncheckhook).
 
-It is also possible to use `passthru.tests` to test the version with [`testVersion`](#tester-testVersion), but since that is pretty trivial and recommended thing to do, we recommend using [`versionCheckHook`](#versioncheckhook) for that, which has the following advantages over `passthru.tests`:
+It is also possible to use `passthru.tests` to test the version with [`testVersion`](#tester-testVersion), but since that is a pretty trivial and recommended thing to do, we recommend using [`versionCheckHook`](#versioncheckhook) for that, which has the following advantages over `passthru.tests`:
 
 - If the `versionCheckPhase` (the phase defined by [`versionCheckHook`](#versioncheckhook)) fails, it triggers a failure which can't be ignored if you use the package, or if you find out about it in a [`nixpkgs-review`](https://github.com/Mic92/nixpkgs-review) report.
 - Sometimes packages become silently broken - meaning they fail to launch but their build passes because they don't perform any tests in the `checkPhase`. If you use this tool infrequently, such a silent breakage may rot in your system / profile configuration, and you will not notice the failure until you will want to use this package. Testing such basic functionality ensures you have to deal with the failure when you update your system / profile.
-- When you open a PR, [ofborg](https://github.com/NixOS/ofborg)'s CI _will_ run `passthru.tests` of [packages that are directly changed by your PR (according to your commits' messages)](https://github.com/NixOS/ofborg?tab=readme-ov-file#automatic-building), but if you'd want to use the [`@ofborg build`](https://github.com/NixOS/ofborg?tab=readme-ov-file#build) command for dependent packages, you won't have to specify in addition the `.tests` attribute of the packages you want to build, and no body will be able to avoid these tests.
+- When you open a PR, [ofborg](https://github.com/NixOS/ofborg)'s CI _will_ run `passthru.tests` of [packages that are directly changed by your PR (according to your commits' messages)](https://github.com/NixOS/ofborg?tab=readme-ov-file#automatic-building), but if you'd want to use the [`@ofborg build`](https://github.com/NixOS/ofborg?tab=readme-ov-file#build) command for dependent packages, you won't have to specify in addition the `.tests` attribute of the packages you want to build, and nobody will be able to avoid these tests.
 
 <!-- NOTE(@fricklerhandwerk): one may argue whether that testing guide should rather be in the user's manual -->
 For more on how to write and run package tests for Nixpkgs, see the [testing section in the package contributor guide](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests).

doc/stdenv/stdenv.chapter.md

···
 | `host --> target`   | `buildInputs`       | `0, 1`   | libraries                                     |
 | `target --> target` | `depsTargetTarget`  | `1, 1`   | stdlibs to run on target                      |
 
-Algorithmically, we traverse propagated inputs, accumulating every propagated dependency’s propagated dependencies and adjusting them to account for the “shift in perspective” described by the current dependency’s platform offsets. This results is sort of a transitive closure of the dependency relation, with the offsets being approximately summed when two dependency links are combined. We also prune transitive dependencies whose combined offsets go out-of-bounds, which can be viewed as a filter over that transitive closure removing dependencies that are blatantly absurd.
+Algorithmically, we traverse propagated inputs, accumulating every propagated dependency’s propagated dependencies and adjusting them to account for the “shift in perspective” described by the current dependency’s platform offsets. This results in a sort of transitive closure of the dependency relation, with the offsets being approximately summed when two dependency links are combined. We also prune transitive dependencies whose combined offsets go out-of-bounds, which can be viewed as a filter over that transitive closure removing dependencies that are blatantly absurd.
 
 We can define the process precisely with [Natural Deduction](https://en.wikipedia.org/wiki/Natural_deduction) using the inference rules below. This probably seems a bit obtuse, but so is the bash code that actually implements it! [^footnote-stdenv-find-inputs-location] They’re confusing in very different ways so… hopefully if something doesn’t make sense in one presentation, it will in the other!
 
···
 
 ##### `nativeBuildInputs` {#var-stdenv-nativeBuildInputs}
 
-A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s host platform. These are programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild` or `depsBuildTarget`. This could be called `depsBuildHost` but `nativeBuildInputs` is used for historical continuity.
+A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s host platform. These are programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild` or `depsBuildTarget`. This could be called `depsBuildHost`, but `nativeBuildInputs` is used for historical continuity.
 
 Since these packages are able to be run at build-time, they are added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
···
 
 ##### `dontAddStaticConfigureFlags` {#var-stdenv-dontAddStaticConfigureFlags}
 
-By default, when building statically, stdenv will try to add build system appropriate configure flags to try to enable static builds.
+By default, when building statically, `stdenv` will try to add build system appropriate configure flags to try to enable static builds.
 
 If this is undesirable, set this variable to true.
 
···
 
 ### Hardening flags enabled by default {#sec-hardening-flags-enabled-by-default}
 
-The following flags are enabled by default and might require disabling with `hardeningDisable` if the program to package is incompatible.
+The following flags are enabled by default and might require disabling with `hardeningDisable` if the program to be packaged is incompatible.
 
 #### `format` {#format}
 

doc/toolchains/llvm.chapter.md

···
 }
 ```
 
-Note that we set `linker` to `lld`. This is because LLVM has its own linker called "lld". By setting it, we utilize Clang and lld within this new instance of Nixpkgs. There is a shorthand method for building everything with LLVM: `pkgsLLVM`. This is easier to use with `nix-build` (or `nix build`):
+Note that we set `linker` to `lld`. This is because LLVM has its own linker, called "lld". By setting it, we utilize Clang and lld within this new instance of Nixpkgs. There is a shorthand method for building everything with LLVM: `pkgsLLVM`. This is easier to use with `nix-build` (or `nix build`):
 
 ```bash
 nix-build -A pkgsLLVM.hello

doc/using/configuration.chapter.md

···
 
 -   The package's `meta.license` is set to a license which is considered to be unfree.
 
--   The package has known security vulnerabilities but has not or can not be updated for some reason, and a list of issues has been entered in to the package's `meta.knownVulnerabilities`.
+-   The package has known security vulnerabilities but has not or can not be updated for some reason, and a list of issues has been entered into the package's `meta.knownVulnerabilities`.
 
 Each of these criteria can be altered in the Nixpkgs configuration.
 
···
     { allowUnfreePredicate = (pkg: false); }
     ```
 
-    For a more useful example, try the following. This configuration only allows unfree packages named roon-server and visual studio code:
+    For a more useful example, try the following. This configuration only allows unfree packages named roon-server and Visual Studio Code:
 
     ```nix
     {
···
 }
 ```
 
-`pathsToLink` tells Nixpkgs to only link the paths listed which gets rid of the extra stuff in the profile. `/bin` and `/share` are good defaults for a user environment, getting rid of the clutter. If you are running on Nix on MacOS, you may want to add another path as well, `/Applications`, that makes GUI apps available.
+`pathsToLink` tells Nixpkgs to only link the paths listed which gets rid of the extra stuff in the profile. `/bin` and `/share` are good defaults for a user environment, getting rid of the clutter. If you are running on Nix on macOS, you may want to add another path as well, `/Applications`, that makes GUI apps available.
 
 ### Getting documentation {#sec-getting-documentation}
 

doc/using/overrides.chapter.md

···
 
 ## <pkg>.overrideAttrs {#sec-pkg-overrideAttrs}
 
-The function `overrideAttrs` allows overriding the attribute set passed to a `stdenv.mkDerivation` call, producing a new derivation based on the original one. This function is available on all derivations produced by the `stdenv.mkDerivation` function, which is most packages in the nixpkgs expression `pkgs`.
+The function `overrideAttrs` allows overriding the attribute set passed to a `stdenv.mkDerivation` call, producing a new derivation based on the original one. This function is available on all derivations produced by the `stdenv.mkDerivation` function, which is most packages in the Nixpkgs expression `pkgs`.
 
 Example usages:
 
···
 Do not use this function in Nixpkgs as it evaluates a derivation before modifying it, which breaks package abstraction. In addition, this evaluation-per-function application incurs a performance penalty, which can become a problem if many overrides are used. It is only intended for ad-hoc customisation, such as in `~/.config/nixpkgs/config.nix`.
 :::
 
-The function `overrideDerivation` creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the `makeOverridable` function. Most standard derivation-producing functions, such as `stdenv.mkDerivation`, are defined using this function, which means most packages in the nixpkgs expression, `pkgs`, have this function.
+The function `overrideDerivation` creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the `makeOverridable` function. Most standard derivation-producing functions, such as `stdenv.mkDerivation`, are defined using this function, which means most packages in the Nixpkgs expression, `pkgs`, have this function.
 
 Example usage:
 

nixos/doc/manual/configuration/declarative-packages.section.md

···
 
 Note: the `nixos` prefix tells us that we want to get the package from
 the `nixos` channel and works only in CLI tools. In declarative
-configuration use `pkgs` prefix (variable).
+configuration, use `pkgs` prefix (variable).
 
 To "uninstall" a package, remove it from
 [](#opt-environment.systemPackages) and run `nixos-rebuild switch`.

nixos/doc/manual/configuration/kubernetes.chapter.md

···
 ::: {.note}
 It is mandatory to configure:
 [](#opt-services.kubernetes.masterAddress).
-The masterAddress must be resolveable and routeable by all cluster nodes.
+The masterAddress must be resolvable and routable by all cluster nodes.
 In single node clusters, this can be set to `localhost`.
 :::
 

nixos/doc/manual/configuration/profiles.chapter.md

···
 Even if some of these profiles seem only useful in the context of
 install media, many are actually intended to be used in real installs.
 
-What follows is a brief explanation on the purpose and use-case for each
+What follows is a brief explanation of the purpose and use-case for each
 profile. Detailing each option configured by each one is out of scope.
 
 ```{=include=} sections

pkgs/README.md

···
 ### New packages
 
 New packages are a common type of pull requests.
-These pull requests consists in adding a new nix-expression for a package.
+These pull requests consist in adding a new nix-expression for a package.
 
 Review process:
 
···
   - Maintainers must be set.
     This can be the package submitter or a community member that accepts taking up maintainership of the package.
   - The `meta.mainProgram` must be set if a main executable exists.
-- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
+- Ensure any special packaging choices and required context are documented in, i.e., the name of a patch or in a comment.
   - If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
   - If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
   - If any non-default build flags are set, document why.
···
 
 [github.com/NixOS/nixpkgs/issues?q=is:issue+is:open+"Vulnerability+roundup"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+%22Vulnerability+roundup%22)
 
-Each issue correspond to a vulnerable version of a package; As a consequence:
+Each issue corresponds to a vulnerable version of a package; as a consequence:
 
 - One issue can contain several CVEs;
 - One CVE can be shared across several issues;

pkgs/applications/networking/browsers/chromium/README.md

···
   - `ungoogled-chromium`: A patch set for Chromium, that has its own entry in Chromium's `upstream-info.nix`.
   - `chromedriver`: Updated via Chromium's `upstream-info.nix` and not built
     from source. Must match Chromium's major version.
-  - `electron-source`: Various version of electron that are built from source using Chromium's
+  - `electron-source`: Various versions of electron that are built from source using Chromium's
     `-unwrapped` derivation, due to electron being based on Chromium.
 
 # Upstream links

pkgs/applications/networking/cluster/k3s/README.md

···
 # K3s
 
-K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version that bundles  Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices.
+K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version that bundles Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices.
 
 ## Usage
 

pkgs/applications/networking/cluster/rke2/README.md

···
 Nixpkgs follows active minor version release channels (typically 4 at a time) and sets aliases for
 `rke2_stable` and `rke2_latest` accordingly.
 
-Patch releases should be backported to to the latest stable release branch, however, new minor
+Patch releases should be backported to the latest stable release branch; however, new minor
 versions are not backported.
 
 For further information visit the

pkgs/build-support/go/README.md

···
 
     When an end-of-life toolchain is removed, builders that pin the EOL version (according to 3.) will automatically be bumped to the then oldest pinned builder (e.g. Go 1.22 is EOL, `buildGo122Module` is bumped to `buildGo123Module`).
 
-    If the package won't build with anymore with that builder, the package is marked broken.
+    If the package won't build with that builder anymore, the package is marked broken.
     It is the package maintainers responsibility to fix the package and get it working with a supported Go toolchain.
 
 [1]: http://go.dev/doc/go1compat

pkgs/by-name/README.md

···
 
 ## Limitations
 
-There's some limitations as to which packages can be defined using this structure:
+There are some limitations as to which packages can be defined using this structure:
 
 - Only packages defined using `pkgs.callPackage`.
   This excludes packages defined using `pkgs.python3Packages.callPackage ...`.

pkgs/by-name/az/azure-cli/README.md

···
 
 Check if the desired functionality was added.
 
-You can check if the extensions was recognized by running:
+You can check if the extensions were recognized by running:
 
 ```sh
 ./result/bin/az extension list

pkgs/by-name/fr/freecad/README.md

···
 This package supports the following parameters:
 
 - withWayland (default: true): when false, set QT_QPA_PLATFORM to xcb
-- spaceNavSupport (enabled by default on linux): whether to enable
+- spaceNavSupport (enabled by default on Linux): whether to enable
   [spacenavd support](https://spacenav.sourceforge.net/)
 - ifcSupport (default: false): whether to enable ifc support through
   ifcopenshell

pkgs/by-name/ka/kanidm/README.md

···
 
 ## Remove release
 
-Kanidm versions are supported for 30 days after the release of new versions. Following the example above, 1.5.x superseding 1.4.x in 30 days, do the following near the end of the 30 day window
+Kanidm versions are supported for 30 days after the release of new versions. Following the example above, 1.5.x superseding 1.4.x in 30 days, do the following near the end of the 30-day window
 
 1. Update `pkgs/by-name/ka/kanidm/1_4.nix` by adding `unsupported = true;`
 1. Update `pkgs/top-level/release.nix` and add `kanidm_1_4-1.4.6` and `kanidmWithSecretProvisioning_1_4-1.4.6` to `permittedInsecurePackages`

pkgs/by-name/ni/nixos-rebuild-ng/README.md

···
 
 The current state of `nixos-rebuild` is dire: it is one of the most critical
 pieces of code we have in NixOS, but it has tons of issues:
-- The code is written in Bash, and while this by itself is not necessary bad,
+- The code is written in Bash, and while this by itself is not necessarily bad,
   it means that it is difficult to do refactorings due to the lack of tooling
   for the language
 - The code itself is a hacky mess. Changing even one line of code can cause
···
   builds Flakes inside a temporary directory and reads the resulting symlink
   since the code seems to predate `--print-out-paths` flag
 
-Given all of those above, improvements in the `nixos-rebuild` are difficult to
+Given all of the above, improvements in the `nixos-rebuild` are difficult to
 do. A full rewrite is probably the easier way to improve the situation since
 this can be done in a separate package that will not break anyone. So this is
 an attempt of the rewrite.
···
 ```
 
 The command above will build, run the unit tests and linters, and also check if
-the code is formatted. However, sometimes is more convenient to run just a few
+the code is formatted. However, sometimes it's more convenient to run just a few
 tests to debug, in this case you can run:
 
 ```console
···
   please open an issue
 - We do some additional validation of flags, like exiting with an error when
   `--build-host` or `--target-host` is used with `repl`, since the user could
-  assume that the `repl` would be run remotely while it always run the local
+  assume that the `repl` would be run remotely while it always runs the local
   machine. `nixos-rebuild` silently ignored those flags, so this
   [may cause some issues](https://github.com/NixOS/nixpkgs/pull/363922) for
   wrappers
···
   may be difficult to fix, so right now I only recommend using
   `nixos-rebuild-ng` if you are testing in a VM or in a filesystem with
   snapshots like BTRFS or ZFS. Those bugs are unlikely to be unfixable but the
-  errors can be difficult to understand. If you want to go anyway,
+  errors can be difficult to understand. If you want to go on,
   `nix-collect-garbage -d` and `nix store repair` are your friends
 
 ## TODON'T

pkgs/by-name/ni/nixos-render-docs/README.md

···
     - It would also require keeping an impure or otherwise continuously updated reference to those other revisions.
     - The static mapping acts like a semi-automatically updated cache that we drag along with version history.
     - Other setups, such as a dedicated service to cache a history of moved content, are more complicated and would still be impure.
-- Checking in large amounts of data that is touched often, bears a risk of more merge conflicts or related build failures.
+- Checking in large amounts of data that is touched often bears a risk of more merge conflicts or related build failures.
 
 The solution picked here is to have a static mapping of the historical locations checked into the Git tree, such that it can be read during the build process.
 This also ensures that an improper redirect mapping will cause `nixos-render-docs` to fail the build and thus enforce that redirects stay up-to-date with every commit.

pkgs/by-name/sw/switch-to-configuration-ng/README.md

···
 # switch-to-configuration-ng
 
-This program implements the switching/updating of NixOS systems. It starts with the exising running configuration at `/run/current-system` and handles the migration to a new configuration, built from a NixOS configuration's `config.system.build.toplevel` derivation.
+This program implements the switching/updating of NixOS systems. It starts with the existing running configuration at `/run/current-system` and handles the migration to a new configuration, built from a NixOS configuration's `config.system.build.toplevel` derivation.
 
 For more information on what happens during a switch, see [what-happens-during-a-system-switch](../../../../nixos/doc/manual/development/what-happens-during-a-system-switch.chapter.md).
 

pkgs/development/compilers/elm/README.md

···
 (versions.dat).
 
 The makeDotElm function lets us retrieve these dependencies in the
-standard nix way. we have to copy them in (rather than symlink) and
+standard nix way. We have to copy them in (rather than symlink) and
 make them writable because the elm compiler writes other .dat files
 alongside the source code. versions.dat was produced during an
 impure build of this same code; the build complains that it can't

pkgs/development/compilers/julia/README.md

···
 [julia]: https://julialang.org
 
 For Nixpkgs, the manual is as always your primary reference, and for the Julia
-side of things you probably want to familiarise yourself with the [README
+side of things, you probably want to familiarise yourself with the [README
 ][readme], [build instructions][build], and [release process][release_process].
 Remember that these can change between Julia releases, especially if the LTS and
 release branches have deviated greatly. A lot of the build process is

pkgs/development/compilers/llvm/README.md

···
 
 - Run `update-git.py`.
   This will set the github revision and sha256 for `llvmPackages_git.llvm` to whatever the latest chromium build is using.
-  For a more recent, commit run `nix-prefetch-github` and change the rev and sha256 accordingly.
+  For a more recent commit, run `nix-prefetch-github` and change the rev and sha256 accordingly.
 
 - That was the easy part.
   The hard part is updating the patch files.
···
     which can be an easily missed reason for failures.
     For cases where the hunk is no longer needed you can simply remove it from the patch.
 
- This is fine for small corrections, but when more serious changes are needed its better to use git.
+ This is fine for small corrections, but when more serious changes are needed, it's better to use git.
 
  1. Clone the LLVM monorepo at https://github.com/llvm/llvm-project/
 
···
 
 Use CMake's [`GNUInstallDirs`](https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html) to support multiple outputs.
 
-Previously, LLVM Just hard-coded `bin`, `include`, and `lib${LLVM_TARGET_PREFIX}`.
+Previously, LLVM just hard-coded `bin`, `include`, and `lib${LLVM_TARGET_PREFIX}`.
 We are making it use these variables.
 
 For the older LLVM versions, these patches live in https://github.com/Ericson2314/llvm-project branches `split-prefix`.

pkgs/development/cuda-modules/README.md

···
-# Cuda modules
+# CUDA Modules
 
 > [!NOTE]
 > This document is meant to help CUDA maintainers understand the structure of
···
 
 ## Distinguished packages
 
-### Cuda compatibility
+### CUDA Compatibility
 
-[Cuda Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/),
+[CUDA Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/),
 available as `cudaPackages.cuda_compat`, is a component which makes it possible
 to run applications built against a newer CUDA toolkit (for example CUDA 12) on
 a machine with an older CUDA driver (for example CUDA 11), which isn't possible
-out of the box. At the time of writing, Cuda Compatibility is only available on
+out of the box. At the time of writing, CUDA Compatibility is only available on
 the Nvidia Jetson architecture, but Nvidia might release support for more
 architectures in the future.
 
-As Cuda Compatibility strictly increases the range of supported applications, we
+As CUDA Compatibility strictly increases the range of supported applications, we
 try our best to enable it by default on supported platforms.
 
 #### Functioning
···
 `cuda_compat` isn't a complete drop-in replacement for the driver (and that's
 the point, otherwise, it would just be a newer driver).
 
-Nvidia's recommendation is to set `LD_LIBRARY_PATH` to points to `cuda_compat`'s
+Nvidia's recommendation is to set `LD_LIBRARY_PATH` to point to `cuda_compat`'s
 driver. This is fine for a manual, one-shot usage, but in general setting
 `LD_LIBRARY_PATH` is a red flag. This is global state which short-circuits most
-of other dynamic libraries resolution mechanisms and can break things in
+of other dynamic library resolution mechanisms and can break things in
 non-obvious ways, especially with other Nix-built software.
 
-#### Cuda compat with Nix
+#### CUDA Compat with Nix
 
 Since `cuda_compat` is a known derivation, the easy way to do this in Nix would
 be to add `cuda_compat` as a dependency of CUDA libraries and applications and
-let Nix does its magic by filling the `DT_RUNPATH` fields. However,
+let Nix do its magic by filling the `DT_RUNPATH` fields. However,
 `cuda_compat` itself depends on `libnvrm_mem` and `libnvrm_gpu` which are loaded
 dynamically at runtime from `/run/opengl-driver`. This doesn't please the Nix
 sandbox when building, which can't find those (a second minor issue is that

pkgs/development/mobile/androidenv/README.md

···
 
 # How to run tests
 
-You may need to make yourself familiar with [package tests](../../../README.md#package-tests), and [Writing larger package tests](../../../README.md#writing-larger-package-tests), then run tests locally with:
+You may need to make yourself familiar with [package tests](../../../README.md#package-tests) and [Writing larger package tests](../../../README.md#writing-larger-package-tests), then run tests locally with:
 
 ```shell
 $ export NIXPKGS_ALLOW_UNFREE=1

pkgs/development/tools/build-managers/gradle/README.md

···
 ## Introduction
 
 Gradle build scripts are written in a DSL, computing the list of Gradle
-dependencies is a turing-complete task, not just in theory but in
+dependencies is a Turing-complete task, not just in theory but also in
 practice. Fetching all of the dependencies often requires building some
 native code, running some commands to check the host platform, or just
 fetching some files using either JVM code or commands like `curl` or
···
 Obviously, this is horrible for reproducibility. Additionally, Gradle
 doesn't offer a way to export the list of dependency URLs and hashes (it
 does in a way, but it's far from being complete, and as such is useless
-for nixpkgs). Even if did, it would be annoying to use considering
+for Nixpkgs). Even if it did, it would be annoying to use considering
 fetching non-Gradle dependencies in Gradle scripts is commonplace.
 
 That's why the setup hook uses mitm-cache, a program designed for
···
 and finally download `b.jar.sha1`, locate it in its cache, and then
 *not* download `b.jar`. This means `b.jar` won't be stored in the MITM
 cache. Then, consider that on a later invocation, the fetching order
-changed, whether it was because of a running on different system,
+changed, whether it was because of running on a different system,
 changed behavior after a Gradle update, or any other source of
 nondeterminism - `b.jar` is fetched before `a.jar`. Gradle will first
 fetch `b.jar.sha1`, not find it in its cache, attempt to fetch `b.jar`,
···
 via CLI arguments.
 
 **Caveat**: Gradle .module files also contain file hashes, in md5, sha1,
-sha256, sha512 formats. It posed no problem as of yet, but it might in
+sha256, sha512 formats. It has posed no problem as of yet, but it might in
 the future. If it does pose problems, the deps derivation code can be
 extended to find all checksums in .module files and copy existing files
 there if their hash matches.
···
 The mitm-cache lockfile format is described in the [mitm-cache
 README](https://github.com/chayleaf/mitm-cache#readme).
 
-The nixpkgs Gradle lockfile format is more complicated:
+The Nixpkgs Gradle lockfile format is more complicated:
 
 ```json
 {
-  "!comment": "This is a nixpkgs Gradle dependency lockfile. For more details, refer to the Gradle section in the nixpkgs manual.",
+  "!comment": "This is a Nixpkgs Gradle dependency lockfile. For more details, refer to the Gradle section in the Nixpkgs manual.",
   "!version": 1,
   "https://oss.sonatype.org/content/repositories/snapshots/com/badlogicgames/gdx-controllers": {
     "gdx-controllers#gdx-controllers-core/2.2.4-20231021.200112-6/SNAPSHOT": {
···
   discern where the repo base ends and the group ID begins).
 
 `compress-deps-json.py` converts the JSON from mitm-cache format into
-nixpkgs Gradle lockfile format. `fetch.nix` does the opposite.
+Nixpkgs Gradle lockfile format. `fetch.nix` does the opposite.
 
 ## Security Considerations
 
···
   doesn't match)
 
 Please be mindful of the above when working on Gradle support for
-nixpkgs.
+Nixpkgs.

pkgs/stdenv/darwin/README.md

···
 There are effectively two steps when updating the standard environment:
 
 1. Update the definition of llvmPackages in `all-packages.nix` for Darwin to match the value of
-   llvmPackages.latest in `all-packages.nix`. Timing-wise, this done currently using the spring
+   llvmPackages.latest in `all-packages.nix`. Timing-wise, this is done currently using the spring
    release of LLVM and once llvmPackages.latest has been updated to match. If the LLVM project
    has announced a release schedule of patch updates, wait until those are in nixpkgs. Otherwise,
    the LLVM updates will have to go through staging instead of being merged into master; and

pkgs/tools/package-management/nix/README.md

···
 
 If you're updating `nixVersions.stable`, follow all the steps mentioned above, but use the **staging** branch for your pull request (or **staging-next** after coordinating with the people in matrix `#staging:nixos.org`)
 This is necessary because, at the end of the staging-next cycle, the NixOS tests are built through the [staging-next-small](https://hydra.nixos.org/jobset/nixos/staging-next-small) jobset.
-Especially nixos installer test are important to look at here.
+Especially NixOS installer tests are important to look at here.
 
 There is a script to update minor versions:
 

pkgs/tools/package-management/nix/modular/README.md

···
 
 ### `workDir` attribute
 
-The Nixpkgs for Nix does inherit the `workDir` attribute that determines the location of the subproject to build.
+The Nixpkgs for Nix inherits the `workDir` attribute that determines the location of the subproject to build.
 It is compared to this directory to produce the correct relative path, similar to upstream.