From 66241985dcf268ef8e2fd020d73b86c4d1b03d15 Mon Sep 17 00:00:00 2001 From: Johannes Kirschbauer Date: Sun, 24 May 2026 14:40:47 +0200 Subject: [PATCH] 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 | 2 +- doc/languages-frameworks/beam.section.md | 2 +- doc/languages-frameworks/haskell.section.md | 2 +- doc/languages-frameworks/maven.section.md | 4 ++-- doc/languages-frameworks/neovim.section.md | 2 +- doc/languages-frameworks/python.section.md | 6 +++--- doc/languages-frameworks/rocq.section.md | 4 ++-- doc/languages-frameworks/ruby.section.md | 4 ++-- doc/languages-frameworks/swift.section.md | 2 +- doc/languages-frameworks/vim.section.md | 2 +- doc/packages/citrix.section.md | 4 ++-- doc/packages/urxvt.section.md | 2 +- doc/packages/weechat.section.md | 2 +- doc/stdenv/stdenv.chapter.md | 6 +++--- 14 files changed, 22 insertions(+), 22 deletions(-) diff --git a/doc/README.md b/doc/README.md index abb07f6ff3dd..c92fa3658a3a 100644 --- a/doc/README.md +++ b/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 diff --git a/doc/languages-frameworks/beam.section.md b/doc/languages-frameworks/beam.section.md index 7b643efa30d8..4452e1fa4c2a 100644 --- a/doc/languages-frameworks/beam.section.md +++ b/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 diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md index f81c1b77d84e..9af8fe72b0e5 100644 --- a/doc/languages-frameworks/haskell.section.md +++ b/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`. diff --git a/doc/languages-frameworks/maven.section.md b/doc/languages-frameworks/maven.section.md index daae60efc3e8..a6e5f42edfea 100644 --- a/doc/languages-frameworks/maven.section.md +++ b/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. diff --git a/doc/languages-frameworks/neovim.section.md b/doc/languages-frameworks/neovim.section.md index 6296a0389ec2..73c4a97ffebd 100644 --- a/doc/languages-frameworks/neovim.section.md +++ b/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 diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md index da76fb682b39..656b933b5373 100644 --- a/doc/languages-frameworks/python.section.md +++ b/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`. diff --git a/doc/languages-frameworks/rocq.section.md b/doc/languages-frameworks/rocq.section.md index af83d1e3790b..f2ba50312807 100644 --- a/doc/languages-frameworks/rocq.section.md +++ b/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"; } diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md index cf2062845426..25407a074a3c 100644 --- a/doc/languages-frameworks/ruby.section.md +++ b/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: diff --git a/doc/languages-frameworks/swift.section.md b/doc/languages-frameworks/swift.section.md index bb4599aa4fc3..76e4962fe9e3 100644 --- a/doc/languages-frameworks/swift.section.md +++ b/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 diff --git a/doc/languages-frameworks/vim.section.md b/doc/languages-frameworks/vim.section.md index 2f3790d38547..91b59e3f0cab 100644 --- a/doc/languages-frameworks/vim.section.md +++ b/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 { diff --git a/doc/packages/citrix.section.md b/doc/packages/citrix.section.md index f8530f4517a0..fe59f083a0b1 100644 --- a/doc/packages/citrix.section.md +++ b/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 { config.allowUnfree = true; }; diff --git a/doc/packages/urxvt.section.md b/doc/packages/urxvt.section.md index 6fc33190b58b..4170e6b0c63e 100644 --- a/doc/packages/urxvt.section.md +++ b/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 { diff --git a/doc/packages/weechat.section.md b/doc/packages/weechat.section.md index b134dc35dc1f..cdc9ccba5a96 100644 --- a/doc/packages/weechat.section.md +++ b/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 { diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md index afcc6cf807c1..d470f69d033d 100644 --- a/doc/stdenv/stdenv.chapter.md +++ b/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.