diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bb76ad0c5..ca317400e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,7 +29,7 @@ To manually test [redirects](./_redirects): ## Building the reference manuals -By default nix.dev builds without the various versions of the Nix reference manual, as that takes quite a while due to how it's currently implemented. +By default, nix.dev builds without the various versions of the Nix reference manual, as that takes quite a while due to how it's currently implemented. To enable building the manuals: ```shell-session diff --git a/source/acknowledgements/index.md b/source/acknowledgements/index.md index 6a4db57b1..4b0c26206 100644 --- a/source/acknowledgements/index.md +++ b/source/acknowledgements/index.md @@ -38,4 +38,4 @@ Many thanks to past contributors, who helped make Nix documentation what it is t - [@domenkozar](https://github.com/domenkozar) was a founding member and part of the team from 2022-05 to 2023-01. Domen originally started nix.dev, wrote many basic tutorials, and funded editorial work through [Cachix](https://www.cachix.org/). He helped bootstrap the documentation team, handed out permissions, and advised us on many aspects. - Domen donated nix.dev to the NixOS Foundation 2023-07. + Domen donated nix.dev to the NixOS Foundation in 2023-07. diff --git a/source/concepts/faq.md b/source/concepts/faq.md index 2adf87c39..8fd055d66 100644 --- a/source/concepts/faq.md +++ b/source/concepts/faq.md @@ -62,12 +62,12 @@ Rolling releases follow [`master`](https://github.com/NixOS/nixpkgs/branches/all Yes. There is: -- CPU architecture—great effort being made to avoid compilation of native instructions in favour of hardcoded supported ones. +- CPU architecture—great effort is being made to avoid compilation of native instructions in favour of hardcoded supported ones. - System's current time/date. - The filesystem used for building (see also [`TMPDIR`](https://nix.dev/manual/nix/stable/command-ref/env-common.html#env-TMPDIR)). - Linux kernel parameters, such as: - [IPv6 capabilities](https://github.com/NixOS/nix/issues/5615). - binfmt interpreters, e.g., those configured with [`boot.binfmt.emulatedSystems`](https://search.nixos.org/options?show=boot.binfmt.emulatedSystems). -- Timing behaviour of the build system—parallel Make build does not get the correct inputs in some cases. +- Timing behaviour of the build system—a parallel Make build may not get the correct inputs in some cases. - Insertion of random values, e.g., from `/dev/random` or `/dev/urandom`. - Differences between Nix versions. For instance, a new Nix version might introduce a new environment variable. A statement like `env > $out` is not promised by Nix to result in the same output, going into the future. diff --git a/source/concepts/flakes.md b/source/concepts/flakes.md index 66adc847c..a5842b7ba 100644 --- a/source/concepts/flakes.md +++ b/source/concepts/flakes.md @@ -42,7 +42,7 @@ Nix handles flakes differently than regular {term}`Nix files ` in the - No external variables, parameters, or impure language values are allowed. - It means full reproducibility of a Nix expression, and, by extension, the resulting build instructions by default, but also prohibits parameterisation of results by consumers. + It means full reproducibility of a Nix expression, and, by extension, the resulting build instructions by default, but also prohibits parametrisation of results by consumers. (flakes-controversy)= ## Why are flakes controversial? @@ -50,13 +50,13 @@ Nix handles flakes differently than regular {term}`Nix files ` in the [Flakes](flakes-definition) were inspired by [Shea Levy's NixCon 2018 talk](https://www.youtube.com/watch?v=DHOLjsyXPtM), formally proposed in [RFC 49](https://github.com/NixOS/rfcs/pull/49), and have been in development since 2019. Nix introduced the implementation as its first [experimental feature] in 2021. -The subject is considered controversial among Nix users and developers in terms of design, implementation quality, and decision making process. +The subject is considered controversial among Nix users and developers in terms of design, implementation quality, and decision-making process. In particular: - The RFC was closed without conclusion, and some fundamental issues are not yet resolved. For example: - The notion of a [global flake registry](https://github.com/NixOS/flake-registry) saw [substantial criticism](https://github.com/NixOS/rfcs/pull/49#issuecomment-635635333) that was never addressed. While the source references of [registry entries can be pinned](https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-registry-pin), local registry names in Nix expressions [introduce mutable system state](https://github.com/NixOS/nix/issues/7422) and are thus, in that regard, no improvement over channels as managed by [`nix-channel`](https://nix.dev/manual/nix/stable/command-ref/nix-channel). - - It is [impossible to parameterise flakes](https://github.com/NixOS/nix/issues/2861). + - It is [impossible to parametrise flakes](https://github.com/NixOS/nix/issues/2861). This means that [flakes downgrade ease of use of the `system` parameter](https://github.com/NixOS/nix/issues/3843) of derivations, for producers and consumers. - the flakes proposal was criticised for [trying to solve too many problems at once](https://github.com/nixos/rfcs/pull/49#issuecomment-521998933) and [at the wrong abstraction layer](https://discourse.nixos.org/t/nixpkgs-cli-working-group-member-search/30517). Part of this is that [the new command line interface and flakes are closely tied to each other](https://discourse.nixos.org/t/2023-03-06-nix-team-meeting-minutes-38/26056#cli-stabilisation-announcement-draft-4). @@ -89,13 +89,13 @@ Flakes and the `nix` command suite bring multiple improvements that are relevant At the same time, flakes have [fundamental architectural issues](flakes-controversy) and a number of [problems with the implementation](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+label%3Aflakes+sort%3Areactions-%2B1-desc), and there is no coordinated effort to resolve them systematically. There are also still many [open design questions around the `nix` command line interface](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+label%3Anew-cli+sort%3Areactions-%2B1-desc), some of which are currently being worked on. -While flakes reduce complexity in some regards, they also introduce some with additional mechanisms. +While flakes reduce complexity in some regards, they also introduce some complexity with additional mechanisms. You will have to learn more about the system to fully understand how it works. Other than that, and below the surface of the flake schema, Nix and the Nix language work exactly the same in both cases. In principle, the same level of reproducibility can be achieved with or without flakes. In particular, the process of adding software to {term}`Nixpkgs` or maintaining {term}`NixOS` modules and configurations is not affected by flakes at all. -There is also no evidence that flakes could help solving the scalability challenges of either. +There is also no evidence that flakes could help solve the scalability challenges of either. Finally, there are downsides to relying on [experimental features][experimental feature] in general: diff --git a/source/concepts/index.md b/source/concepts/index.md index 1cb09fc8c..462d2a2a5 100644 --- a/source/concepts/index.md +++ b/source/concepts/index.md @@ -1,7 +1,7 @@ (concepts)= # Concepts -These sections contains explanations of history and ideas in the Nix ecosystem. +These sections contain explanations of history and ideas in the Nix ecosystem. ```{toctree} :glob: diff --git a/source/contributing/documentation/diataxis.md b/source/contributing/documentation/diataxis.md index aa466c7ac..100673e16 100644 --- a/source/contributing/documentation/diataxis.md +++ b/source/contributing/documentation/diataxis.md @@ -5,9 +5,9 @@ We aim to build our documentation according to the [Diátaxis framework for tech - [Tutorials](#tutorials) - [Guides](#guides) - [Reference](#reference) -- [Concept](#concepts) +- [Concepts](#concepts) -We've found that contributors struggle to understand the differences between these categories, and while we _strongly_ recommend reading up on the Diataxis framework, we can summarize them as follows: +We've found that contributors struggle to understand the differences between these categories, and while we _strongly_ recommend reading up on the Diátaxis framework, we can summarize them as follows: ## Reference @@ -62,7 +62,7 @@ The pilot-in-training needs practice knowing when to deploy the landing gear, wh Actually landing the plane during the flight simulation is less important than learning the individual skills that make up a successful landing. This is the context for a tutorial. -Finally, one last way of thinking about the difference between How-to Guide and Tutorial is like this: +Finally, one last way of thinking about the difference between a how-to guide and a tutorial is like this: - Guide: "step 1: do this, step 2: do that, etc" - Tutorial: "take my hand as I show you how to do this" diff --git a/source/contributing/documentation/index.md b/source/contributing/documentation/index.md index 3b52ac480..0213aa9f7 100644 --- a/source/contributing/documentation/index.md +++ b/source/contributing/documentation/index.md @@ -1,6 +1,6 @@ # Contributing documentation -Thank you for your interest to help improve documentation in the Nix ecosystem! +Thank you for your interest in helping improve documentation in the Nix ecosystem! This project would not be possible without your support. ## Getting started @@ -40,7 +40,7 @@ Please share your experience to help us improve upstream documentation and begin If you are proficient in applying Nix to a domain-specific problem, and want to share your expertise on best practices, please check the existing content. - Does existing material on your subject meet your standards? - How could we improve it? -- Is there a popular application of Nix' capabilities not yet covered? +- Is there a popular application of Nix's capabilities not yet covered? - We would be glad to incorporate your insights. ## Licensing and attribution diff --git a/source/contributing/documentation/resources.md b/source/contributing/documentation/resources.md index 0e0f11229..62728d448 100644 --- a/source/contributing/documentation/resources.md +++ b/source/contributing/documentation/resources.md @@ -1,6 +1,6 @@ # Documentation resources -This is an overview of documentation resources for Nix, Nixpkgs, and NixOS, with suggestions how you can help to improve them. +This is an overview of documentation resources for Nix, Nixpkgs, and NixOS, with suggestions for how you can help to improve them. ## Reference manuals diff --git a/source/contributing/documentation/style-guide.md b/source/contributing/documentation/style-guide.md index ea6354d46..25865853f 100644 --- a/source/contributing/documentation/style-guide.md +++ b/source/contributing/documentation/style-guide.md @@ -10,8 +10,8 @@ This document outlines the guidelines we use when writing documentation. > > — [Blaise Pascal](https://en.m.wikiquote.org/w/index.php?title=Blaise_Pascal&oldid=2978584#Quotes) -Readers' time and attention is limited. -Take the time to be extraordinarily respectful with their cognitive resources. +Readers' time and attention are limited. +Take the time to be extraordinarily respectful of their cognitive resources. The same holds for communication directed to contributors and maintainers: This is a public project, and many people will read what you write. @@ -27,7 +27,7 @@ Use this leverage with care. > Add the `python310` package to `buildInputs`. - Don't use a conversational tone, as it distracts from the contents. + Don't use a conversational tone, as it distracts from the content. For example, don't write: > Going forward, let's now add the `python310` package to `buildInputs` as we have seen in the previous tutorial. @@ -110,7 +110,7 @@ Set off a [fork bomb](https://en.wikipedia.org/wiki/Fork_bomb): ``` :::{dropdown} Detailed explanation -This Bash command defines and executes a function `:` that recursively spawns copies of itself, quickly consuming system resources +This Bash command defines and executes a function `:` that recursively spawns copies of itself, quickly consuming system resources. ::: ```` :::: @@ -126,10 +126,10 @@ If that's not possible, break the example down into multiple parts, explain them Code samples that are _intended_ to work should work. -If you are going to present an example that does not work (e.g. you're illustrating a common mistake) explain so beforehand. +If you are going to present an example that does not work (e.g. you're illustrating a common mistake) explain this beforehand. Many readers will get stuck trying to make example code work without reading ahead to find out that the code isn't intended to work. -Code samples should all include a programming language when applicable for syntax highlighting when rendered e.g. +Code samples should all include a programming language when applicable for syntax highlighting when rendered, e.g.: ```` ```python @@ -142,7 +142,7 @@ print("Hello, World!") Reserve the largest header (`#`) for the title. Use Markdown headers `##` through `###` to divide up content in the body of the document. -Finer grained headings are not necessarily better. +Finer-grained headings are not necessarily better. ### One line per sentence diff --git a/source/contributing/documentation/writing-a-tutorial.md b/source/contributing/documentation/writing-a-tutorial.md index e95c5276a..fa66f1395 100644 --- a/source/contributing/documentation/writing-a-tutorial.md +++ b/source/contributing/documentation/writing-a-tutorial.md @@ -24,20 +24,20 @@ Most of that time is typically spent collaboratively: - Ensuring that the instructions are neither too sparse nor too dense for learners - Finding ever-more succinct and clear ways to convey ideas -Follow these steps to avoid re-doing work +Follow these steps to avoid redoing work ### Pick a topic There is a [tracking issue](https://github.com/NixOS/nix.dev/issues/572) for tutorials that the documentation team has decided should exist as part of the tutorial series. Pick an issue that covers a topic that you're either knowledgeable about or have a particular interest in. -Check referenced issues and pull request to make sure you won't duplicate work that someone else has already started! +Check referenced issues and pull requests to make sure you won't duplicate work that someone else has already started! There are more [tutorial requests](https://github.com/NixOS/nix.dev/issues?q=is%3Aopen+is%3Aissue+label%3Atutorial) than captured in the outline. [Open a new issue](https://github.com/NixOS/nix.dev/issues/new?&template=tutorial.md) if what you wanted to work on isn't tracked anywhere. This is an opportunity for you to clarify your goals, and an opportunity for everyone else to find out that there's interest in that subject. -### Submit an pull request with an outline +### Submit a pull request with an outline Submit a pull request with an outline of the tutorial following [our recommended structure](#structure). The outline should contain bullet points on each section's content. @@ -57,7 +57,7 @@ Revise your tutorial based on the detailed feedback. We recommend testing your tutorial with friends or coworkers. This will both help with revealing implicit prerequisites as well as provide a realistic estimate of the reading time. -In a final review will check that everything is technically correct. +A final review will check that everything is technically correct. ## Structure @@ -74,7 +74,7 @@ The learning goal of a tutorial is always acquiring a skill, which is distinguis ### What do you need? State the prerequisite knowledge and skills. -The tutorial should always be written such that the stated prerequisites are sufficient to achieve learning goals. +The tutorial should always be written such that the stated prerequisites are sufficient to achieve the learning goals. Examples: @@ -111,7 +111,7 @@ Depending on how well a use case is explored, point the reader to - guides or other tutorials - links to known-good external resources, with summaries - overview of available support tools, and their state of maturity and maintenance -- overview of ideas, and state of community discussion. +- overview of ideas, and the state of community discussion. We recommend making an explicit separation of practical from theoretical learning resources, as then readers will be able to quickly decide to either get things done or learn more. diff --git a/source/contributing/how-to-contribute.md b/source/contributing/how-to-contribute.md index 1d13662fa..a9cb4c30c 100644 --- a/source/contributing/how-to-contribute.md +++ b/source/contributing/how-to-contribute.md @@ -6,7 +6,7 @@ Keeping it working and up to date – and improving it continuously – would no This guide shows how you can contribute to {term}`Nix`, {term}`Nixpkgs` or {term}`NixOS`. It assumes that you're already somewhat proficient with basic concepts and workflows, which are outlined in the [beginner tutorial series](tutorials). -The most important aspects are [the Nix language](reading-nix-language), the various Nixpkgs mechanisms for [constructing derivations to build software](packaging-tutorial), [the module system](module-system-tutorial), and [NixOS integration tests](integration-testing-vms). +The most important aspects are [the Nix language](reading-nix-language), the various Nixpkgs mechanisms for [constructing derivations to build software](packaging-tutorial), [the module system](module-system-tutorial), and [NixOS integration tests](integration-testing-vms). :::{important} If you cannot contribute time, consider [donating to the NixOS Foundation on Open Collective](https://opencollective.com/nixos). @@ -17,7 +17,7 @@ With enough budget, it would be possible to pay for ongoing maintenance and deve ## Getting started -Start with asking informed questions, after reading [reference documentation](reference) and the code relevant to what you care about. +Start by asking informed questions, after reading [reference documentation](reference) and the code relevant to what you care about. [Join our community communication platforms](https://nixos.org/community) to get in contact with other users and developers. Check out and consider participating in our [community teams](https://nixos.org/community/#governance-teams) if you're interested in a particular topic. @@ -43,7 +43,7 @@ And it will lead to better code and documentation in the long run. :::{note} For asking general questions about the code or how to do things, please use our [community communication platforms](https://nixos.org/community) -To state techincal problems and propose solutions, open GitHub issues and close them when the problem is resolved or invalidated. +To state technical problems and propose solutions, open GitHub issues and close them when the problem is resolved or invalidated. ::: We can only fix issues that we know of, so please report any issue you encounter. @@ -78,7 +78,7 @@ The perfect issue is, in fact, a pull request that solves the problem directly a ::: :::{important} -Please open issues to request new features (such as packages, modules, commands, ...) only if your are willing and able to implement them yourself. +Please open issues to request new features (such as packages, modules, commands, ...) only if you are willing and able to implement them yourself. Then the issue can be used to gauge user interest, to determine if the feature fits into the project, and to discuss implementation strategies. ::: @@ -119,4 +119,4 @@ If you know your way around, working on [popular issues][nixos issues] will be h # How to get help -If you prepared a pull request and need help moving forward, check [](contributing-how-to-get-help) for +If you prepared a pull request and need help moving forward, check [contributing-how-to-get-help](https://nix.dev/contributing/how-to-get-help#contributing-how-to-get-help) for more information. diff --git a/source/contributing/how-to-get-help.md b/source/contributing/how-to-get-help.md index 77cc747a2..6b4bab76d 100644 --- a/source/contributing/how-to-get-help.md +++ b/source/contributing/how-to-get-help.md @@ -6,7 +6,7 @@ can go for help. ## How to find maintainers -For better efficiency and higher chance of success, you should try contacting individuals or groups with more specific knowledge first: +For better efficiency and a higher chance of success, you should try contacting individuals or groups with more specific knowledge first: - If your contribution is for a package in Nixpkgs, look for its maintainers in the [`maintainers`](https://nixos.org/manual/nixpkgs/stable/#var-meta-maintainers) @@ -28,7 +28,7 @@ Once you've found the people you're looking for, you can contact them on one of All the source code is maintained on GitHub. This is the right place to discuss implementation details. - In issue comments or pull request descriptions, [mention the GitHub username](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams) found in the [`maintainers-list.nix` file][maintainers-list]. + In issue comments or pull request descriptions, [mention the GitHub username](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams) found in the [`maintainers-list.nix` file](https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix). - [Discourse](https://discourse.nixos.org) diff --git a/source/guides/best-practices.md b/source/guides/best-practices.md index 35f27b42e..ab593fef3 100644 --- a/source/guides/best-practices.md +++ b/source/guides/best-practices.md @@ -5,7 +5,7 @@ The Nix language syntax supports bare URLs, so one could write `https://example.com` instead of `"https://example.com"` [RFC 45](https://github.com/NixOS/rfcs/pull/45) was accepted to deprecate unquoted URLs and provides -a number of arguments how this feature does more harm than good. +a number of arguments for how this feature does more harm than good. :::{tip} Always quote URLs. @@ -31,7 +31,7 @@ rec { { a = 1; b = 3; } ``` -A common pitfall is to introduce a hard to debug error `infinite recursion` when shadowing a name. +A common pitfall is to introduce a hard-to-debug error `infinite recursion` when shadowing a name. The simplest example for this is: ```{code-block} nix @@ -135,7 +135,7 @@ You will often encounter Nix language code samples that refer to ``. [introduced in 2011]: https://github.com/NixOS/nix/commit/1ecc97b6bdb27e56d832ca48cdafd3dbb5185a04 [`$NIX_PATH`]: https://nix.dev/manual/nix/stable/command-ref/env-common.html#env-NIX_PATH -This means, the value of a lookup path depends on external system state. +This means the value of a lookup path depends on external system state. When using lookup paths, the same Nix expression can produce different results. In most cases, `$NIX_PATH` is set to the latest channel when Nix is installed, and is therefore likely to differ from machine to machine. @@ -177,12 +177,12 @@ import {} ``` However, even when `` is replaced as shown in [](pinning-nixpkgs), the result may still not be fully reproducible. -This is because, for historical reasons, the [Nixpkgs top-level expression] by default impurely reads from the file system to obtain configuration parameters. +This is because for historical reasons the [Nixpkgs top-level expression] by default impurely reads from the file system to obtain configuration parameters. Systems that have the appropriate files populated may end up with different results. [Nixpkgs top-level expression]: https://github.com/NixOS/nixpkgs/blob/master/default.nix -It is a well-known problem that can't be resolved without breaking existing setups. +It is a well-known problem that cannot be resolved without breaking existing setups. :::{tip} Explicitly set [`config`](https://nixos.org/manual/nixpkgs/stable/#chap-packageconfig) and [`overlays`](https://nixos.org/manual/nixpkgs/stable/#chap-overlays) when importing Nixpkgs: diff --git a/source/guides/faq.md b/source/guides/faq.md index 7904a296d..95c346f96 100644 --- a/source/guides/faq.md +++ b/source/guides/faq.md @@ -11,7 +11,7 @@ Please refer to its source repository for installation instructions. ### How to convert between paths and strings in the Nix language? -See the Nix reference manual on [string interpolation](https://nix.dev/manual/nix/2.19/language/string-interpolation) and [operators on paths and strings](https://nix.dev/manual/nix/2.19/language/operators#string-concatenation) +See the Nix reference manual on [string interpolation](https://nix.dev/manual/nix/2.19/language/string-interpolation) and [operators on paths and strings](https://nix.dev/manual/nix/2.19/language/operators#string-concatenation). ### How to build reverse dependencies of a package? @@ -87,7 +87,7 @@ See ### How do I connect to any of the machines in NixOS tests? -Apply following patch: +Apply the following patch: ```diff diff --git a/nixos/lib/test-driver/test-driver.pl b/nixos/lib/test-driver/test-driver.pl diff --git a/source/guides/index.md b/source/guides/index.md index 1f7dbd806..20b99dca6 100644 --- a/source/guides/index.md +++ b/source/guides/index.md @@ -1,7 +1,7 @@ (guides)= # Guides -These sections contains guides to getting things done. +These sections contain guides to getting things done. ```{toctree} :glob: diff --git a/source/guides/recipes/continuous-integration-github-actions.md b/source/guides/recipes/continuous-integration-github-actions.md index 0cc50fee3..4f2fd3c33 100644 --- a/source/guides/recipes/continuous-integration-github-actions.md +++ b/source/guides/recipes/continuous-integration-github-actions.md @@ -15,7 +15,7 @@ One benefit of Nix is that **CI can build and cache developer environments for e An important aspect of CI is the feedback loop of, **how many minutes does the build take to finish?** -There are a several good options, but Cachix (below) is the most straightforward. +There are several good options, but Cachix (below) is the most straightforward. ## Caching builds using Cachix @@ -27,7 +27,7 @@ Before each job, derivations to be built are first substituted (if they exist) f ### 1. Creating your first binary cache -It's recommended to have different binary caches per team, depending who will have write/read access to it. +It's recommended to have different binary caches per team, depending on who will have write/read access to it. Fill out the form on the [create binary cache](https://app.cachix.org/cache) page. @@ -75,7 +75,7 @@ you should see status checks appearing on commits and PRs. ## Next steps - See [GitHub Actions workflow syntax](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions) -- To quickly setup a Nix project read through +- To quickly set up a Nix project read through [Getting started Nix template](https://github.com/nix-dot-dev/getting-started-nix-template). [github-actions-caching-limits]: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows diff --git a/source/guides/recipes/dependency-management.md b/source/guides/recipes/dependency-management.md index f7107e7ea..bff9dbff8 100644 --- a/source/guides/recipes/dependency-management.md +++ b/source/guides/recipes/dependency-management.md @@ -73,7 +73,7 @@ $ nix-shell [nix-shell]$ npins add github nixos nixpkgs --branch nixos-21.11 ``` -Create a file `default.nix` in the new directory, and import the original one with the `sources` just created. +Create a file `default.nix` in the new directory to import the original one with the `sources` you just created. ```nix import ../default.nix { sources = import ./npins; } diff --git a/source/guides/recipes/direnv.md b/source/guides/recipes/direnv.md index 63c6ba08a..5e834d6c5 100644 --- a/source/guides/recipes/direnv.md +++ b/source/guides/recipes/direnv.md @@ -21,13 +21,13 @@ pkgs.mkShellNoCC { } ``` -From the top-level directory of your project run: +From the top-level directory of your project, run: ```shell-session $ echo "use nix" > .envrc && direnv allow ``` -The next time you launch your terminal and enter the top-level directory of your project, `direnv` will automatically launch the shell defined in `shell.nix` +The next time you launch your terminal and enter the top-level directory of your project, `direnv` will automatically launch the shell defined in `shell.nix`. ```shell-session $ cd myproject diff --git a/source/guides/recipes/post-build-hook.md b/source/guides/recipes/post-build-hook.md index 67d5833d5..58f0966f5 100644 --- a/source/guides/recipes/post-build-hook.md +++ b/source/guides/recipes/post-build-hook.md @@ -75,7 +75,7 @@ Set the [`post-build-hook`](https://nix.dev/manual/nix/2.22/command-ref/conf-fil post-build-hook = /etc/nix/upload-to-cache.sh ``` -Then restart the `nix-daemon` an all involved machines, e.g. with +Then restart the `nix-daemon` on all involved machines, e.g. with ``` pkill nix-daemon diff --git a/source/guides/recipes/python-environment.md b/source/guides/recipes/python-environment.md index f8b1aad22..32992e613 100644 --- a/source/guides/recipes/python-environment.md +++ b/source/guides/recipes/python-environment.md @@ -2,7 +2,7 @@ # Setting up a Python development environment In this example you will build a Python web application using the [Flask](https://flask.palletsprojects.com) web framework as an exercise. -To make best use of it you should be familiar with [defining declarative shell environments](declarative-reproducible-envs). +To make the best use of it, you should be familiar with [defining declarative shell environments](declarative-reproducible-envs). Create a new file called `myapp.py` and add the following code: diff --git a/source/guides/recipes/sharing-dependencies.md b/source/guides/recipes/sharing-dependencies.md index d5a8abdd8..45d578a4e 100644 --- a/source/guides/recipes/sharing-dependencies.md +++ b/source/guides/recipes/sharing-dependencies.md @@ -1,7 +1,7 @@ (sharing-dependencies)= # Dependencies in the development shell -When [packaging software in `default.nix`](packaging-tutorial), you'll want a [development environment in `shell.nix`](declarative-reproducible-envs) to enter it conveniently with `nix-shell` or [automatically with `direnv`](./direnv). +When [packaging software in `default.nix`](packaging-tutorial), you'll want a [development environment in `shell.nix`](declarative-reproducible-envs) to enter conveniently with `nix-shell` or [automatically with `direnv`](./direnv). How to share the package's dependencies in `default.nix` with the development environment in `shell.nix`? diff --git a/source/guides/troubleshooting.md b/source/guides/troubleshooting.md index 6df8e7060..dd700b7a8 100644 --- a/source/guides/troubleshooting.md +++ b/source/guides/troubleshooting.md @@ -1,6 +1,6 @@ # Troubleshooting -This page is a collection of tips to solve problems you may encounter using Nix. +This page is a collection of tips to solve problems you may encounter when using Nix. ## What to do if a binary cache is down or unreachable? @@ -34,7 +34,7 @@ $ sqlite3 /nix/var/nix/db/db.sqlite-bkp ".dump" | sqlite3 /nix/var/nix/db/db.sql This is a [known issue](https://github.com/NixOS/nix/issues/1251). -It means that using a new version of Nix upgraded the SQLite schema of the [database](https://nix.dev/manual/nix/stable/glossary#gloss-nix-database), and then you tried to use an older version Nix. +It means that using a new version of Nix upgraded the SQLite schema of the [database](https://nix.dev/manual/nix/stable/glossary#gloss-nix-database), and then you tried to use an older version of Nix. The solution is to dump the database, and use the old Nix version to re-import the data: @@ -47,7 +47,7 @@ $ nix-store --load-db < /tmp/db.dump ## How to fix: `writing to file: Connection reset by peer` -This may mean you are trying to import a too large file or directory into the [Nix store](https://nix.dev/manual/nix/stable/glossary#gloss-store), or your machine is running out of resources, such as disk space or memory. +This may mean you are trying to import too large a file or directory into the [Nix store](https://nix.dev/manual/nix/stable/glossary#gloss-store), or your machine is running out of resources, such as disk space or memory. Try to reduce the size of the directory to import, or run [garbage collection](https://nix.dev/manual/nix/stable/command-ref/nix-collect-garbage). diff --git a/source/install-nix.md b/source/install-nix.md index f06bd3d7a..c45939226 100644 --- a/source/install-nix.md +++ b/source/install-nix.md @@ -2,7 +2,7 @@ # Install Nix Requirements: - - Prior to installation, you might need to first install `xz-utils` or similar for uncompressing the Nix binary tarball (`.tar.xz`) that will be downloaded via the scripts below. + - Prior to installation, you might first need to install `xz-utils` or similar for decompressing the Nix binary tarball (`.tar.xz`) that will be downloaded via the scripts below. :::::{tab-set} @@ -29,7 +29,7 @@ $ curl -L https://nixos.org/nix/install | sh :::{important} **Updating to macOS 15 Sequoia** -If you recently updated to macOS 15 Sequoia and are getting +If you recently updated to macOS 15 Sequoia and are getting the error ```console error: the user '_nixbld1' in the group 'nixbld' does not exist ``` @@ -71,7 +71,7 @@ $ mkdir workdir $ docker run -it -v $(pwd)/workdir:/workdir nixos/nix ``` -The `workdir` example from above can be also used to start hacking on Nixpkgs: +The `workdir` example from above can also be used to start hacking on Nixpkgs: ```shell-session $ git clone git@github.com:NixOS/nixpkgs diff --git a/source/recommended-reading.md b/source/recommended-reading.md index c6a83aa3d..5a4726228 100644 --- a/source/recommended-reading.md +++ b/source/recommended-reading.md @@ -38,7 +38,7 @@ - [Nix Shorts](https://github.com/justinwoo/nix-shorts) - A series of posts on basics of how packaging with Nix works. + A series of posts on the basics of how packaging with Nix works. - [NixOS and Flakes - An unofficial book for beginners](https://nixos-and-flakes.thiscute.world) (2023) diff --git a/source/reference/index.md b/source/reference/index.md index 8d698dbf2..7739ff2f6 100644 --- a/source/reference/index.md +++ b/source/reference/index.md @@ -1,7 +1,7 @@ (reference)= # Reference -These sections contains collections of detailed technical descriptions. +These sections contain collections of detailed technical descriptions. ```{toctree} :glob: diff --git a/source/reference/pinning-nixpkgs.md b/source/reference/pinning-nixpkgs.md index de02cda25..004ea9b5a 100644 --- a/source/reference/pinning-nixpkgs.md +++ b/source/reference/pinning-nixpkgs.md @@ -5,7 +5,7 @@ Specifying remote Nix expressions, such as the one provided by Nixpkgs, can be done in several ways: - [`$NIX_PATH` environment variable](https://nix.dev/manual/nix/stable/command-ref/env-common.html#env-NIX_PATH) -- [`-I` option](https://nix.dev/manual/nix/stable/command-ref/opt-common.html#opt-I) to most of commands like `nix-build`, `nix-shell`, etc. +- [`-I` option](https://nix.dev/manual/nix/stable/command-ref/opt-common.html#opt-I) to most commands like `nix-build`, `nix-shell`, etc. - [`fetchurl`](https://nix.dev/manual/nix/stable/language/builtins.html#builtins-fetchurl), [`fetchTarball`](https://nix.dev/manual/nix/stable/language/builtins.html#builtins-fetchTarball), [`fetchGit`](https://nix.dev/manual/nix/stable/language/builtins.html#builtins-fetchGit) or [Nixpkgs fetchers](https://nixos.org/manual/nixpkgs/stable/#chap-pkgs-fetchers) in Nix expressions ## Possible URL values diff --git a/source/tutorials/callpackage.md b/source/tutorials/callpackage.md index fd88c3e0e..00962ee11 100644 --- a/source/tutorials/callpackage.md +++ b/source/tutorials/callpackage.md @@ -265,10 +265,10 @@ But this benefit really pays off for large constructions, where it is the amount ## Summary -Using `callPackage` does not only follow Nixpkgs conventions, which makes your code easier to follow for experienced Nix users, but it also gives you some benefits for free: +Using `callPackage` not only follows Nixpkgs conventions, which makes your code easier to follow for experienced Nix users, but it also gives you some benefits for free: 1. Parametrized builds -2. Overrideable builds +2. Overridable builds 3. Concise implementation of interdependent package sets ## References diff --git a/source/tutorials/cross-compilation.md b/source/tutorials/cross-compilation.md index 3549190e6..78a550dad 100644 --- a/source/tutorials/cross-compilation.md +++ b/source/tutorials/cross-compilation.md @@ -167,7 +167,7 @@ There are multiple equivalent ways to access packages targeted to the host platf ``` 2. Pass the host platform to `crossSystem` when importing `nixpkgs`. - This configures `nixpkgs` such that all its packages are build for the host platform: + This configures `nixpkgs` such that all its packages are built for the host platform: ```nix let @@ -312,6 +312,6 @@ hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically link Additionally, supporting cross compilation is not trivial work and due to many possible combinations of what would need to be tested, some packages might not build. - [A detailed explanation how of cross compilation is implemented in Nix](https://nixos.org/manual/nixpkgs/stable/#chap-cross) can help with fixing those issues. + [A detailed explanation of how cross compilation is implemented in Nix](https://nixos.org/manual/nixpkgs/stable/#chap-cross) can help with fixing those issues. - The Nix community has a [dedicated Matrix room](https://matrix.to/#/#cross-compiling:nixos.org) for help with cross compiling. diff --git a/source/tutorials/first-steps/ad-hoc-shell-environments.md b/source/tutorials/first-steps/ad-hoc-shell-environments.md index 8b9fe8509..0042b2364 100644 --- a/source/tutorials/first-steps/ad-hoc-shell-environments.md +++ b/source/tutorials/first-steps/ad-hoc-shell-environments.md @@ -123,7 +123,7 @@ these 151 paths will be fetched (186.43 MiB download, 1018.20 MiB unpacked): (check-package-version)= ### Check package versions -Check that you have indeed the specific version of these programs provided by Nix, even if you had any of them already installed on your machine. +Check that you have the specific version of these programs provided by Nix, even if you had any of them already installed on your machine. ```shell-session [nix-shell:~]$ which git diff --git a/source/tutorials/first-steps/declarative-shell.md b/source/tutorials/first-steps/declarative-shell.md index 74591f370..cb8de03ed 100644 --- a/source/tutorials/first-steps/declarative-shell.md +++ b/source/tutorials/first-steps/declarative-shell.md @@ -81,13 +81,13 @@ in We explicitly set `config` and `overlays` to avoid them being inadvertently overridden by [global configuration](https://nixos.org/manual/nixpkgs/stable/#chap-packageconfig). -`mkShellNoCC` is a function that takes as argument an attribute set. +`mkShellNoCC` is a function that takes as an argument an attribute set. Here we give it an attribute `packages` with a list containing two items from the `pkgs` attribute set. :::{Dropdown} Side note on `mkShell` `nix-shell` and `mkShell` were originally conceived as a way to construct a shell environment containing the [tools needed to debug package builds](https://nixos.org/manual/nixpkgs/stable/#sec-tools-of-stdenv), such as Make or GCC. -Only later it became widely used as a general way to make temporary environments for other purposes. +Only later did it become widely used as a general way to make temporary environments for other purposes. `mkShellNoCC` is a function that produces such an environment, but without a compiler toolchain. You may encounter examples of `mkShell` or `mkShellNoCC` that add packages to the `buildInputs` or `nativeBuildInputs` attributes instead. diff --git a/source/tutorials/first-steps/index.md b/source/tutorials/first-steps/index.md index 7a7087ff2..8a4aae7fe 100644 --- a/source/tutorials/first-steps/index.md +++ b/source/tutorials/first-steps/index.md @@ -5,7 +5,7 @@ This tutorial series is where you should start learning Nix. In these lessons, you will use basic Nix commands to obtain almost any piece of software, create development environments on the fly, and learn how to make reproducible scripts. -You will also learn reading the Nix language, and later use it to build portable, reproducible development environments. +You will also learn to read the Nix language, and later use it to build portable, reproducible development environments. ```{toctree} :maxdepth: 1 diff --git a/source/tutorials/first-steps/reproducible-scripts.md b/source/tutorials/first-steps/reproducible-scripts.md index 550990617..051f70e28 100644 --- a/source/tutorials/first-steps/reproducible-scripts.md +++ b/source/tutorials/first-steps/reproducible-scripts.md @@ -81,7 +81,7 @@ The additional shebang lines are a Nix-specific construct: - The parameter of `-I` refers to a specific Git commit of the Nixpkgs repository. - This ensures that the script will always run with the exact same packages versions, everywhere. + This ensures that the script will always run with the exact same package versions, everywhere. Make the script executable: diff --git a/source/tutorials/index.md b/source/tutorials/index.md index deff72304..c62bfe446 100644 --- a/source/tutorials/index.md +++ b/source/tutorials/index.md @@ -1,7 +1,7 @@ (tutorials)= # Tutorials -These sections contains series of lessons to get started. +These sections contain a series of lessons to get started. ```{toctree} :glob: diff --git a/source/tutorials/module-system/deep-dive.md b/source/tutorials/module-system/deep-dive.md index 40d5a30eb..7a773209b 100644 --- a/source/tutorials/module-system/deep-dive.md +++ b/source/tutorials/module-system/deep-dive.md @@ -9,7 +9,7 @@ In this tutorial you will follow an extensive demonstration of how to wrap an ex This tutorial follows [@infinisil](https://github.com/infinisil)'s [presentation on modules](https://infinisil.com/modules.mp4) ([source](https://github.com/tweag/summer-of-nix-modules)) for participants of [Summer of Nix](https://github.com/ngi-nix/summer-of-nix) 2021. -It may help playing it alongside this tutorial to better keep track of changes to the code you will work on. +It may help to play it alongside this tutorial to better keep track of changes to the code you will work on. ### What will you learn? @@ -245,8 +245,8 @@ This command does the following: ## Declaring more options -Rather than setting all script parameters directly, we will to do that through the module system. -This will not just add some safety through type checking, but also allow to build abstractions to manage growing complexity and changing requirements. +Rather than setting all script parameters directly, we will do that through the module system. +This will not just add some safety through type checking, but also allow building abstractions to manage growing complexity and changing requirements. Let's begin by introducing another option, `requestParams`, which will represent the parameters of the request made to the Google Maps API. @@ -350,7 +350,7 @@ Lazy evaluation in the Nix language allows the module system to make a value ava The result of this represents the list of command line arguments to pass to the `./map` script. ## Conditional definitions -Sometimes, you will want option values to be, well, optional. This can be useful when defining a value for an option is not required, as in the following case. +Sometimes, you will want option values to be optional. This can be useful when defining a value for an option is not required, as in the following case. You will define a new option, `map.zoom`, to control the zoom level of the map. The Google Maps API will infer a zoom level if no corresponding argument is passed, a situation you can represent with the `nullOr `, which represents values of type `` or `null`. This _does not_ automatically mean that when the option isn't defined, the value of such an option is `null` -- we still need to define a default value. @@ -796,7 +796,7 @@ Here you will use two new type-functions for this: - `either `, which takes two types as arguments, and allows either of them - `enum [ ]`, which takes a list of allowed values, and allows any of them -In the `let` block, add the following `colorType` option, which can hold strings containing either some given color names or an RGB value add the new compound type: +In the `let` block, add the following `colorType` option, which can hold strings containing either some given color names or an RGB value, add the new compound type: ```{code-block} diff :caption: marker.nix @@ -1038,7 +1038,7 @@ Your users have spoken, and they demand the ability to customize the styles of t As before, you'll now declare a new submodule for the path style. -While you could also directly declare the `style.weight` option, in this case you should use the submodule to be able reuse the path style type later. +While you could also directly declare the `style.weight` option, in this case you should use the submodule to be able to reuse the path style type later. Add the `pathStyleType` submodule option to the `let` block in `path.nix`: ```{code-block} diff @@ -1099,7 +1099,7 @@ Finally, update the `attributes` list in `paramForPath`: ## The `pathStyle` submodule -Users still can't actually customize the path style yet. +Users still cannot actually customize the path style yet. Introduce a new `pathStyle` option for each user. The module system allows you to declare values for an option multiple times, and if the types permit doing so, takes care of merging each declaration's values together. diff --git a/source/tutorials/module-system/index.md b/source/tutorials/module-system/index.md index 7b5e10763..44fbd7a68 100644 --- a/source/tutorials/module-system/index.md +++ b/source/tutorials/module-system/index.md @@ -5,7 +5,7 @@ Much of the power in Nixpkgs and NixOS comes from the module system. The module system is a Nix language library that enables you to - Declare one attribute set using many separate Nix expressions. -- Impose type constraints on values in that attribute set. +- Imposes type constraints on values in that attribute set. - Define values for the same attribute in different Nix expressions and merge these values automatically according to their type. These Nix expressions are called modules and must have a particular structure. diff --git a/source/tutorials/nix-language.md b/source/tutorials/nix-language.md index 1f3c19913..996e3db11 100644 --- a/source/tutorials/nix-language.md +++ b/source/tutorials/nix-language.md @@ -26,7 +26,7 @@ You may quickly encounter Nix language expressions that look very complicated. As with any programming language, the required amount of Nix language code closely matches the complexity of the problem it is supposed to solve, and reflects how well the problem – and its solution – is understood. Building software is a complex undertaking, and Nix both *exposes* and *allows managing* this complexity with the Nix language. -Yet, the Nix language itself has only few basic concepts that will be introduced in this tutorial, and which can be combined arbitrarily. +Yet, the Nix language itself has only a few basic concepts that will be introduced in this tutorial, and which can be combined arbitrarily. What may look complicated comes not from the language, but from how it is used. ## Overview @@ -211,7 +211,7 @@ It is otherwise insignificant. [lexical tokens]: https://en.wikipedia.org/wiki/Lexical_analysis#Lexical_token_and_lexical_tokenization -Line breaks, indentation, and additional spaces are for readers' convenience. +Line breaks, indentation, and additional spaces are for the reader's convenience. The following are equivalent: @@ -1329,7 +1329,7 @@ f 1 2 ### Attribute set argument -Also known as “keyword arguments” or “destructuring” . +Also known as “keyword arguments” or “destructuring”. Nix functions can be declared to require an attribute set with specific structure as argument. @@ -1979,7 +1979,7 @@ This example declares a shell environment (which runs the `shellHook` on initial Explanation: -- This expression is a function that takes an attribute set as an argument. +- This expression is a function that takes an attribute set as its argument. - If the argument has the attribute `pkgs`, it will be used in the function body. Otherwise, by default, import the Nix expression in the file found on the lookup path `` (which is a function in this case), call the function with an empty attribute set, and use the resulting value. - The name `message` is bound to the string value `"hello world"`. diff --git a/source/tutorials/nixos/binary-cache-setup.md b/source/tutorials/nixos/binary-cache-setup.md index 2ec6d54f1..24e67bdfb 100644 --- a/source/tutorials/nixos/binary-cache-setup.md +++ b/source/tutorials/nixos/binary-cache-setup.md @@ -32,7 +32,7 @@ You'll learn how to: - (optional) A public IP and DNS domain - If you don't host yourself, check [NixOS friendly hosters](https://wiki.nixos.org/wiki/NixOS_friendly_hosters) on the NixOS Wiki. + If you don't host yourself, check [NixOS-friendly hosters](https://wiki.nixos.org/wiki/NixOS_friendly_hosters) on the NixOS Wiki. Follow the tutorial on [](provisioning-remote-machines-tutorial) to deploy your NixOS configuration. For a cache on a local network, we assume: @@ -107,7 +107,7 @@ nixos-rebuild switch --no-flake --target-host root@cache ``` :::{note} -The binary cache daemon will report errors because there is no secret key file, yet. +The binary cache daemon will report errors because there is no secret key file yet. ::: ## Generate a signing key pair diff --git a/source/tutorials/nixos/building-bootable-iso-image.md b/source/tutorials/nixos/building-bootable-iso-image.md index d4d219434..d4f1c578d 100644 --- a/source/tutorials/nixos/building-bootable-iso-image.md +++ b/source/tutorials/nixos/building-bootable-iso-image.md @@ -38,5 +38,5 @@ $ sync ## Next steps -- Take a look at this [list of formats that generators support](https://github.com/nix-community/nixos-generators#user-content-supported-formats) to find your cloud provider or virtualization technology. +- Take a look at this [list of formats that the generators support](https://github.com/nix-community/nixos-generators#user-content-supported-formats) to find your cloud provider or virtualization technology. - Take a look at the [alternative guide to create a NixOS live CD](https://wiki.nixos.org/wiki/Creating_a_NixOS_live_CD) diff --git a/source/tutorials/nixos/deploying-nixos-using-terraform.md b/source/tutorials/nixos/deploying-nixos-using-terraform.md index 6adf17ece..819cc8f4f 100644 --- a/source/tutorials/nixos/deploying-nixos-using-terraform.md +++ b/source/tutorials/nixos/deploying-nixos-using-terraform.md @@ -109,7 +109,7 @@ module "nixos_image" { :::{note} The `aws_image_nixos` module will return a NixOS AMI given a [NixOS release number](https://status.nixos.org) -so that the `aws_instance` resource can reference the AMI in [instance_type](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#instance_type) argument. +so that the `aws_instance` resource can reference the AMI in the [instance_type](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#instance_type) argument. ::: 5. Make sure to [configure AWS credentials](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication). diff --git a/source/tutorials/nixos/distributed-builds-setup.md b/source/tutorials/nixos/distributed-builds-setup.md index 933569911..90afc994b 100644 --- a/source/tutorials/nixos/distributed-builds-setup.md +++ b/source/tutorials/nixos/distributed-builds-setup.md @@ -233,7 +233,7 @@ Activate the new configuration as `root`: ## Test distributed builds -Try building an new derivation on the *local machine*: +Try building a new derivation on the *local machine*: ```shell-session $ nix-build --max-jobs 0 -E << EOF diff --git a/source/tutorials/nixos/integration-testing-using-virtual-machines.md b/source/tutorials/nixos/integration-testing-using-virtual-machines.md index 5045bd0ab..9b0a2a99e 100644 --- a/source/tutorials/nixos/integration-testing-using-virtual-machines.md +++ b/source/tutorials/nixos/integration-testing-using-virtual-machines.md @@ -95,7 +95,7 @@ We will build the example up from scratch. 1. Because this example only uses one virtual machine, the node we specify is simply called `machine`. This name is arbitrary and can be chosen freely. - As configuration you use the relevant parts of the default configuration, [that we used in a previous tutorial](): + As configuration you use the relevant parts of the default configuration, [which we used in a previous tutorial](): ```nix nodes.machine = { config, pkgs, ... }: { @@ -205,7 +205,7 @@ or ``` for all nodes. -You can enter a interactive shell on the virtual machine using: +You can enter an interactive shell on the virtual machine using: ```shell-session >>> machine.shell_interact() diff --git a/source/tutorials/nixos/nixos-configuration-on-vm.md b/source/tutorials/nixos/nixos-configuration-on-vm.md index 4b6723991..5581b8729 100644 --- a/source/tutorials/nixos/nixos-configuration-on-vm.md +++ b/source/tutorials/nixos/nixos-configuration-on-vm.md @@ -8,7 +8,7 @@ NixOS configurations can be used to test and use NixOS using a virtual machine, ## What will you learn? -This tutorial serves as an introduction creating NixOS virtual machines. +This tutorial serves as an introduction to creating NixOS virtual machines. Virtual machines are a practical tool for experimenting with or debugging NixOS configurations. ## What do you need? diff --git a/source/tutorials/nixos/provisioning-remote-machines.md b/source/tutorials/nixos/provisioning-remote-machines.md index 928dc83b5..d83df7978 100644 --- a/source/tutorials/nixos/provisioning-remote-machines.md +++ b/source/tutorials/nixos/provisioning-remote-machines.md @@ -40,7 +40,7 @@ For a successful unattended installation, ensure for the *target machine* that: - The IP address is configured automatically with DHCP - You can login via SSH - - With public key authentication (prefered), or password + - With public key authentication (preferred), or password - As user `root` or another user with `sudo` permissions The *local machine* only needs a working [Nix installation](install-nix). diff --git a/source/tutorials/packaging-existing-software.md b/source/tutorials/packaging-existing-software.md index 8b61639ea..6b452ae4e 100644 --- a/source/tutorials/packaging-existing-software.md +++ b/source/tutorials/packaging-existing-software.md @@ -62,7 +62,7 @@ This is a function which takes an attribute set containing `stdenv`, and produce GNU Hello is an implementation of the "hello world" program, with source code accessible [from the GNU Project's FTP server](https://ftp.gnu.org/gnu/hello/). To begin, add a `pname` attribute to the set passed to `mkDerivation`. -Every package needs a name and a version, and Nix will throw `error: derivation name missing` without. +Every package needs a name and a version, and Nix will throw `error: derivation name missing` without one. ```diff @@ -141,7 +141,7 @@ This allows you to run `nix-build -A hello` to realize the derivation in `hello. :::{note} `callPackage` automatically passes attributes from `pkgs` to the given function, if they match attributes required by that function's argument attribute set. -In this case, `callPackage` will supply `stdenv`, and `fetchzip` to the function defined in `hello.nix`. +In this case, `callPackage` will supply `stdenv` and `fetchzip` to the function defined in `hello.nix`. The tutorial [](./callpackage.md) goes into detail on how this works. :::