From 3f6eb45c9713d7f98796d148d425da6dc3129160 Mon Sep 17 00:00:00 2001 From: Pavel Roskin Date: Mon, 19 Feb 2024 21:14:06 -0800 Subject: [PATCH] Fix typos --- book.xml | 2 +- pills/03-enter-environment.xml | 2 +- pills/04-basics-of-language.xml | 2 +- pills/05-functions-and-imports.xml | 16 ++++++++-------- pills/06-our-first-derivation.xml | 6 +++--- pills/08-generic-builders.xml | 6 +++--- pills/09-automatic-runtime.xml | 8 ++++---- pills/10-developing-with-nix-shell.xml | 8 ++++---- pills/11-garbage-collector.xml | 20 ++++++++++---------- pills/12-inputs-design-pattern.xml | 16 ++++++++-------- pills/13-callpackage-design-pattern.xml | 12 ++++++------ pills/14-override-design-pattern.xml | 4 ++-- pills/15-nix-search-paths.xml | 8 ++++---- pills/16-nixpkgs-parameters.xml | 8 ++++---- pills/17-nixpkgs-overriding-packages.xml | 10 +++++----- pills/20-basic-dependencies-and-hooks.xml | 4 ++-- 16 files changed, 66 insertions(+), 66 deletions(-) diff --git a/book.xml b/book.xml index a160181..2a7a245 100644 --- a/book.xml +++ b/book.xml @@ -16,7 +16,7 @@ This is a ported version of the Nix Pills, a series of blog posts written by Luca Bruno (aka Lethalman) and - orginally published in 2014 and 2015. It provides a tutorial + originally published in 2014 and 2015. It provides a tutorial introduction into the Nix package manager and Nixpkgs package collection, in the form of short chapters called 'pills'. diff --git a/pills/03-enter-environment.xml b/pills/03-enter-environment.xml index ebeb6b1..ccddacb 100644 --- a/pills/03-enter-environment.xml +++ b/pills/03-enter-environment.xml @@ -372,7 +372,7 @@ - Everytime we change the environment, a new generation is created. + Every time we change the environment, a new generation is created. Switching between generations is easy and immediate. diff --git a/pills/04-basics-of-language.xml b/pills/04-basics-of-language.xml index 09d9edc..545b6df 100644 --- a/pills/04-basics-of-language.xml +++ b/pills/04-basics-of-language.xml @@ -205,7 +205,7 @@ Attribute sets - Attribute sets are an association between string keys and a Nix values. Keys + An attribute set is an association between string keys and Nix values. Keys can only be strings. When writing attribute sets you can also use unquoted identifiers as keys. diff --git a/pills/05-functions-and-imports.xml b/pills/05-functions-and-imports.xml index 85281de..3a5639c 100644 --- a/pills/05-functions-and-imports.xml +++ b/pills/05-functions-and-imports.xml @@ -93,7 +93,7 @@ xml:id="functions-and-imports"> - You don't have to use parenthesis at all, Nix has sane priorities when + You don't have to use parentheses at all, Nix has sane priorities when parsing the code: @@ -102,7 +102,7 @@ xml:id="functions-and-imports"> Much more readable, you don't even notice that functions only receive one argument. Since the argument is separated by a space, to pass more complex - expressions you need parenthesis. In other common languages you would write + expressions you need parentheses. In other common languages you would write mul(6+7, 8+9). @@ -121,7 +121,7 @@ xml:id="functions-and-imports">
- Arguments set + Argument set Now this is a very cool feature of Nix. It is possible to pattern match over @@ -134,13 +134,13 @@ xml:id="functions-and-imports"> In the first case we defined a function that accepts a single parameter. We then access attributes a and - b from the given set. Note how the parenthesis-less syntax for + b from the given set. Note how the parentheses-less syntax for function calls is very elegant in this case, instead of doing mul({ a=3; b=4; }) in other languages. - In the second case we defined an arguments set. It's like defining a set, + In the second case we defined an argument set. It's like defining a set, except without values. We require that the passed set contains the keys a and b. Then we can use those a and b in the function body directly. @@ -160,7 +160,7 @@ xml:id="functions-and-imports"> It is possible to specify default values - of attributes in the arguments set: + of attributes in the argument set: @@ -264,7 +264,7 @@ xml:id="functions-and-imports"> - Yes it's really that simple. You import a file, and it gets parsed as + Yes it's really that simple. You import a file, and it gets parsed as an expression. Note that the scope of the imported file does not inherit the scope of the importer. @@ -324,7 +324,7 @@ xml:id="functions-and-imports"> - So when is the message shown? Only when it's in need to be evaluated. + So when is the message shown? Only when it needs to be evaluated.
diff --git a/pills/06-our-first-derivation.xml b/pills/06-our-first-derivation.xml index bf2855f..cad3f14 100644 --- a/pills/06-our-first-derivation.xml +++ b/pills/06-our-first-derivation.xml @@ -81,7 +81,7 @@ Oh oh, what's that? Did it build the derivation? No it didn't, but it did create the .drv file. nix repl does - not build derivations unless you tell to do so. + not build derivations unless you tell it to do so. @@ -342,7 +342,7 @@ - Apart the nixpkgs stuff, just think we added to the scope a series of + Apart from the nixpkgs stuff, just think we added to the scope a series of variables. One of them is coreutils. It is the derivation of the coreutils package you all know of from other Linux distributions. It contains basic binaries for GNU/Linux systems (you may have multiple derivations of @@ -387,7 +387,7 @@ - Obvious note: everytime we change the + Obvious note: every time we change the derivation, a new hash is created. diff --git a/pills/08-generic-builders.xml b/pills/08-generic-builders.xml index c7f2b43..aa5062d 100644 --- a/pills/08-generic-builders.xml +++ b/pills/08-generic-builders.xml @@ -123,7 +123,7 @@ As you can see, there's no reference to "hello" in the builder anymore. - It still does several assumptions, but it's certainly more generic. + It still makes several assumptions, but it's certainly more generic. @@ -134,7 +134,7 @@ All clear, except that buildInputs. However it's easier than any black - magic you are thinking in this moment. + magic you are thinking of at this moment. @@ -162,7 +162,7 @@ We managed to write a builder that can be used for multiple autotools projects. But in the hello.nix expression we are specifying tools that - are common to more projects; we don't want to pass them everytime. + are common to more projects; we don't want to pass them every time. diff --git a/pills/09-automatic-runtime.xml b/pills/09-automatic-runtime.xml index a8d370d..7af0c1b 100644 --- a/pills/09-automatic-runtime.xml +++ b/pills/09-automatic-runtime.xml @@ -102,7 +102,7 @@ - For each build dependency .drv and it's relative out path, + For each build dependency .drv and its relative out path, search the contents of the NAR for this out path. @@ -146,7 +146,7 @@ Even after reducing the rpath, the hello binary would still depend upon gcc because of some debugging information. This - unnecesarily increases the size of our runtime + unnecessarily increases the size of our runtime dependencies. We'll explore how strip can help us with that in the next section. @@ -218,7 +218,7 @@ - Now, we rebuild hello.nix:nd...: + Now, we rebuild hello.nix... @@ -252,7 +252,7 @@ We saw some of the tools Nix provides, along with their features. In particular, we saw how Nix is able to compute runtime dependencies automatically. This is not limited to only shared libraries, - but can also referenced executables, scripts, Python libraries, and so + but can also reference executables, scripts, Python libraries, and so forth. diff --git a/pills/10-developing-with-nix-shell.xml b/pills/10-developing-with-nix-shell.xml index 7c19da7..e5dd5c1 100644 --- a/pills/10-developing-with-nix-shell.xml +++ b/pills/10-developing-with-nix-shell.xml @@ -67,7 +67,7 @@ - This means the we can source our + This means that we can source our builder.sh, and it will build the derivation. You may get an error in the installation phase, because your user may not have the permission to write to /nix/store: @@ -122,7 +122,7 @@ First, when we sourced the builder.sh - file, we obtained the file in the currenty directory. What we really wanted + file, we obtained the file in the current directory. What we really wanted was the builder.sh that is stored in the nix store, as this is the file that would be used by nix-build. To achieve this, the correct technique is to pass an environment variable @@ -142,7 +142,7 @@ - During our refactoring, we ill wrap the build phases in functions to + During our refactoring, we will wrap the build phases in functions to give more structure to our design. Additionally, we'll move the set -e to the builder file instead of the setup file. The set -e is annoying in nix-shell, @@ -214,7 +214,7 @@ With nix-shell we are able to drop into an isolated environment suitable for developing a project. This environment provides the necessary dependencies for the development shell, similar to how - nix-build providesthe necessary dependencies to a builder. + nix-build provides the necessary dependencies to a builder. Additionally, we can build and debug the project manually, executing step-by-step like we would in any other operating system. Note that we never installed tools such gcc or make system-wide; these tools diff --git a/pills/11-garbage-collector.xml b/pills/11-garbage-collector.xml index 9698094..2132d69 100644 --- a/pills/11-garbage-collector.xml +++ b/pills/11-garbage-collector.xml @@ -8,7 +8,7 @@ Welcome to the 11th Nix pill. In the previous - 10th pill, we drew a + 10th pill, we drew a parallel between the isolated build environment provided by nix-build and the isolated development shell provided by nix-shell. Using nix-shell allowed us @@ -44,7 +44,7 @@ Instead of objects, Nix's garbage collection operates on store paths, with the GC roots themselves being store paths. -. This approach is much mode principled than traditional package +. This approach is much more principled than traditional package managers such as dpkg or rpm, which may leave around unused packages or dangling files. @@ -52,13 +52,13 @@ The implementation is very simple and transparent to the user. The primary GC roots are stored under /nix/var/nix/gcroots. If there - is a symlink to a store path, then linked store path is a GC root. + is a symlink to a store path, then the linked store path is a GC root. Nix allows this directory to have subdirectories: it will simply recursively traverse the subdirectories in search of symlinks to store paths. When - a symlink is encountered, it's target is added to the list of live store + a symlink is encountered, its target is added to the list of live store paths. @@ -90,7 +90,7 @@ We now install a new program, bsd-games, inspect its - store path, and examine it's GC root. The nix-store -q --roots + store path, and examine its GC root. The nix-store -q --roots command is used to query the GC roots that refer to a given derivation. In this case, our current user environment refers to bsd-games: @@ -131,7 +131,7 @@ /nix/var/nix/gcroots. In addition to the latter, Nix treats /nix/var/nix/profiles as a GC root. This is useful because it means that any profile and its generations - are GC roots. Other path are considered GC roots as well; for example, + are GC roots. Other paths are considered GC roots as well; for example, /run/booted-system on NixOS. The command nix-store --gc --print-roots prints all paths considered as GC roots when running the garbage collector. @@ -166,14 +166,14 @@ What is important is that such a symlink exists and points to /home/nix/result. This is called an indirect GC root. A GC root is - considred indirect if it's specification is outside of + considered indirect if its specification is outside of /nix/var/nix/gcroots. In this case, this means that the target of the result symlink will not be garbage collected. - To remove a deriviation considered "live" by an indirect GC root, + To remove a derivation considered "live" by an indirect GC root, there are two possibilities: @@ -211,7 +211,7 @@ The main source of software duplication in the nix store comes from GC roots, due to nix-build and profile generations. Running nix-build results in a GC root for the build - that refers to a specific version of specific libaries, such as + that refers to a specific version of specific libraries, such as glibc. After an upgrade, we must delete the previous build if we want the garbage collector to remove the corresponding derivation, as well as if we want old dependencies cleaned up. @@ -272,7 +272,7 @@ Conclusion - Garbage collection in Nix is a powerful mechanism to cleanup your system. + Garbage collection in Nix is a powerful mechanism to clean up your system. The nix-store commands allow us to know why a certain derivation is present in the nix store, and whether or not it is eligible for garbage collection. We also saw how to conduct more destructive deletion diff --git a/pills/12-inputs-design-pattern.xml b/pills/12-inputs-design-pattern.xml index 3911467..d2fa330 100644 --- a/pills/12-inputs-design-pattern.xml +++ b/pills/12-inputs-design-pattern.xml @@ -16,7 +16,7 @@
Repositories in Nix - Package repositories in Nix arose naturally from the need to organize pacakges. + Package repositories in Nix arose naturally from the need to organize packages. There is no preset directory structure or packaging policy prescribed by Nix itself; Nix, as a full, functional programming language, is powerful enough to support multiple different repository formats. @@ -25,7 +25,7 @@ Over time, the nixpkgs repository evolved a particular structure. This structure reflects the history of Nix as well as the design - patterns adopted by it's users as useful tools in building and organizing + patterns adopted by its users as useful tools in building and organizing packages. Below, we will examine some of these patterns in detail.
@@ -33,7 +33,7 @@ The single repository pattern Different operating system distributions have different opinions about how - package repositories should organized. Systems like Debian scatter packages + package repositories should be organized. Systems like Debian scatter packages in several small repositories (which tends to make tracking interdependent changes more difficult, and hinders contributions to the repositories), while systems like Gentoo put all package descriptions in a single repository. @@ -102,7 +102,7 @@ The graphviz configuration script uses pkg-config to specify which flags are passed to the compiler. Since there is no global location for libraries, we need to tell pkg-config where to find - it's description files, which tell the configuration script where to find + its description files, which tell the configuration script where to find headers and libraries. @@ -150,7 +150,7 @@ Now that we have two packages, we want to combine them into a single repository. To do so, we'll mimic what nixpkgs does: we will create a single attribute set containing derivations. This attribute set can - then be imported, and deriviations can be selected by accessing the + then be imported, and derivations can be selected by accessing the top-level attribute set. @@ -175,8 +175,8 @@ The default.nix file is special. When a directory - contains a default.nix file, it is used as the implict - nix expression of the directory. This, for example, allows use to run + contains a default.nix file, it is used as the implicit + nix expression of the directory. This, for example, allows us to run nix-build -A hello without specifying default.nix explicitly. @@ -295,7 +295,7 @@ gd, it would suffice to pass gd = ...;. - If we wanted to change the toolchain, we simply pass a different + If we wanted to change the toolchain, we would simply pass a different mkDerivation function. diff --git a/pills/13-callpackage-design-pattern.xml b/pills/13-callpackage-design-pattern.xml index f8443a3..95c085a 100644 --- a/pills/13-callpackage-design-pattern.xml +++ b/pills/13-callpackage-design-pattern.xml @@ -15,7 +15,7 @@ The next design pattern we will examine is called the callPackage pattern. This technique is extensively used in nixpkgs, and it's the current - de facto standard for importing packages in a repository. It's purpose is to reduce + de facto standard for importing packages in a repository. Its purpose is to reduce the duplication of identifiers between package derivation inputs and repository derivations. @@ -35,19 +35,19 @@ - we would likely want to bundle that package derivation into a respository via a + we would likely want to bundle that package derivation into a repository via a an attribute set defined as something like: There are two things to note. First, that inputs often have the same name as - attributes in the respository itself. Second, that (due to the rec + attributes in the repository itself. Second, that (due to the rec keyword), the inputs to a package derivation may be other packages in the repository itself. Rather than passing the inputs twice, we would prefer to pass those inputs from - the respoistory automatically and allow for manually overriding defaults. + the repository automatically and allow for manually overriding defaults. To achieve this, we will define a callPackage function with @@ -113,7 +113,7 @@ - The former is easy: we just have to set our package deriviation's inputs + The former is easy: we just have to set our package derivation's inputs to be package names in a repository, such as nixpkgs. For the latter, Nix provides another builtin function: @@ -249,7 +249,7 @@ Writing a repository in Nix is an evolution of writing convenient functions for - combining the packages. This pills demonstrates how Nix can be a generic tool + combining the packages. This pill demonstrates how Nix can be a generic tool to build and deploy software, and how suitable it is to create software repositories with our own conventions. diff --git a/pills/14-override-design-pattern.xml b/pills/14-override-design-pattern.xml index 1d66737..06db75f 100644 --- a/pills/14-override-design-pattern.xml +++ b/pills/14-override-design-pattern.xml @@ -127,7 +127,7 @@ The variable res contains the result of the function call without any override. It's easy to see in the definition of makeOverridable. - In addition, you can see that new override attribute is a function. + In addition, you can see that the new override attribute is a function. Calling res.override with a set will invoke the original function @@ -136,7 +136,7 @@ This is a good start, but we can't override again! This is because the returned set (with result = 15) does not have an override - attribute of it's own. This is bad; it breaks further composition. + attribute of its own. This is bad; it breaks further composition. The solution is simple: the .override function should make the diff --git a/pills/15-nix-search-paths.xml b/pills/15-nix-search-paths.xml index f534006..b5d110f 100644 --- a/pills/15-nix-search-paths.xml +++ b/pills/15-nix-search-paths.xml @@ -23,7 +23,7 @@ In the shell for example, when you execute the command ping, it's being searched in the PATH directories. The first one found is the one being used. - In nix it's exactly the same, however the syntax is different. Instead of just typing ping you have to type <ping>. Yes, I know... you are already thinking of <nixpkgs>. However don't stop reading here, let's keep going. + In nix it's exactly the same, however the syntax is different. Instead of just typing ping you have to type <ping>. Yes, I know... you are already thinking of <nixpkgs>. However, don't stop reading here, let's keep going. What's NIX_PATH good for? Nix expressions may refer to an "abstract" path such as <nixpkgs>, and it's possible to override it from the command line. @@ -72,7 +72,7 @@ - Yes, nix-build also accepts paths with angular brackets. We first evaluate the whole repository (default.nix) and then peek the graphviz attribute. + Yes, nix-build also accepts paths with angular brackets. We first evaluate the whole repository (default.nix) and then pick the graphviz attribute.
@@ -98,7 +98,7 @@ - By default nix-env parses all derivations and use the derivation names to interpret the command line. So in this case "graphviz" matched two derivations. Alternatively, like for nix-build, one can use -A to specify an attribute name instead of a derivation name: + By default nix-env parses all derivations and uses the derivation names to interpret the command line. So in this case "graphviz" matched two derivations. Alternatively, like for nix-build, one can use -A to specify an attribute name instead of a derivation name: @@ -108,7 +108,7 @@ For completeness: you must install graphvizCore with -A, since without the -A switch it's ambiguous. - In summary, it may happen when playing with nix that nix-env peeks a different derivation than nix-build. In such case you probably specified NIX_PATH, but nix-env is instead looking into ~/.nix-defexpr. + In summary, it may happen when playing with nix that nix-env picks a different derivation than nix-build. In that case you probably specified NIX_PATH, but nix-env is instead looking into ~/.nix-defexpr. Why is nix-env having this different behavior? I don't know specifically by myself either, but the answers could be: diff --git a/pills/16-nixpkgs-parameters.xml b/pills/16-nixpkgs-parameters.xml index 631362b..081a316 100644 --- a/pills/16-nixpkgs-parameters.xml +++ b/pills/16-nixpkgs-parameters.xml @@ -6,7 +6,7 @@ Nixpkgs Parameters - Welcome to the 16th Nix pill. In the previous 15th pill we've realized how nix finds expressions with the angular brackets syntax, so that we finally know where is <nixpkgs> located on our system. + Welcome to the 16th Nix pill. In the previous 15th pill we've realized how nix finds expressions with the angular brackets syntax, so that we finally know where <nixpkgs> is located on our system. We can start diving into the nixpkgs repository, through all the various tools and design patterns. Please note that also nixpkgs has its own manual, underlying the difference between the general nix language and the nixpkgs repository. @@ -66,10 +66,10 @@ I'm sure on the wiki or other manuals you've read about ~/.config/nixpkgs/config.nix (previously ~/.nixpkgs/config.nix) and I'm sure you've wondered whether that's hardcoded in nix. It's not, it's in nixpkgs. - The all-packages.nix expression accepts the config parameter. If it's null, then it reads the NIXPKGS_CONFIG environment variable. If not specified, nixpkgs will peek $HOME/.config/nixpkgs/config.nix. + The all-packages.nix expression accepts the config parameter. If it's null, then it reads the NIXPKGS_CONFIG environment variable. If not specified, nixpkgs will pick $HOME/.config/nixpkgs/config.nix. - After determining config.nix, it will be imported as nix expression, and that will be the value of config (in case it hasn't been passed as parameter to import <nixpkgs>). + After determining config.nix, it will be imported as a nix expression, and that will be the value of config (in case it hasn't been passed as parameter to import <nixpkgs>). The config is available in the resulting repository: @@ -90,7 +90,7 @@ In this case, nix does a trick: - If the expression is a derivation, well build it. + If the expression is a derivation, build it. If the expression is a function, call it and build the resulting derivation. diff --git a/pills/17-nixpkgs-overriding-packages.xml b/pills/17-nixpkgs-overriding-packages.xml index d885543..5d8fd36 100644 --- a/pills/17-nixpkgs-overriding-packages.xml +++ b/pills/17-nixpkgs-overriding-packages.xml @@ -27,7 +27,7 @@ This will build graphviz without X support, it's as simple as that. - However let's say a package P depends on graphviz, how do we make P depend on the new graphviz without X support? + However, let's say a package P depends on graphviz, how do we make P depend on the new graphviz without X support?
@@ -38,7 +38,7 @@ - Given pkgs.P depends on pkgs.graphviz, it's easy to build P with the replaced graphviz. On a pure functional language it's not that easy because you can assign to variables only once. + Given pkgs.P depends on pkgs.graphviz, it's easy to build P with the replaced graphviz. In a pure functional language it's not that easy because you can assign to variables only once.
@@ -79,7 +79,7 @@ - In the first case we computed pkgs with the overrides, in the second case we also included the overriden attributes in the result. + In the first case we computed pkgs with the overrides, in the second case we also included the overridden attributes in the result.
@@ -87,7 +87,7 @@
Overriding nixpkgs packages - We've seen how to override attributes in a set such that they get recursively picked by dependant attributes. This approach can be used for derivations too, after all nixpkgs is a giant set of attributes that depend on each other. + We've seen how to override attributes in a set such that they get recursively picked by dependent attributes. This approach can be used for derivations too, after all nixpkgs is a giant set of attributes that depend on each other. To do this, nixpkgs offers config.packageOverrides. So nixpkgs returns a fixed point of the package set, and packageOverrides is used to inject the overrides. @@ -134,7 +134,7 @@
Next pill - ...we will stop diving nixpkgs for a moment and talk about store paths. How does Nix compute the path in the store where to place the result of builds? How to add files to the store for which we have an integrity hash? + ...we will stop studying nixpkgs for a moment and talk about store paths. How does Nix compute the path in the store where to place the result of builds? How to add files to the store for which we have an integrity hash?
diff --git a/pills/20-basic-dependencies-and-hooks.xml b/pills/20-basic-dependencies-and-hooks.xml index 54b76cb..0c29729 100644 --- a/pills/20-basic-dependencies-and-hooks.xml +++ b/pills/20-basic-dependencies-and-hooks.xml @@ -32,7 +32,7 @@ For the simplest dependencies where the current package directly needs another, we use the buildInputs attribute. - This is exactly the pattern in taught with our builder in Pill 8. + This is exactly the pattern used in our builder in Pill 8. To demo this, let's build GNU Hello, and then another package which provides a shell script that execs it. @@ -138,7 +138,7 @@ As a final convenience, we have environment hooks. Recall in Pill 12 how we created NIX_CFLAGS_COMPILE for -I flags and NIX_LDFLAGS for -L flags, in a similar manner to how we prepared the PATH. One point of ugliness was how anti-modular this was. - It makes sense to build the PATH in generic builder, because the PATH is used by the shell, and the generic builder is intrinsically tied to the shell. + It makes sense to build the PATH in a generic builder, because the PATH is used by the shell, and the generic builder is intrinsically tied to the shell. But -I and -L flags are only relevant to the C compiler. The stdenv isn't wedded to including a C compiler (though it does by default), and there are other compilers too which may take completely different flags.