doc: avoid 'simply' (#266434)

While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.

(there are more possible improvements like this, we can apply those in separate
PRs)

10 files changed, 19 insertions, 19 deletions

diff --git a/doc/languages-frameworks/agda.section.md b/doc/languages-frameworks/agda.section.md
index ff3d70ef0c6..cb1f12eec23 100644
--- a/doc/languages-frameworks/agda.section.md
+++ b/doc/languages-frameworks/agda.section.md
@@ -146,7 +146,7 @@ agdaPackages.mkDerivation {
 
 ### Building Agda packages {#building-agda-packages}
 
-The default build phase for `agdaPackages.mkDerivation` simply runs `agda` on the `Everything.agda` file.
+The default build phase for `agdaPackages.mkDerivation` runs `agda` on the `Everything.agda` file.
 If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.
 Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.
 `agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.
@@ -250,7 +250,7 @@ Usually, the maintainers will answer within a week or two with a new release.
 Bumping the version of that reverse dependency should be a further commit on your PR.
 
 In the rare case that a new release is not to be expected within an acceptable time,
-simply mark the broken package as broken by setting `meta.broken = true;`.
+mark the broken package as broken by setting `meta.broken = true;`.
 This will exclude it from the build test.
 It can be added later when it is fixed,
 and does not hinder the advancement of the whole package set in the meantime.
diff --git a/doc/languages-frameworks/beam.section.md b/doc/languages-frameworks/beam.section.md
index 2cb4863fc53..1e83d4b93c7 100644
--- a/doc/languages-frameworks/beam.section.md
+++ b/doc/languages-frameworks/beam.section.md
@@ -44,7 +44,7 @@ There is also a `buildMix` helper, whose behavior is closer to that of `buildErl
 
 ## How to Install BEAM Packages {#how-to-install-beam-packages}
 
-BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.
+BEAM builders are not registered at the top level, because they are not relevant to the vast majority of Nix users.
 To use any of those builders into your environment, refer to them by their attribute path under `beamPackages`, e.g. `beamPackages.rebar3`:
 
 ::: {.example #ex-beam-ephemeral-shell}
diff --git a/doc/languages-frameworks/dart.section.md b/doc/languages-frameworks/dart.section.md
index 8d9c062f422..9da43714a16 100644
--- a/doc/languages-frameworks/dart.section.md
+++ b/doc/languages-frameworks/dart.section.md
@@ -8,7 +8,7 @@ It fetches its Dart dependencies automatically through `fetchDartDeps`, and (thr
 
 If you are packaging a Flutter desktop application, use [`buildFlutterApplication`](#ssec-dart-flutter) instead.
 
-`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, simply set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).
+`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).
 
 If the upstream source is missing a `pubspec.lock` file, you'll have to vendor one and specify it using `pubspecLockFile`. If it is needed, one will be generated for you and printed when attempting to build the derivation.
 
diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md
index 6b9ce32d173..b0b5f5c3bb2 100644
--- a/doc/languages-frameworks/haskell.section.md
+++ b/doc/languages-frameworks/haskell.section.md
@@ -177,7 +177,7 @@ 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 simply take as input packages with names off the desired dependencies
+It will take as input packages with names off 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).
 
@@ -780,7 +780,7 @@ there instead.
 The top level `pkgs.haskell-language-server` attribute is just a convenience
 wrapper to make it possible to install HLS for multiple GHC versions at the
 same time. If you know, that you only use one GHC version, e.g., in a project
-specific `nix-shell` you can simply use
+specific `nix-shell` you can use
 `pkgs.haskellPackages.haskell-language-server` or
 `pkgs.haskell.packages.*.haskell-language-server` from the package set you use.
 
diff --git a/doc/languages-frameworks/lisp.section.md b/doc/languages-frameworks/lisp.section.md
index 8712c341206..fe7f2ef80a2 100644
--- a/doc/languages-frameworks/lisp.section.md
+++ b/doc/languages-frameworks/lisp.section.md
@@ -268,7 +268,7 @@ getting an environment variable for `ext:getenv`. This will load the
 
 ### Loading systems {#lisp-loading-systems}
 
-There, you can simply use `asdf:load-system`. This works by setting the right
+There, you can use `asdf:load-system`. This works by setting the right
 values for the `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` environment
 variables, so that systems are found in the Nix store and pre-compiled FASLs are
 loaded.
diff --git a/doc/languages-frameworks/maven.section.md b/doc/languages-frameworks/maven.section.md
index 7e287a097c7..b86733a7589 100644
--- a/doc/languages-frameworks/maven.section.md
+++ b/doc/languages-frameworks/maven.section.md
@@ -53,7 +53,7 @@ After setting `maven.buildMavenPackage`, we then do standard Java `.jar` install
 
 Maven defines default versions for its core plugins, e.g. `maven-compiler-plugin`. If your project does not override these versions, an upgrade of Maven will change the version of the used plugins, and therefore the derivation and hash.
 
-When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will simply be built on the derivation of old plugins, and fail because the requested plugins are missing.
+When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will be built on the derivation of old plugins, and fail because the requested plugins are missing.
 
 This clearly prevents automatic upgrades of Maven: a manual effort must be made throughout nixpkgs by any maintainer wishing to push the upgrades.
 
diff --git a/doc/languages-frameworks/php.section.md b/doc/languages-frameworks/php.section.md
index 377e3947b2a..154d8174f9a 100644
--- a/doc/languages-frameworks/php.section.md
+++ b/doc/languages-frameworks/php.section.md
@@ -58,7 +58,7 @@ php.withExtensions ({ enabled, all }:
   ++ [ all.imagick ])
 ```
 
-To build your list of extensions from the ground up, you can simply
+To build your list of extensions from the ground up, you can
 ignore `enabled`:
 
 ```nix
@@ -140,7 +140,7 @@ Example of building `composer` with additional extensions:
 ### Overriding PHP packages {#ssec-php-user-guide-overriding-packages}
 
 `php-packages.nix` form a scope, allowing us to override the packages defined
-within. For example, to apply a patch to a `mysqlnd` extension, you can simply
+within. For example, to apply a patch to a `mysqlnd` extension, you can
 pass an overlay-style function to `php`’s `packageOverrides` argument:
 
 ```nix
@@ -191,7 +191,7 @@ using the `bin` attribute in `composer.json`, these binaries will be
 automatically linked and made accessible in the derivation. In this context,
 "binaries" refer to PHP scripts that are intended to be executable.
 
-To use the helper effectively, simply add the `vendorHash` attribute, which
+To use the helper effectively, add the `vendorHash` attribute, which
 enables the wrapper to handle the heavy lifting.
 
 Internally, the helper operates in three stages:
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index 9af3f529ae4..70150717838 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -264,7 +264,7 @@ python3MyBlas = pkgs.python3.override {
 ```
 
 This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.
-Note that using simply `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in
+Note that using `scipy = super.scipy.override { blas = super.pkgs.mkl; };` will likely result in
 compilation issues, because scipy dependencies need to use the same blas implementation as well.
 
 #### `buildPythonApplication` function {#buildpythonapplication-function}
@@ -433,7 +433,7 @@ python3.withPackages (ps: [ ps.pyramid ])
 
 Now, `ps` is set to `python3Packages`, matching the version of the interpreter.
 
-As [`python.withPackages`](#python.withpackages-function) simply uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also
+As [`python.withPackages`](#python.withpackages-function) uses [`python.buildEnv`](#python.buildenv-function) under the hood, it also
 supports the `env` attribute. The `shell.nix` file from the previous section can
 thus be also written like this:
 
@@ -682,7 +682,7 @@ b = np.array([3,4])
 print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
 ```
 
-Then we simply execute it, without requiring any environment setup at all!
+Then we execute it, without requiring any environment setup at all!
 
 ```sh
 $ ./foo.py
@@ -1713,7 +1713,7 @@ This is an example of a `default.nix` for a `nix-shell`, which allows to consume
 a virtual environment created by `venv`, and install Python modules through
 `pip` the traditional way.
 
-Create this `default.nix` file, together with a `requirements.txt` and simply
+Create this `default.nix` file, together with a `requirements.txt` and
 execute `nix-shell`.
 
 ```nix
diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md
index d3b896686c0..920c84eee68 100644
--- a/doc/languages-frameworks/ruby.section.md
+++ b/doc/languages-frameworks/ruby.section.md
@@ -94,7 +94,7 @@ $ bundle lock
 $ bundix
 ```
 
-If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.
+If you already have a `Gemfile.lock`, you can run `bundix` and it will work the same.
 
 To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.
 
@@ -251,7 +251,7 @@ source 'https://rubygems.org' do
 end
 ```
 
-If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.
+If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by running the `bundle lock` and `bundix` steps again.
 
 Now you can also make a `default.nix` that looks like this:
 
diff --git a/doc/languages-frameworks/swift.section.md b/doc/languages-frameworks/swift.section.md
index 1cc452cc9b9..213d444f499 100644
--- a/doc/languages-frameworks/swift.section.md
+++ b/doc/languages-frameworks/swift.section.md
@@ -32,7 +32,7 @@ look for the following directories:
   (If not targeting macOS, replace `macosx` with the Xcode platform name.)
 - On other platforms: `lib/swift/linux/x86_64`
   (Where `linux` and `x86_64` are from lowercase `uname -sm`.)
-- For convenience, Nixpkgs also adds simply `lib/swift` to the search path.
+- 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.
 
@@ -123,7 +123,7 @@ swiftpmFlags = [ "--disable-dead-strip" ];
 
 The default `buildPhase` already passes `-j` for parallel building.
 
-If these two customization options are insufficient, simply provide your own
+If these two customization options are insufficient, provide your own
 `buildPhase` that invokes `swift build`.
 
 ### Running tests {#ssec-swiftpm-running-tests}