From d7c8d346493767c54354b4620fe61589bce31281 Mon Sep 17 00:00:00 2001 From: Noam Yorav-Raphael Date: Thu, 4 Apr 2024 00:18:40 +0300 Subject: [PATCH] Replace `\...` with `...` --- pills/01-why-you-should-give-it-try.md | 6 +++--- pills/02-install-on-your-running.md | 4 ++-- pills/03-enter-environment.md | 2 +- pills/04-basics-of-language.md | 2 +- pills/05-functions-and-imports.md | 4 ++-- pills/06-our-first-derivation.md | 4 ++-- pills/08-generic-builders.md | 2 +- pills/09-automatic-runtime.md | 2 +- pills/15-nix-search-paths.md | 4 ++-- pills/16-nixpkgs-parameters.md | 4 ++-- pills/17-nixpkgs-overriding-packages.md | 6 +++--- pills/18-nix-store-paths.md | 2 +- pills/19-fundamentals-of-stdenv.md | 4 ++-- pills/20-basic-dependencies-and-hooks.md | 4 ++-- 14 files changed, 25 insertions(+), 25 deletions(-) diff --git a/pills/01-why-you-should-give-it-try.md b/pills/01-why-you-should-give-it-try.md index e6ce644..a8c2807 100644 --- a/pills/01-why-you-should-give-it-try.md +++ b/pills/01-why-you-should-give-it-try.md @@ -16,7 +16,7 @@ The following is a description of Nix. Just as with pills, I'll try to be as sho ## Not being purely functional -Most, if not all, widely used package managers ([dpkg](https://wiki.debian.org/dpkg), [rpm](http://www.rpm.org/), \...) mutate the global state of the system. If a package `foo-1.0` installs a program to `/usr/bin/foo`, you cannot install `foo-1.1` as well, unless you change the installation paths or the binary name. But changing the binary names means breaking users of that binary. +Most, if not all, widely used package managers ([dpkg](https://wiki.debian.org/dpkg), [rpm](http://www.rpm.org/), ...) mutate the global state of the system. If a package `foo-1.0` installs a program to `/usr/bin/foo`, you cannot install `foo-1.1` as well, unless you change the installation paths or the binary name. But changing the binary names means breaking users of that binary. There are some attempts to mitigate this problem. Debian, for example, partially solves the problem with the [alternatives](https://wiki.debian.org/DebianAlternatives) system. @@ -91,6 +91,6 @@ That may sound scary, however after running NixOS on both a server and a laptop Considering [Nixpkgs](https://nixos.org/nixpkgs/) ([github link](https://github.com/NixOS/nixpkgs)) is a completely new repository of all the existing software, with a completely fresh concept, and with few core developers but overall year-over-year increasing contributions, the current state is more than acceptable and beyond the experimental stage. In other words, it's worth your investment. -## Next pill\... +## Next pill... -\...we will install Nix on top of your current system (I assume GNU/Linux, but we also have OSX users) and start inspecting the installed software. +...we will install Nix on top of your current system (I assume GNU/Linux, but we also have OSX users) and start inspecting the installed software. diff --git a/pills/02-install-on-your-running.md b/pills/02-install-on-your-running.md index e34a51c..113ddcd 100644 --- a/pills/02-install-on-your-running.md +++ b/pills/02-install-on-your-running.md @@ -142,6 +142,6 @@ The installation put everything under `/nix`, and some symlinks in the Nix user I hope I left nothing uncovered so that you think there's some kind of magic going on behind the scenes. It's all about putting components in the store and symlinking these components together. -## Next pill\... +## Next pill... -\...we will enter the Nix environment and learn how to interact with the store. +...we will enter the Nix environment and learn how to interact with the store. diff --git a/pills/03-enter-environment.md b/pills/03-enter-environment.md index 993e6ac..de56b31 100644 --- a/pills/03-enter-environment.md +++ b/pills/03-enter-environment.md @@ -199,4 +199,4 @@ A quick analogy with programming languages: you have the heap with all the objec ## Next pill -\...we will learn the basics of the Nix language. The Nix language is used to describe how to build derivations, and it's the basis for everything else, including NixOS. Therefore it's very important to understand both the syntax and the semantics of the language. +...we will learn the basics of the Nix language. The Nix language is used to describe how to build derivations, and it's the basis for everything else, including NixOS. Therefore it's very important to understand both the syntax and the semantics of the language. diff --git a/pills/04-basics-of-language.md b/pills/04-basics-of-language.md index 8878779..563de86 100644 --- a/pills/04-basics-of-language.md +++ b/pills/04-basics-of-language.md @@ -223,4 +223,4 @@ Since `a` is not needed, there's no error about division by zero, because the ex ## Next pill -\...we will talk about functions and imports. In this pill I've tried to avoid function calls as much as possible, otherwise the post would have been too long. +...we will talk about functions and imports. In this pill I've tried to avoid function calls as much as possible, otherwise the post would have been too long. diff --git a/pills/05-functions-and-imports.md b/pills/05-functions-and-imports.md index f1dd51b..0bc8f24 100644 --- a/pills/05-functions-and-imports.md +++ b/pills/05-functions-and-imports.md @@ -13,7 +13,7 @@ Functions are anonymous (lambdas), and only have a single parameter. The syntax nix-repl> x: x*2 «lambda» -So here we defined a function that takes a parameter `x`, and returns `x*2`. The problem is that we cannot use it in any way, because it's unnamed\... joke! +So here we defined a function that takes a parameter `x`, and returns `x*2`. The problem is that we cannot use it in any way, because it's unnamed... joke! We can store functions in variables. @@ -183,4 +183,4 @@ So when is the message shown? Only when it needs to be evaluated. ## Next pill -\...we will finally write our first derivation. +...we will finally write our first derivation. diff --git a/pills/06-our-first-derivation.md b/pills/06-our-first-derivation.md index 4522643..1067aa7 100644 --- a/pills/06-our-first-derivation.md +++ b/pills/06-our-first-derivation.md @@ -97,7 +97,7 @@ Many things are empty in that `.drv`, however I'll write a summary of the [.drv That's it, the minimum necessary information to build our derivation. -Important note: the environment variables passed to the builder are just those you see in the .drv plus some other Nix related configuration (number of cores, temp dir, \...). The builder will not inherit any variable from your running shell, otherwise builds would suffer from [non-determinism](https://wiki.debian.org/ReproducibleBuilds). +Important note: the environment variables passed to the builder are just those you see in the .drv plus some other Nix related configuration (number of cores, temp dir, ...). The builder will not inherit any variable from your running shell, otherwise builds would suffer from [non-determinism](https://wiki.debian.org/ReproducibleBuilds). Back to our fake derivation. @@ -279,4 +279,4 @@ When Nix builds a derivation, it first creates a .drv file from a derivation exp ## Next pill -\...we will finally write our first **working** derivation. Yes, this post is about "our first derivation", but I never said it was a working one ;) +...we will finally write our first **working** derivation. Yes, this post is about "our first derivation", but I never said it was a working one ;) diff --git a/pills/08-generic-builders.md b/pills/08-generic-builders.md index ab99653..ed2a436 100644 --- a/pills/08-generic-builders.md +++ b/pills/08-generic-builders.md @@ -248,4 +248,4 @@ In Nix you create derivations stored in the nix store, and then you compose them ## Next pill -\...we will talk a little about runtime dependencies. Is the GNU hello world package self-contained? What are its runtime dependencies? We only specified build dependencies by means of using other derivations in the "hello" derivation. +...we will talk a little about runtime dependencies. Is the GNU hello world package self-contained? What are its runtime dependencies? We only specified build dependencies by means of using other derivations in the "hello" derivation. diff --git a/pills/09-automatic-runtime.md b/pills/09-automatic-runtime.md index 90a7b5c..05d9529 100644 --- a/pills/09-automatic-runtime.md +++ b/pills/09-automatic-runtime.md @@ -96,7 +96,7 @@ That is, for each file we run `patchelf --shrink-rpath` and `strip`. Note that w **Exercise:** Add `findutils` and `patchelf` to the `baseInputs` of `autotools.nix`. -Now, we rebuild `hello.nix`\... +Now, we rebuild `hello.nix`... $ nix-build hello.nix [...] diff --git a/pills/15-nix-search-paths.md b/pills/15-nix-search-paths.md index ec9a146..a420e66 100644 --- a/pills/15-nix-search-paths.md +++ b/pills/15-nix-search-paths.md @@ -12,7 +12,7 @@ Who uses `NIX_PATH`? The nix expressions! Yes, `NIX_PATH` is not of much use by 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 ``. Yes, I know\... you are already thinking of ``. 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 ``. Yes, I know... you are already thinking of ``. 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 ``, and it's possible to override it from the command line. @@ -121,4 +121,4 @@ In general do not abuse `NIX_PATH`, when possible use relative paths when writin ## Next pill -\...we will finally dive into `nixpkgs`. Most of the techniques we have developed in this series are already in `nixpkgs`, like `mkDerivation`, `callPackage`, `override`, etc., but of course better. With time, those base utilities get enhanced by the community with more features in order to handle more and more use cases and in a more general way. +...we will finally dive into `nixpkgs`. Most of the techniques we have developed in this series are already in `nixpkgs`, like `mkDerivation`, `callPackage`, `override`, etc., but of course better. With time, those base utilities get enhanced by the community with more features in order to handle more and more use cases and in a more general way. diff --git a/pills/16-nixpkgs-parameters.md b/pills/16-nixpkgs-parameters.md index 2cfab64..e045b42 100644 --- a/pills/16-nixpkgs-parameters.md +++ b/pills/16-nixpkgs-parameters.md @@ -20,7 +20,7 @@ The `all-packages.nix` is a bit contrived. First of all, it's a function. It acc - `config`: defaults to null -- others\... +- others... The **system** parameter, as per comment in the expression, it's the system for which the packages will be built. It allows for example to install i686 packages on amd64 machines. @@ -97,4 +97,4 @@ Lately I'm a little busy with the NixOS 14.11 release and other stuff, and I'm a ## Next pill -\...we will talk about overriding packages in the `nixpkgs` repository. What if you want to change some options of a library and let all other packages pick the new library? One possibility is to use, like described above, the `config` parameter when applicable. The other possibility is to override derivations. +...we will talk about overriding packages in the `nixpkgs` repository. What if you want to change some options of a library and let all other packages pick the new library? One possibility is to use, like described above, the `config` parameter when applicable. The other possibility is to override derivations. diff --git a/pills/17-nixpkgs-overriding-packages.md b/pills/17-nixpkgs-overriding-packages.md index 85228ca..fbb2702 100644 --- a/pills/17-nixpkgs-overriding-packages.md +++ b/pills/17-nixpkgs-overriding-packages.md @@ -21,9 +21,9 @@ 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? -## In an imperative world\... +## In an imperative world... -\...you could do something like this: +...you could do something like this: pkgs = import {}; pkgs.graphviz = pkgs.graphviz.override { withXorg = false; }; @@ -124,4 +124,4 @@ The newly built asciidoc will depend on the new graphviz, and old asciidoc will ## Next pill -\...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? +...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/18-nix-store-paths.md b/pills/18-nix-store-paths.md index 8beaab6..a67bca2 100644 --- a/pills/18-nix-store-paths.md +++ b/pills/18-nix-store-paths.md @@ -159,4 +159,4 @@ Also we've introduced some fundamentals, in particular the fact that Nix knows b ## Next pill -\...we will introduce `stdenv`. In the previous pills we rolled our own `mkDerivation` convenience function for wrapping the builtin derivation, but the `nixpkgs` repository also has its own convenience functions for dealing with autotools projects and other build systems. +...we will introduce `stdenv`. In the previous pills we rolled our own `mkDerivation` convenience function for wrapping the builtin derivation, but the `nixpkgs` repository also has its own convenience functions for dealing with autotools projects and other build systems. diff --git a/pills/19-fundamentals-of-stdenv.md b/pills/19-fundamentals-of-stdenv.md index 496b719..126b51e 100644 --- a/pills/19-fundamentals-of-stdenv.md +++ b/pills/19-fundamentals-of-stdenv.md @@ -193,6 +193,6 @@ That's it. Everything you need to know about the stdenv phases is in the [setup Really, take your time to read that file. Don't forget that juicy docs are also available in the [nixpkgs manual](http://nixos.org/nixpkgs/manual/#chap-stdenv). -## Next pill\... +## Next pill... -\...we will talk about how to add dependencies to our packages with `buildInputs` and `propagatedBuildInputs`, and influence downstream builds with setup hooks and env hooks. These concepts are crucial to how `nixpkgs` packages are composed. +...we will talk about how to add dependencies to our packages with `buildInputs` and `propagatedBuildInputs`, and influence downstream builds with setup hooks and env hooks. These concepts are crucial to how `nixpkgs` packages are composed. diff --git a/pills/20-basic-dependencies-and-hooks.md b/pills/20-basic-dependencies-and-hooks.md index 7c50f94..bd26a30 100644 --- a/pills/20-basic-dependencies-and-hooks.md +++ b/pills/20-basic-dependencies-and-hooks.md @@ -244,9 +244,9 @@ Functions listed in `envHooks` are applied to every package passed to `addToEnv` and if one dependency has that setup hook then all of them will be so `echo`ed. Allowing dependencies to learn about their *sibling* dependencies is exactly what compilers need. -## Next pill\... +## Next pill... -\...I'm not sure! We could talk about the additional dependency types and hooks which cross compilation necessitates, building on our knowledge here to cover stdenv as it works today. We could talk about how nixpkgs is bootstrapped. Or we could talk about how `localSystem` and `crossSystem` are elaborated into the `buildPlatform`, `hostPlatform`, and `targetPlatform` each bootstrapping stage receives. Let us know which most interests you! +...I'm not sure! We could talk about the additional dependency types and hooks which cross compilation necessitates, building on our knowledge here to cover stdenv as it works today. We could talk about how nixpkgs is bootstrapped. Or we could talk about how `localSystem` and `crossSystem` are elaborated into the `buildPlatform`, `hostPlatform`, and `targetPlatform` each bootstrapping stage receives. Let us know which most interests you! [^1]: We can now be precise and consider what `addToEnv` does alone the minimal treatment of a dependency: i.e. a package that is *just* a dependency would *only* have `addToEnv` applied to it.