From 2f77d9aa7c0c8459f2d5559a0508a134d9db153a Mon Sep 17 00:00:00 2001 From: Ben Siraphob Date: Tue, 19 Aug 2025 00:09:21 -0700 Subject: [PATCH] pkgs: fix README typos --- pkgs/README.md | 6 +++--- .../networking/browsers/chromium/README.md | 2 +- .../networking/cluster/k3s/README.md | 2 +- .../networking/cluster/rke2/README.md | 2 +- pkgs/build-support/go/README.md | 2 +- pkgs/by-name/README.md | 2 +- pkgs/by-name/az/azure-cli/README.md | 2 +- pkgs/by-name/fr/freecad/README.md | 2 +- pkgs/by-name/ka/kanidm/README.md | 2 +- pkgs/by-name/ni/nixos-rebuild-ng/README.md | 10 +++++----- pkgs/by-name/ni/nixos-render-docs/README.md | 2 +- .../sw/switch-to-configuration-ng/README.md | 2 +- pkgs/development/compilers/elm/README.md | 2 +- pkgs/development/compilers/julia/README.md | 2 +- pkgs/development/compilers/llvm/README.md | 6 +++--- pkgs/development/cuda-modules/README.md | 18 +++++++++--------- pkgs/development/mobile/androidenv/README.md | 2 +- .../tools/build-managers/gradle/README.md | 16 ++++++++-------- pkgs/stdenv/darwin/README.md | 2 +- pkgs/tools/package-management/nix/README.md | 2 +- .../package-management/nix/modular/README.md | 2 +- 21 files changed, 44 insertions(+), 44 deletions(-) diff --git a/pkgs/README.md b/pkgs/README.md index 7dd549cc3438..635cda46ce03 100644 --- a/pkgs/README.md +++ b/pkgs/README.md @@ -1116,7 +1116,7 @@ Sample template for a package update review is provided below. ### New packages New packages are a common type of pull requests. -These pull requests consists in adding a new nix-expression for a package. +These pull requests consist in adding a new nix-expression for a package. Review process: @@ -1131,7 +1131,7 @@ Review process: - Maintainers must be set. This can be the package submitter or a community member that accepts taking up maintainership of the package. - The `meta.mainProgram` must be set if a main executable exists. -- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment. +- Ensure any special packaging choices and required context are documented in, i.e., the name of a patch or in a comment. - If a special version of a package is pinned, document why, so others know if/when it can be unpinned. - If any (especially opinionated) patch or `substituteInPlace` is applied, document why. - If any non-default build flags are set, document why. @@ -1204,7 +1204,7 @@ Currently opened ones can be found using the following: [github.com/NixOS/nixpkgs/issues?q=is:issue+is:open+"Vulnerability+roundup"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+%22Vulnerability+roundup%22) -Each issue correspond to a vulnerable version of a package; As a consequence: +Each issue corresponds to a vulnerable version of a package; as a consequence: - One issue can contain several CVEs; - One CVE can be shared across several issues; diff --git a/pkgs/applications/networking/browsers/chromium/README.md b/pkgs/applications/networking/browsers/chromium/README.md index ae5b4a1c97cb..dc928bb7b4e6 100644 --- a/pkgs/applications/networking/browsers/chromium/README.md +++ b/pkgs/applications/networking/browsers/chromium/README.md @@ -11,7 +11,7 @@ - `ungoogled-chromium`: A patch set for Chromium, that has its own entry in Chromium's `upstream-info.nix`. - `chromedriver`: Updated via Chromium's `upstream-info.nix` and not built from source. Must match Chromium's major version. - - `electron-source`: Various version of electron that are built from source using Chromium's + - `electron-source`: Various versions of electron that are built from source using Chromium's `-unwrapped` derivation, due to electron being based on Chromium. # Upstream links diff --git a/pkgs/applications/networking/cluster/k3s/README.md b/pkgs/applications/networking/cluster/k3s/README.md index 9ea31423c7db..dcc2bffcc69e 100644 --- a/pkgs/applications/networking/cluster/k3s/README.md +++ b/pkgs/applications/networking/cluster/k3s/README.md @@ -1,6 +1,6 @@ # K3s -K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version that bundles Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices. +K3s is a simplified [Kubernetes](https://wiki.nixos.org/wiki/Kubernetes) version that bundles Kubernetes cluster components into a few small binaries optimized for Edge and IoT devices. ## Usage diff --git a/pkgs/applications/networking/cluster/rke2/README.md b/pkgs/applications/networking/cluster/rke2/README.md index e22ebe904acd..e511c1a5ef6c 100644 --- a/pkgs/applications/networking/cluster/rke2/README.md +++ b/pkgs/applications/networking/cluster/rke2/README.md @@ -24,7 +24,7 @@ release channel tied to each Kubernetes minor version, e.g. `v1.32`. Nixpkgs follows active minor version release channels (typically 4 at a time) and sets aliases for `rke2_stable` and `rke2_latest` accordingly. -Patch releases should be backported to to the latest stable release branch, however, new minor +Patch releases should be backported to the latest stable release branch; however, new minor versions are not backported. For further information visit the diff --git a/pkgs/build-support/go/README.md b/pkgs/build-support/go/README.md index 9a0b59836921..6e87879f20ac 100644 --- a/pkgs/build-support/go/README.md +++ b/pkgs/build-support/go/README.md @@ -39,7 +39,7 @@ Based on this, we align on the following policy for toolchain/builder upgrades: When an end-of-life toolchain is removed, builders that pin the EOL version (according to 3.) will automatically be bumped to the then oldest pinned builder (e.g. Go 1.22 is EOL, `buildGo122Module` is bumped to `buildGo123Module`). - If the package won't build with anymore with that builder, the package is marked broken. + If the package won't build with that builder anymore, the package is marked broken. It is the package maintainers responsibility to fix the package and get it working with a supported Go toolchain. [1]: http://go.dev/doc/go1compat diff --git a/pkgs/by-name/README.md b/pkgs/by-name/README.md index 4dcb6708a1c7..5f962ccffa01 100644 --- a/pkgs/by-name/README.md +++ b/pkgs/by-name/README.md @@ -110,7 +110,7 @@ foo.override { bar = baz; } ## Limitations -There's some limitations as to which packages can be defined using this structure: +There are some limitations as to which packages can be defined using this structure: - Only packages defined using `pkgs.callPackage`. This excludes packages defined using `pkgs.python3Packages.callPackage ...`. diff --git a/pkgs/by-name/az/azure-cli/README.md b/pkgs/by-name/az/azure-cli/README.md index d236c3cb4390..958828067549 100644 --- a/pkgs/by-name/az/azure-cli/README.md +++ b/pkgs/by-name/az/azure-cli/README.md @@ -87,7 +87,7 @@ nix build --impure --expr 'with (import ./. {}); azure-cli.withExtensions [ azur Check if the desired functionality was added. -You can check if the extensions was recognized by running: +You can check if the extensions were recognized by running: ```sh ./result/bin/az extension list diff --git a/pkgs/by-name/fr/freecad/README.md b/pkgs/by-name/fr/freecad/README.md index b8dd940578ee..f3fdae03e150 100644 --- a/pkgs/by-name/fr/freecad/README.md +++ b/pkgs/by-name/fr/freecad/README.md @@ -1,7 +1,7 @@ This package supports the following parameters: - withWayland (default: true): when false, set QT_QPA_PLATFORM to xcb -- spaceNavSupport (enabled by default on linux): whether to enable +- spaceNavSupport (enabled by default on Linux): whether to enable [spacenavd support](https://spacenav.sourceforge.net/) - ifcSupport (default: false): whether to enable ifc support through ifcopenshell diff --git a/pkgs/by-name/ka/kanidm/README.md b/pkgs/by-name/ka/kanidm/README.md index c4bcd62467e2..b624e8e67ab4 100644 --- a/pkgs/by-name/ka/kanidm/README.md +++ b/pkgs/by-name/ka/kanidm/README.md @@ -34,7 +34,7 @@ For example, when upgrading from 1.4 -> 1.5 ## Remove release -Kanidm versions are supported for 30 days after the release of new versions. Following the example above, 1.5.x superseding 1.4.x in 30 days, do the following near the end of the 30 day window +Kanidm versions are supported for 30 days after the release of new versions. Following the example above, 1.5.x superseding 1.4.x in 30 days, do the following near the end of the 30-day window 1. Update `pkgs/by-name/ka/kanidm/1_4.nix` by adding `unsupported = true;` 1. Update `pkgs/top-level/release.nix` and add `kanidm_1_4-1.4.6` and `kanidmWithSecretProvisioning_1_4-1.4.6` to `permittedInsecurePackages` diff --git a/pkgs/by-name/ni/nixos-rebuild-ng/README.md b/pkgs/by-name/ni/nixos-rebuild-ng/README.md index 3192c044e262..49c0d7bbfa2c 100644 --- a/pkgs/by-name/ni/nixos-rebuild-ng/README.md +++ b/pkgs/by-name/ni/nixos-rebuild-ng/README.md @@ -7,7 +7,7 @@ Work-in-Progress rewrite of The current state of `nixos-rebuild` is dire: it is one of the most critical pieces of code we have in NixOS, but it has tons of issues: -- The code is written in Bash, and while this by itself is not necessary bad, +- The code is written in Bash, and while this by itself is not necessarily bad, it means that it is difficult to do refactorings due to the lack of tooling for the language - The code itself is a hacky mess. Changing even one line of code can cause @@ -18,7 +18,7 @@ pieces of code we have in NixOS, but it has tons of issues: builds Flakes inside a temporary directory and reads the resulting symlink since the code seems to predate `--print-out-paths` flag -Given all of those above, improvements in the `nixos-rebuild` are difficult to +Given all of the above, improvements in the `nixos-rebuild` are difficult to do. A full rewrite is probably the easier way to improve the situation since this can be done in a separate package that will not break anyone. So this is an attempt of the rewrite. @@ -44,7 +44,7 @@ nix-build -A nixos-rebuild-ng -A nixos-rebuild-ng.tests.linters ``` The command above will build, run the unit tests and linters, and also check if -the code is formatted. However, sometimes is more convenient to run just a few +the code is formatted. However, sometimes it's more convenient to run just a few tests to debug, in this case you can run: ```console @@ -97,7 +97,7 @@ not possible to fix, please open an issue and we can discuss a solution. please open an issue - We do some additional validation of flags, like exiting with an error when `--build-host` or `--target-host` is used with `repl`, since the user could - assume that the `repl` would be run remotely while it always run the local + assume that the `repl` would be run remotely while it always runs the local machine. `nixos-rebuild` silently ignored those flags, so this [may cause some issues](https://github.com/NixOS/nixpkgs/pull/363922) for wrappers @@ -108,7 +108,7 @@ not possible to fix, please open an issue and we can discuss a solution. may be difficult to fix, so right now I only recommend using `nixos-rebuild-ng` if you are testing in a VM or in a filesystem with snapshots like BTRFS or ZFS. Those bugs are unlikely to be unfixable but the - errors can be difficult to understand. If you want to go anyway, + errors can be difficult to understand. If you want to go on, `nix-collect-garbage -d` and `nix store repair` are your friends ## TODON'T diff --git a/pkgs/by-name/ni/nixos-render-docs/README.md b/pkgs/by-name/ni/nixos-render-docs/README.md index a27e9fdbc9eb..4c0af6db096e 100644 --- a/pkgs/by-name/ni/nixos-render-docs/README.md +++ b/pkgs/by-name/ni/nixos-render-docs/README.md @@ -40,7 +40,7 @@ The chosen design is a trade-off between speed, repository size, and contributor - It would also require keeping an impure or otherwise continuously updated reference to those other revisions. - The static mapping acts like a semi-automatically updated cache that we drag along with version history. - Other setups, such as a dedicated service to cache a history of moved content, are more complicated and would still be impure. -- Checking in large amounts of data that is touched often, bears a risk of more merge conflicts or related build failures. +- Checking in large amounts of data that is touched often bears a risk of more merge conflicts or related build failures. The solution picked here is to have a static mapping of the historical locations checked into the Git tree, such that it can be read during the build process. This also ensures that an improper redirect mapping will cause `nixos-render-docs` to fail the build and thus enforce that redirects stay up-to-date with every commit. diff --git a/pkgs/by-name/sw/switch-to-configuration-ng/README.md b/pkgs/by-name/sw/switch-to-configuration-ng/README.md index ae7003302d0b..4111f131f089 100644 --- a/pkgs/by-name/sw/switch-to-configuration-ng/README.md +++ b/pkgs/by-name/sw/switch-to-configuration-ng/README.md @@ -1,6 +1,6 @@ # switch-to-configuration-ng -This program implements the switching/updating of NixOS systems. It starts with the exising running configuration at `/run/current-system` and handles the migration to a new configuration, built from a NixOS configuration's `config.system.build.toplevel` derivation. +This program implements the switching/updating of NixOS systems. It starts with the existing running configuration at `/run/current-system` and handles the migration to a new configuration, built from a NixOS configuration's `config.system.build.toplevel` derivation. For more information on what happens during a switch, see [what-happens-during-a-system-switch](../../../../nixos/doc/manual/development/what-happens-during-a-system-switch.chapter.md). diff --git a/pkgs/development/compilers/elm/README.md b/pkgs/development/compilers/elm/README.md index f0254d0f9547..609d67c1a773 100644 --- a/pkgs/development/compilers/elm/README.md +++ b/pkgs/development/compilers/elm/README.md @@ -12,7 +12,7 @@ package.elm-lang.org, as well as a cached bit of metadata (versions.dat). The makeDotElm function lets us retrieve these dependencies in the -standard nix way. we have to copy them in (rather than symlink) and +standard nix way. We have to copy them in (rather than symlink) and make them writable because the elm compiler writes other .dat files alongside the source code. versions.dat was produced during an impure build of this same code; the build complains that it can't diff --git a/pkgs/development/compilers/julia/README.md b/pkgs/development/compilers/julia/README.md index e9843fa3c9e7..9df03e6ae486 100644 --- a/pkgs/development/compilers/julia/README.md +++ b/pkgs/development/compilers/julia/README.md @@ -9,7 +9,7 @@ as comments in the expressions themselves. [julia]: https://julialang.org For Nixpkgs, the manual is as always your primary reference, and for the Julia -side of things you probably want to familiarise yourself with the [README +side of things, you probably want to familiarise yourself with the [README ][readme], [build instructions][build], and [release process][release_process]. Remember that these can change between Julia releases, especially if the LTS and release branches have deviated greatly. A lot of the build process is diff --git a/pkgs/development/compilers/llvm/README.md b/pkgs/development/compilers/llvm/README.md index ca4e096eb002..399669988641 100644 --- a/pkgs/development/compilers/llvm/README.md +++ b/pkgs/development/compilers/llvm/README.md @@ -2,7 +2,7 @@ - Run `update-git.py`. This will set the github revision and sha256 for `llvmPackages_git.llvm` to whatever the latest chromium build is using. - For a more recent, commit run `nix-prefetch-github` and change the rev and sha256 accordingly. + For a more recent commit, run `nix-prefetch-github` and change the rev and sha256 accordingly. - That was the easy part. The hard part is updating the patch files. @@ -50,7 +50,7 @@ which can be an easily missed reason for failures. For cases where the hunk is no longer needed you can simply remove it from the patch. - This is fine for small corrections, but when more serious changes are needed its better to use git. + This is fine for small corrections, but when more serious changes are needed, it's better to use git. 1. Clone the LLVM monorepo at https://github.com/llvm/llvm-project/ @@ -68,7 +68,7 @@ Use CMake's [`GNUInstallDirs`](https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html) to support multiple outputs. -Previously, LLVM Just hard-coded `bin`, `include`, and `lib${LLVM_TARGET_PREFIX}`. +Previously, LLVM just hard-coded `bin`, `include`, and `lib${LLVM_TARGET_PREFIX}`. We are making it use these variables. For the older LLVM versions, these patches live in https://github.com/Ericson2314/llvm-project branches `split-prefix`. diff --git a/pkgs/development/cuda-modules/README.md b/pkgs/development/cuda-modules/README.md index 1a88761c4d51..8d450302a45d 100644 --- a/pkgs/development/cuda-modules/README.md +++ b/pkgs/development/cuda-modules/README.md @@ -1,4 +1,4 @@ -# Cuda modules +# CUDA Modules > [!NOTE] > This document is meant to help CUDA maintainers understand the structure of @@ -43,17 +43,17 @@ package set by [cuda-packages.nix](../../top-level/cuda-packages.nix). ## Distinguished packages -### Cuda compatibility +### CUDA Compatibility -[Cuda Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/), +[CUDA Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/), available as `cudaPackages.cuda_compat`, is a component which makes it possible to run applications built against a newer CUDA toolkit (for example CUDA 12) on a machine with an older CUDA driver (for example CUDA 11), which isn't possible -out of the box. At the time of writing, Cuda Compatibility is only available on +out of the box. At the time of writing, CUDA Compatibility is only available on the Nvidia Jetson architecture, but Nvidia might release support for more architectures in the future. -As Cuda Compatibility strictly increases the range of supported applications, we +As CUDA Compatibility strictly increases the range of supported applications, we try our best to enable it by default on supported platforms. #### Functioning @@ -64,17 +64,17 @@ the other shared libraries of the default driver must still be accessible: `cuda_compat` isn't a complete drop-in replacement for the driver (and that's the point, otherwise, it would just be a newer driver). -Nvidia's recommendation is to set `LD_LIBRARY_PATH` to points to `cuda_compat`'s +Nvidia's recommendation is to set `LD_LIBRARY_PATH` to point to `cuda_compat`'s driver. This is fine for a manual, one-shot usage, but in general setting `LD_LIBRARY_PATH` is a red flag. This is global state which short-circuits most -of other dynamic libraries resolution mechanisms and can break things in +of other dynamic library resolution mechanisms and can break things in non-obvious ways, especially with other Nix-built software. -#### Cuda compat with Nix +#### CUDA Compat with Nix Since `cuda_compat` is a known derivation, the easy way to do this in Nix would be to add `cuda_compat` as a dependency of CUDA libraries and applications and -let Nix does its magic by filling the `DT_RUNPATH` fields. However, +let Nix do its magic by filling the `DT_RUNPATH` fields. However, `cuda_compat` itself depends on `libnvrm_mem` and `libnvrm_gpu` which are loaded dynamically at runtime from `/run/opengl-driver`. This doesn't please the Nix sandbox when building, which can't find those (a second minor issue is that diff --git a/pkgs/development/mobile/androidenv/README.md b/pkgs/development/mobile/androidenv/README.md index 7ebb9d640c0b..815df6d20282 100644 --- a/pkgs/development/mobile/androidenv/README.md +++ b/pkgs/development/mobile/androidenv/README.md @@ -4,7 +4,7 @@ # How to run tests -You may need to make yourself familiar with [package tests](../../../README.md#package-tests), and [Writing larger package tests](../../../README.md#writing-larger-package-tests), then run tests locally with: +You may need to make yourself familiar with [package tests](../../../README.md#package-tests) and [Writing larger package tests](../../../README.md#writing-larger-package-tests), then run tests locally with: ```shell $ export NIXPKGS_ALLOW_UNFREE=1 diff --git a/pkgs/development/tools/build-managers/gradle/README.md b/pkgs/development/tools/build-managers/gradle/README.md index bdfca72f61f3..4598b0302391 100644 --- a/pkgs/development/tools/build-managers/gradle/README.md +++ b/pkgs/development/tools/build-managers/gradle/README.md @@ -3,7 +3,7 @@ ## Introduction Gradle build scripts are written in a DSL, computing the list of Gradle -dependencies is a turing-complete task, not just in theory but in +dependencies is a Turing-complete task, not just in theory but also in practice. Fetching all of the dependencies often requires building some native code, running some commands to check the host platform, or just fetching some files using either JVM code or commands like `curl` or @@ -22,7 +22,7 @@ use the latest version of a dependency as opposed to a fixed version. Obviously, this is horrible for reproducibility. Additionally, Gradle doesn't offer a way to export the list of dependency URLs and hashes (it does in a way, but it's far from being complete, and as such is useless -for nixpkgs). Even if did, it would be annoying to use considering +for Nixpkgs). Even if it did, it would be annoying to use considering fetching non-Gradle dependencies in Gradle scripts is commonplace. That's why the setup hook uses mitm-cache, a program designed for @@ -89,7 +89,7 @@ it hasn't yet downloaded a file with this hash, and then fetch `a.jar`, and finally download `b.jar.sha1`, locate it in its cache, and then *not* download `b.jar`. This means `b.jar` won't be stored in the MITM cache. Then, consider that on a later invocation, the fetching order -changed, whether it was because of a running on different system, +changed, whether it was because of running on a different system, changed behavior after a Gradle update, or any other source of nondeterminism - `b.jar` is fetched before `a.jar`. Gradle will first fetch `b.jar.sha1`, not find it in its cache, attempt to fetch `b.jar`, @@ -103,7 +103,7 @@ stripping is hardcoded, but `.md5/.sha1` file rejection is configured via CLI arguments. **Caveat**: Gradle .module files also contain file hashes, in md5, sha1, -sha256, sha512 formats. It posed no problem as of yet, but it might in +sha256, sha512 formats. It has posed no problem as of yet, but it might in the future. If it does pose problems, the deps derivation code can be extended to find all checksums in .module files and copy existing files there if their hash matches. @@ -173,11 +173,11 @@ following items: The mitm-cache lockfile format is described in the [mitm-cache README](https://github.com/chayleaf/mitm-cache#readme). -The nixpkgs Gradle lockfile format is more complicated: +The Nixpkgs Gradle lockfile format is more complicated: ```json { - "!comment": "This is a nixpkgs Gradle dependency lockfile. For more details, refer to the Gradle section in the nixpkgs manual.", + "!comment": "This is a Nixpkgs Gradle dependency lockfile. For more details, refer to the Gradle section in the Nixpkgs manual.", "!version": 1, "https://oss.sonatype.org/content/repositories/snapshots/com/badlogicgames/gdx-controllers": { "gdx-controllers#gdx-controllers-core/2.2.4-20231021.200112-6/SNAPSHOT": { @@ -223,7 +223,7 @@ Each URL has a value associated with it. The value may be: discern where the repo base ends and the group ID begins). `compress-deps-json.py` converts the JSON from mitm-cache format into -nixpkgs Gradle lockfile format. `fetch.nix` does the opposite. +Nixpkgs Gradle lockfile format. `fetch.nix` does the opposite. ## Security Considerations @@ -242,4 +242,4 @@ the following: doesn't match) Please be mindful of the above when working on Gradle support for -nixpkgs. +Nixpkgs. diff --git a/pkgs/stdenv/darwin/README.md b/pkgs/stdenv/darwin/README.md index 75d30b96a7f6..df0641868f58 100644 --- a/pkgs/stdenv/darwin/README.md +++ b/pkgs/stdenv/darwin/README.md @@ -15,7 +15,7 @@ There are two more goals worth calling out explicitly: There are effectively two steps when updating the standard environment: 1. Update the definition of llvmPackages in `all-packages.nix` for Darwin to match the value of - llvmPackages.latest in `all-packages.nix`. Timing-wise, this done currently using the spring + llvmPackages.latest in `all-packages.nix`. Timing-wise, this is done currently using the spring release of LLVM and once llvmPackages.latest has been updated to match. If the LLVM project has announced a release schedule of patch updates, wait until those are in nixpkgs. Otherwise, the LLVM updates will have to go through staging instead of being merged into master; and diff --git a/pkgs/tools/package-management/nix/README.md b/pkgs/tools/package-management/nix/README.md index 0b87fdf1088b..922d2970bd87 100644 --- a/pkgs/tools/package-management/nix/README.md +++ b/pkgs/tools/package-management/nix/README.md @@ -32,7 +32,7 @@ curl https://releases.nixos.org/nix/nix-$version/fallback-paths.nix > nixos/modu If you're updating `nixVersions.stable`, follow all the steps mentioned above, but use the **staging** branch for your pull request (or **staging-next** after coordinating with the people in matrix `#staging:nixos.org`) This is necessary because, at the end of the staging-next cycle, the NixOS tests are built through the [staging-next-small](https://hydra.nixos.org/jobset/nixos/staging-next-small) jobset. -Especially nixos installer test are important to look at here. +Especially NixOS installer tests are important to look at here. There is a script to update minor versions: diff --git a/pkgs/tools/package-management/nix/modular/README.md b/pkgs/tools/package-management/nix/modular/README.md index e6488d2b1e32..0b1c83be5fb9 100644 --- a/pkgs/tools/package-management/nix/modular/README.md +++ b/pkgs/tools/package-management/nix/modular/README.md @@ -13,5 +13,5 @@ Using filesets with a fetched source would require "IFD", as the fetching happen ### `workDir` attribute -The Nixpkgs for Nix does inherit the `workDir` attribute that determines the location of the subproject to build. +The Nixpkgs for Nix inherits the `workDir` attribute that determines the location of the subproject to build. It is compared to this directory to produce the correct relative path, similar to upstream.