doc/treewide: replace "in order to" with "to"

Fixes a styleguide violation (doc/styleguide.md, "Filler Words and
Weak Phrases"). Release notes excluded.

doc/README.md

@@ -36,7 +36,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
 
 ### Development environment
 
-In order to reduce repetition, consider using tools from the provided development environment:
+To reduce repetition, consider using tools from the provided development environment:
 
 Load it from the Nixpkgs documentation directory with
 

doc/languages-frameworks/beam.section.md

@@ -236,7 +236,7 @@ Setup will require the following steps:
 
 #### Example of creating a service for an Elixir - Phoenix project {#example-of-creating-a-service-for-an-elixir---phoenix-project}
 
-In order to create a service with your release, you could add a `service.nix`
+To create a service with your release, you could add a `service.nix`
 in your project with the following
 
 ```nix

doc/languages-frameworks/haskell.section.md

@@ -679,7 +679,7 @@ Defaults to `false`.
 
 `genericBuilderArgsModifier`
 : This argument accepts a function allowing you to modify the arguments passed
-to `mkDerivation` in order to create the development environment. For example,
+to `mkDerivation` to create the development environment. For example,
 `args: { doCheck = false; }` would cause the environment to not include any test
 dependencies. Defaults to `lib.id`.
 

doc/languages-frameworks/maven.section.md

@@ -288,7 +288,7 @@ The double invocation is a _simple_ way to get around the problem that `nix-buil
 
 It treats the entire Maven repository as a single source to be downloaded, relying on Maven's dependency resolution to satisfy the output hash. This is similar to fetchers like `fetchgit`, except it has to run a Maven build to determine what to download.
 
-The first step will be to build the Maven project as a fixed-output derivation in order to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
+The first step will be to build the Maven project as a fixed-output derivation to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
 
 ::: {.note}
 Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
@@ -416,7 +416,7 @@ The previous example builds a `jar` file but that's not a file one can run.
 
 You need to use it with `java -jar $out/share/java/output.jar` and make sure to provide the required dependencies on the classpath.
 
-The following explains how to use `makeWrapper` in order to make the derivation produce an executable that will run the JAR file you created.
+The following explains how to use `makeWrapper` to make the derivation produce an executable that will run the JAR file you created.
 
 We will use the same repository we built above (either _double invocation_ or _buildMaven_) to setup a CLASSPATH for our JAR.
 

doc/languages-frameworks/neovim.section.md

@@ -136,7 +136,7 @@ For example, if upstream documents that a plugin uses the Vim license but GitHub
 
 ## LuaRocks based plugins {#neovim-luarocks-based-plugins}
 
-In order to automatically handle plugin dependencies, several Neovim plugins
+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
 packages](#packaging-a-library-on-luarocks), and converted via `buildNeovimPlugin` in

doc/languages-frameworks/python.section.md

@@ -1640,7 +1640,7 @@ looked at how you can create environments in which specified packages are
 available.
 
 At some point you'll likely have multiple packages which you would
-like to be able to use in different projects. In order to minimise unnecessary
+like to be able to use in different projects. To minimise unnecessary
 duplication we now look at how you can maintain a repository with your
 own packages. The important functions here are `import` and `callPackage`.
 
@@ -1892,7 +1892,7 @@ pkgs.mkShell rec {
     pythonPackages.numpy
     pythonPackages.requests
 
-    # In this particular example, in order to compile any binary extensions they may
+    # In this particular example, to compile any binary extensions they may
     # require, the Python modules listed in the hypothetical requirements.txt need
     # the following packages to be installed locally:
     taglib
@@ -2132,7 +2132,7 @@ See also [contributing section](#contributing).
 ### Are Python interpreters built deterministically? {#deterministic-builds}
 
 The Python interpreters are now built deterministically. Minor modifications had
-to be made to the interpreters in order to generate deterministic bytecode. This
+to be made to the interpreters to generate deterministic bytecode. This
 has security implications and is relevant for those using Python in a
 `nix-shell`.
 

doc/languages-frameworks/rocq.section.md

@@ -51,7 +51,7 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
   * if it is a string of the form `owner:branch` then it tries to download the `branch` of owner `owner` for a project of the same name using the same vcs, and the `version` attribute of the resulting derivation is set to `"dev"`, additionally if the owner is not provided (i.e. if the `owner:` prefix is missing), it defaults to the original owner of the package (see below),
   * if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
 * `defaultVersion` (optional). Rocq libraries may be compatible with some specific versions of Rocq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `rocq-core` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `rocqPackages` attribute set.
-* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `hash` attribute (you may put the empty string `""` in order to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
+* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `hash` attribute (you may put the empty string `""` to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
 * `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `hash` and returns an attribute set with a `version` and `src`.
 * `repo` (optional, defaults to the value of `pname`),
 * `owner` (optional, defaults to `"rocq-community"`).
@@ -153,7 +153,7 @@ For example, assuming you have a special `mathcomp` dependency you want to use,
 multinomials.override { mathcomp = my-special-mathcomp; }
 ```
 
-In Nixpkgs, all Rocq derivations take a `version` argument.  This can be overridden in order to easily use a different version:
+In Nixpkgs, all Rocq derivations take a `version` argument.  This can be overridden to easily use a different version:
 
 ```nix
 rocqPackages.multinomials.override { version = "1.5.1"; }

doc/languages-frameworks/ruby.section.md

@@ -125,7 +125,7 @@ With this file in your directory, you can run `nix-shell` to build and use the g
 
 The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
 
-One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
+One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So to give the `bundler` from your gemset priority, it would be used like this:
 
 ```nix
 # ...
@@ -265,7 +265,7 @@ Now that you know how to get a working Ruby environment with Nix, it's time to g
 
 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`.
+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`.
 
 To test that it works, you can then try using the gem with:
 

doc/languages-frameworks/swift.section.md

@@ -160,7 +160,7 @@ This essentially runs: `swift test -c release`
 
 In some cases, it may be necessary to patch a SwiftPM dependency. SwiftPM
 dependencies are located in `.build/checkouts`, but the `swiftpm2nix` helper
-provides these as symlinks to read-only `/nix/store` paths. In order to patch
+provides these as symlinks to read-only `/nix/store` paths. To patch
 them, we need to make them writable.
 
 A special function `swiftpmMakeMutable` is available to replace the symlink

doc/languages-frameworks/vim.section.md

@@ -153,7 +153,7 @@ Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plu
 
 When the vim updater detects an nvim-treesitter update, it also runs [`nvim-treesitter/update.py $(nix-build -A vimPlugins.nvim-treesitter)`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/utils/update.py) to update the tree sitter grammars for `nvim-treesitter`.
 
-Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
+Some plugins require overrides to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
 
 ```nix
 {

doc/packages/citrix.section.md

@@ -10,7 +10,7 @@ The tarball archive needs to be downloaded manually, as the license agreements o
 
 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:
+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:
 
 ```ShellSession
 $ storebrowse -C ~/Downloads/receiverconfig.cr
@@ -19,7 +19,7 @@ $ selfservice
 
 ## 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`. 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/urxvt.section.md

@@ -22,7 +22,7 @@ rxvt-unicode.override {
 
 If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically.
 
-In order to add plugins but also keep all default plugins installed, it is possible to use the following method:
+To add plugins but also keep all default plugins installed, it is possible to use the following method:
 
 ```nix
 rxvt-unicode.override {

doc/packages/weechat.section.md

@@ -39,7 +39,7 @@ weechat.override {
 }
 ```
 
-In order to also keep all default plugins installed, it is possible to use the following method:
+To also keep all default plugins installed, it is possible to use the following method:
 
 ```nix
 weechat.override {

doc/stdenv/stdenv.chapter.md

@@ -776,7 +776,7 @@ By default, the flag `--disable-dependency-tracking` is added to the configure f
 
 ##### `dontFixLibtool` {#var-stdenv-dontFixLibtool}
 
-By default, the configure phase applies some special hackery to all files called `ltmain.sh` before running the configure script in order to improve the purity of Libtool-based packages [^footnote-stdenv-sys-lib-search-path] . If this is undesirable, set this variable to true.
+By default, the configure phase applies some special hackery to all files called `ltmain.sh` before running the configure script to improve the purity of Libtool-based packages [^footnote-stdenv-sys-lib-search-path] . If this is undesirable, set this variable to true.
 
 ##### `dontDisableStatic` {#var-stdenv-dontDisableStatic}
 
@@ -939,7 +939,7 @@ The fixup phase performs (Nix-specific) post-processing actions on the files ins
 
 - It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`.
 - It strips libraries and executables of debug information.
-- On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies.
+- On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` to prevent unnecessary runtime dependencies.
 - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details.
 
 #### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}
@@ -1345,7 +1345,7 @@ $ echo $configureFlags
 
 Nix itself considers a build-time dependency as merely something that should previously be built and accessible at build time—packages themselves are on their own to perform any additional setup. In most cases, that is fine, and the downstream derivation can deal with its own dependencies. But for a few common tasks, that would result in almost every package doing the same sort of setup work—depending not on the package itself, but entirely on which dependencies were used.
 
-In order to alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
+To alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
 
 The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.