doc/treewide: drop 'allows you to' filler words (#569871)

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

@@ -41,7 +41,7 @@ appimageTools.wrapType2 {
 
 :::
 
-The argument passed to `wrapType2` can also contain an `extraPkgs` attribute, which allows you to include additional packages inside the FHS environment your AppImage is going to run in.
+The argument passed to `wrapType2` can also contain an `extraPkgs` attribute, which includes additional packages inside the FHS environment your AppImage is going to run in.
 `extraPkgs` must be a function that returns a list of packages.
 There are a few ways to learn which dependencies an application needs:
 
@@ -116,7 +116,7 @@ appimageTools.wrapType2 (finalAttrs: {
 
 `appimageTools` also exposes the `extract` function should you need to do it manually, requiring `pname`, `version`, and `src` arguments (`src` being the AppImage file to extract).
 
-The arguments passed to `extract` can also contain a `postExtract` attribute, which allows you to execute additional commands after the files are extracted from the AppImage.
+The arguments passed to `extract` can also contain a `postExtract` attribute, which executes additional commands after the files are extracted from the AppImage.
 `postExtract` must be a string with commands to run.
 
 :::{.warning}

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

@@ -217,7 +217,7 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
 `buildArgs` (Attribute Set)
 
 : The argument passed to `buildImage` itself.
-  This allows you to inspect all attributes specified in the argument, as described above.
+  This exposes all attributes specified in the argument, as described above.
 
 `layer` (Attribute Set)
 
@@ -228,7 +228,7 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
 
 : The tag of the generated image.
   This is useful if no tag was specified in the attributes of the argument to `buildImage`, because an automatic tag will be used instead.
-  `imageTag` allows you to retrieve the value of the tag used in this case.
+  `imageTag` contains the value of the tag used in this case.
 
 ### Examples {#ssec-pkgs-dockerTools-buildImage-examples}
 
@@ -657,7 +657,7 @@ This allows the function to produce reproducible images.
 
 : The tag of the generated image.
   This is useful if no tag was specified in the attributes of the argument to the function, because an automatic tag will be used instead.
-  `imageTag` allows you to retrieve the value of the tag used in this case.
+  `imageTag` contains the value of the tag used in this case.
 
 ### Examples {#ssec-pkgs-dockerTools-streamLayeredImage-examples}
 

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

@@ -1,6 +1,6 @@
 # buildFHSEnv {#sec-fhs-environments}
 
-`buildFHSEnv` provides a way to build and run an FHS-compatible, lightweight sandbox. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you to run software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance.
+`buildFHSEnv` provides a way to build and run an FHS-compatible, lightweight sandbox. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This runs software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance.
 It uses Linux' namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system.
 
 Accepted arguments are:

doc/build-helpers/special/vm-tools.section.md

@@ -18,7 +18,7 @@ Run a derivation in a Linux virtual machine (using Qemu/KVM).
 By default, there is no disk image; the root filesystem is a `tmpfs`, and the Nix store is shared with the host (via the [9P protocol](https://wiki.qemu.org/Documentation/9p#9p_Protocol)).
 Thus, any pure Nix derivation should run unmodified.
 
-If the build fails and Nix is run with the `-K/--keep-failed` option, a script `run-vm` will be left behind in the temporary build directory that allows you to boot into the VM and debug it interactively.
+If the build fails and Nix is run with the `-K/--keep-failed` option, a script `run-vm` will be left behind in the temporary build directory that boots into the VM for interactive debugging.
 
 ### Attributes {#vm-tools-runInLinuxVM-attributes}
 

doc/languages-frameworks/cuda.section.md

@@ -121,7 +121,7 @@ Overriding the CUDA package set for a package may cause inconsistencies, because
 
 ### Nixpkgs CUDA variants {#cuda-nixpkgs-cuda-variants}
 
-Nixpkgs CUDA variants are provided primarily for the convenience of selecting CUDA-enabled packages by attribute path. As an example, the `pkgsForCudaArch` collection of CUDA Nixpkgs variants allows you to access an instantiation of OpenCV with CUDA support for an Ada Lovelace GPU with the attribute path `pkgsForCudaArch.sm_89.opencv`, without needing to modify the `config` provided when importing Nixpkgs.
+Nixpkgs CUDA variants are provided primarily for the convenience of selecting CUDA-enabled packages by attribute path. As an example, the `pkgsForCudaArch` collection of CUDA Nixpkgs variants exposes an instantiation of OpenCV with CUDA support for an Ada Lovelace GPU at the attribute path `pkgsForCudaArch.sm_89.opencv`, without needing to modify the `config` provided when importing Nixpkgs.
 
 ::: {.caution}
 Nixpkgs variants are not free: they require re-evaluating Nixpkgs. Where possible, import Nixpkgs once, with the desired configuration.

doc/languages-frameworks/factor.section.md

@@ -193,7 +193,7 @@ Additional attributes that are understood by `buildFactorApplication`:
 
   : is the path to the vocabulary to be deployed relative to the source root.
     So, directory `foo/` from the example above could be `extra/deep/down/foo`.
-    This allows you to maintain Factor's vocabulary hierarchy and distribute the same source tree as a stand-alone application and as a library in the Factor development environment via the `extraVocabs` attribute.
+    Use this to maintain Factor's vocabulary hierarchy and distribute the same source tree as a stand-alone application and as a library in the Factor development environment via the `extraVocabs` attribute.
 
   `binName` (String; _optional_)
 

doc/languages-frameworks/gradle.section.md

@@ -92,7 +92,7 @@ stdenv.mkDerivation (finalAttrs: {
 })
 ```
 
-This allows you to `override` any arguments of the `pkg` used for the update script (for example, `pkg = pdftk.override { enableSomeFlag = true };)`.
+Use this to `override` any arguments of the `pkg` used for the update script (for example, `pkg = pdftk.override { enableSomeFlag = true };)`.
 
 The second is to use `finalAttrs.finalPackage` like this:
 
@@ -134,7 +134,7 @@ The update script does the following:
   will generally use instead of `pkg` or `attrPath`.
 - `pkg` - the package to be used for fetching the dependencies. Defaults
   to `getAttrFromPath (splitString "." attrPath) pkgs`.
-- `bwrapFlags` - allows you to override bwrap flags (only relevant for
+- `bwrapFlags` - overrides bwrap flags (only relevant for
   downstream, non-nixpkgs projects)
 - `data` - path to the dependencies lockfile (can be relative to the
   package, can be absolute). In nixpkgs, it's discouraged to have the

doc/languages-frameworks/haskell.section.md

@@ -688,7 +688,7 @@ dependencies. Defaults to `lib.id`.
 Setting it to `true` will cause the development environment to include all
 benchmark dependencies which would be excluded by default. Defaults to `false`.
 
-One neat property of `shellFor` is that it allows you to work on multiple
+One neat property of `shellFor` is that it supports multiple
 packages using the same environment in conjunction with
 [cabal.project files][cabal-project-files].
 Say our example above depends on `distribution-nixpkgs` and we have a project

doc/languages-frameworks/ruby.section.md

@@ -14,7 +14,7 @@ Since not all gems have executables like `nokogiri`, it's usually more convenien
 
 ### Temporary Ruby environment with `nix-shell` {#temporary-ruby-environment-with-nix-shell}
 
-Rather than having a single Ruby environment shared by all Ruby development projects on a system, Nix allows you to create separate environments per project. `nix-shell` gives you the possibility to temporarily load another environment akin to a combined `chruby` or `rvm` and `bundle exec`.
+Rather than having a single Ruby environment shared by all Ruby development projects on a system, Nix creates separate environments per project. `nix-shell` gives you the possibility to temporarily load another environment akin to a combined `chruby` or `rvm` and `bundle exec`.
 
 There are two methods for loading a shell with Ruby packages. The first and recommended method is to create an environment with `ruby.withPackages` and load that.
 
@@ -277,7 +277,7 @@ To check the gems for any security vulnerabilities, run `./maintainers/scripts/a
 
 ### 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, which makes 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:
 

doc/languages-frameworks/rust.section.md

@@ -1013,7 +1013,7 @@ There are two community maintained approaches to Rust toolchain management:
 
 Despite their names, both projects provides a similar set of packages and overlays under different APIs.
 
-Oxalica's overlay allows you to select a particular Rust version without you providing a hash or a flake input,
+Oxalica's overlay selects 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.

doc/packages/emacs.section.md

@@ -2,7 +2,7 @@
 
 ## 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 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:
+The Emacs package comes with some extra helpers to make it easier to configure. `emacs.pkgs.withPackages` manages 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
 {

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

@@ -52,5 +52,5 @@ tree = parser.parse(
 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 programmatically inspect the structure of the code.
+The `tree_sitter_rust.language()` function references the Rust grammar loaded in the Nix shell. Use the resulting tree to inspect the structure of the code programmatically.
 

doc/using/configuration.chapter.md

@@ -119,7 +119,7 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     `allowUnfreePackages` permits the listed unfree packages.
 
-    In NixOS modules, lists set through `nixpkgs.config.allowUnfreePackages` merge additively across modules. This allows you to declare your unfree exceptions in the same modules that triggered them.
+    In NixOS modules, lists set through `nixpkgs.config.allowUnfreePackages` merge additively across modules. Declare your unfree exceptions in the same modules that triggered them.
 
     To allow unfree packages programmatically: