diff --git a/doc/build-helpers/images/appimagetools.section.md b/doc/build-helpers/images/appimagetools.section.md index ec34ce36265d..c4ba31fcdc3d 100644 --- a/doc/build-helpers/images/appimagetools.section.md +++ b/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} diff --git a/doc/build-helpers/images/dockertools.section.md b/doc/build-helpers/images/dockertools.section.md index 5fcfb5964a80..2b3267024c7d 100644 --- a/doc/build-helpers/images/dockertools.section.md +++ b/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} diff --git a/doc/build-helpers/special/fhs-environments.section.md b/doc/build-helpers/special/fhs-environments.section.md index 9a015f241453..cb767458e6ba 100644 --- a/doc/build-helpers/special/fhs-environments.section.md +++ b/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: diff --git a/doc/build-helpers/special/vm-tools.section.md b/doc/build-helpers/special/vm-tools.section.md index 47f048e3c842..50d21b228ae0 100644 --- a/doc/build-helpers/special/vm-tools.section.md +++ b/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} diff --git a/doc/languages-frameworks/cuda.section.md b/doc/languages-frameworks/cuda.section.md index 01b70402cf48..3b2d77ff192b 100644 --- a/doc/languages-frameworks/cuda.section.md +++ b/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. diff --git a/doc/languages-frameworks/factor.section.md b/doc/languages-frameworks/factor.section.md index 9e081934c90f..07627c3cad9f 100644 --- a/doc/languages-frameworks/factor.section.md +++ b/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_) diff --git a/doc/languages-frameworks/gradle.section.md b/doc/languages-frameworks/gradle.section.md index 8f3659d3dd6d..91c42d8f4e01 100644 --- a/doc/languages-frameworks/gradle.section.md +++ b/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 diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md index 9af8fe72b0e5..109a9dd39e78 100644 --- a/doc/languages-frameworks/haskell.section.md +++ b/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 diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md index 25407a074a3c..80234f05d4e6 100644 --- a/doc/languages-frameworks/ruby.section.md +++ b/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: diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md index f6d798ff6cee..dcf3aab4f037 100644 --- a/doc/languages-frameworks/rust.section.md +++ b/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. diff --git a/doc/packages/emacs.section.md b/doc/packages/emacs.section.md index 1cb728469f66..5486f2cc8944 100644 --- a/doc/packages/emacs.section.md +++ b/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 { diff --git a/doc/packages/python-tree-sitter.section.md b/doc/packages/python-tree-sitter.section.md index bd00d77cf7c2..0e6b3589e078 100644 --- a/doc/packages/python-tree-sitter.section.md +++ b/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. diff --git a/doc/using/configuration.chapter.md b/doc/using/configuration.chapter.md index 7317b5b198fd..262fd04e4a22 100644 --- a/doc/using/configuration.chapter.md +++ b/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: