Mirrors/nix-pills
2
0
Fork 0
mirror of https://github.com/NixOS/nix-pills synced 2024-11-10 05:44:14 +00:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #230 from proski/typos

Browse source 
Fix typos
This commit is contained in:
Pol Dellaiera 2024-02-20 09:04:08 +01:00 committed by GitHub
commit 102ef96805
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
16 changed files with 66 additions and 66 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
book.xml
View file

@ -16,7 +16,7 @@
This is a ported version of the <emphasis role="strong">Nix
Pills</emphasis>, a series of blog posts written by <emphasis
role="strong">Luca Bruno</emphasis> (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'.
</para>

2
pills/03-enter-environment.xml
View file

@ -372,7 +372,7 @@
</para>
<para>
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.
</para>

2
pills/04-basics-of-language.xml
View file

@ -205,7 +205,7 @@
<title>Attribute sets</title>
<para>
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.
</para>

16
pills/05-functions-and-imports.xml
View file

@ -93,7 +93,7 @@ xml:id="functions-and-imports">
</para>
<para>
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:
</para>
@ -102,7 +102,7 @@ xml:id="functions-and-imports">
<para>
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
<code>mul(6+7, 8+9)</code>.
</para>
@ -121,7 +121,7 @@ xml:id="functions-and-imports">
</section>
<section>
<title>Arguments set</title>
<title>Argument set</title>
<para>
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">
<para>
In the first case we defined a function that accepts a single parameter. We
then access attributes <code>a</code> and
<code>b</code> from the given set. Note how the parenthesis-less syntax for
<code>b</code> from the given set. Note how the parentheses-less syntax for
function calls is very elegant in this case, instead of doing <code>mul({
a=3; b=4; })</code> in other languages.
</para>
<para>
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
<code>a</code> and <code>b</code>. Then we can use those <code>a</code> and
<code>b</code> in the function body directly.
@ -160,7 +160,7 @@ xml:id="functions-and-imports">
<para>
It is possible to specify <emphasis role="strong">default values</emphasis>
of attributes in the arguments set:
of attributes in the argument set:
</para>
<screen><xi:include href="./05/default-values.txt" parse="text" /></screen>
@ -264,7 +264,7 @@ xml:id="functions-and-imports">
<screen><xi:include href="./05/import.txt" parse="text" /></screen>
<para>
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.
</para>
@ -324,7 +324,7 @@ xml:id="functions-and-imports">
</itemizedlist>
<para>
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.
</para>
</section>

6
pills/06-our-first-derivation.xml
View file

@ -81,7 +81,7 @@
<para>
Oh oh, what's that? Did it build the derivation? No it didn't, but it
<emphasis role="strong">did create the .drv file</emphasis>. <literal>nix repl</literal> does
not build derivations unless you tell to do so.
not build derivations unless you tell it to do so.
</para>
</section>
@ -342,7 +342,7 @@
<screen><xi:include href="./06/coreutils.txt" parse="text" /></screen>
<para>
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 @@
<para>
<emphasis role="underline">Obvious note</emphasis>: everytime we change the
<emphasis role="underline">Obvious note</emphasis>: every time we change the
derivation, a new hash is created.
</para>

6
pills/08-generic-builders.xml
View file

@ -123,7 +123,7 @@
<para>
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.
</para>
<para>
@ -134,7 +134,7 @@
<para>
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.
</para>
<para>
@ -162,7 +162,7 @@
<para>
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.
</para>
<para>

8
pills/09-automatic-runtime.xml
View file

@ -102,7 +102,7 @@
</listitem>
<listitem>
<para>
For each build dependency <code>.drv</code> and it's relative out path,
For each build dependency <code>.drv</code> and its relative out path,
search the contents of the NAR for this out path.
</para>
</listitem>
@ -146,7 +146,7 @@
<para>
Even after reducing the rpath, the <code>hello</code> binary would still
depend upon <code>gcc</code> 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 <command><link
xlink:href="https://linux.die.net/man/1/strip">strip</link>
</command> can help us with that in the next section.
@ -218,7 +218,7 @@
</para>
<para>
Now, we rebuild <filename>hello.nix</filename>:nd...:
Now, we rebuild <filename>hello.nix</filename>...
</para>
<screen><xi:include href="./09/build-hello-nix.txt" parse="text" /></screen>
@ -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.
</para>

8
pills/10-developing-with-nix-shell.xml
View file

@ -67,7 +67,7 @@
</para>
<para>
This means the we can <command>source</command> our
This means that we can <command>source</command> our
<filename>builder.sh</filename>, 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 <filename>/nix/store</filename>:
@ -122,7 +122,7 @@
<para>
First, when we <command>source</command>d the <filename>builder.sh</filename>
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 <filename>builder.sh</filename> that is stored in the nix store,
as this is the file that would be used by <command>nix-build</command>.
To achieve this, the correct technique is to pass an environment variable
@ -142,7 +142,7 @@
</para>
<para>
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
<code>set -e</code> to the builder file instead of the setup file.
The <code>set -e</code> is annoying in <command>nix-shell</command>,
@ -214,7 +214,7 @@
With <command>nix-shell</command> 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
<command>nix-build</command> providesthe necessary dependencies to a builder.
<command>nix-build</command> 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 <command>gcc</command> or <command>make</command> system-wide; these tools

20
pills/11-garbage-collector.xml
View file

@ -8,7 +8,7 @@
<para>
Welcome to the 11th Nix pill. In the previous
<link linkend="developing-with-nix-shell">10th pill</link>, we drew a
<link linkend="developing-with-nix-shell">10th pill</link>, we drew
a parallel between the isolated build environment provided by
<command>nix-build</command> and the isolated development shell provided by
<command>nix-shell</command>. Using <command>nix-shell</command> allowed us
@ -44,7 +44,7 @@
<para>
Instead of objects, Nix's garbage collection operates on store paths, <link xlink:href="https://nixos.org/manual/nix/stable/package-management/garbage-collector-roots.html">with the GC roots themselves being store paths</link>.
. This approach is much mode principled than traditional package
. This approach is much more principled than traditional package
managers such as <code>dpkg</code> or <code>rpm</code>, which may
leave around unused packages or dangling files.
</para>
@ -52,13 +52,13 @@
<para>
The implementation is very simple and transparent to the user. The primary
GC roots are stored under <filename>/nix/var/nix/gcroots</filename>. 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.
</para>
<para>
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.
</para>
@ -90,7 +90,7 @@
<para>
We now install a new program, <code>bsd-games</code>, inspect its
store path, and examine it's GC root. The <command>nix-store -q --roots</command>
store path, and examine its GC root. The <command>nix-store -q --roots</command>
command is used to query the GC roots that refer to a given derivation. In this
case, our current user environment refers to <code>bsd-games</code>:
</para>
@ -131,7 +131,7 @@
<filename>/nix/var/nix/gcroots</filename>. In addition to the latter,
Nix treats <filename>/nix/var/nix/profiles</filename> 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,
<filename>/run/booted-system</filename> on NixOS.
The command <command>nix-store --gc --print-roots</command> 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
<filename>/home/nix/result</filename>. This is called an
<emphasis role="bold">indirect GC root</emphasis>. A GC root is
considred indirect if it's specification is outside of
considered indirect if its specification is outside of
<filename>/nix/var/nix/gcroots</filename>. In this case, this means
that the target of the <filename>result</filename> symlink will
not be garbage collected.
</para>
<para>
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:
</para>
@ -211,7 +211,7 @@
The main source of software duplication in the nix store comes from
GC roots, due to <command>nix-build</command> and profile generations.
Running <command>nix-build</command> 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
<package>glibc</package>. 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 @@
<title>Conclusion</title>
<para>
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 <command>nix-store</command> 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

16
pills/12-inputs-design-pattern.xml
View file

@ -16,7 +16,7 @@
<section>
<title>Repositories in Nix</title>
<para>
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 @@
<para>
Over time, the <literal>nixpkgs</literal> 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.
</para>
</section>
@ -33,7 +33,7 @@
<title>The single repository pattern</title>
<para>
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 <code>graphviz</code> configuration script uses <command>pkg-config</command>
to specify which flags are passed to the compiler. Since there is no global location
for libraries, we need to tell <command>pkg-config</command> 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.
</para>
<para>
@ -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 <literal>nixpkgs</literal> 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.
</para>
<para>
@ -175,8 +175,8 @@
<screen><xi:include href="./12/repository-test-nix-build.txt" parse="text" /></screen>
<para>
The <filename>default.nix</filename> file is special. When a directory
contains a <filename>default.nix</filename> file, it is used as the implict
nix expression of the directory. This, for example, allows use to run
contains a <filename>default.nix</filename> file, it is used as the implicit
nix expression of the directory. This, for example, allows us to run
<command>nix-build -A hello</command> without specifying
<filename>default.nix</filename> explicitly.
</para>
@ -295,7 +295,7 @@
<code>gd</code>, it would suffice to pass <literal>gd = ...;</literal>.
</para>
<para>
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
<literal>mkDerivation</literal> function.
</para>
<para>

12
pills/13-callpackage-design-pattern.xml
View file

@ -15,7 +15,7 @@
The next design pattern we will examine is called the <literal>callPackage</literal>
pattern. This technique is extensively used in <link
xlink:href="https://github.com/NixOS/nixpkgs">nixpkgs</link>, 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.
</para>
@ -35,19 +35,19 @@
</para>
<screen><xi:include href="./13/package-derivation.txt" parse="text" /></screen>
<para>
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:
</para>
<screen><xi:include href="./13/repository-derivation.txt" parse="text" /></screen>
<para>
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 <code>rec</code>
attributes in the repository itself. Second, that (due to the <code>rec</code>
keyword), the inputs to a package derivation may be other packages in the
repository itself.
</para>
<para>
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.
</para>
<para>
To achieve this, we will define a <literal>callPackage</literal> function with
@ -113,7 +113,7 @@
</itemizedlist>
</para>
<para>
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 <code>nixpkgs</code>. For
the latter, Nix provides another builtin function:
</para>
@ -249,7 +249,7 @@
</para>
<para>
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.
</para>

4
pills/14-override-design-pattern.xml
View file

@ -127,7 +127,7 @@
<para>
The variable <literal>res</literal> contains the result of the function call without
any override. It's easy to see in the definition of <literal>makeOverridable</literal>.
In addition, you can see that new <literal>override</literal> attribute is a function.
In addition, you can see that the new <literal>override</literal> attribute is a function.
</para>
<para>
Calling <literal>res.override</literal> with a set will invoke the original function
@ -136,7 +136,7 @@
<para>
This is a good start, but we can't override again! This is because the returned
set (with <literal>result = 15</literal>) does not have an <literal>override</literal>
attribute of it's own. This is bad; it breaks further composition.
attribute of its own. This is bad; it breaks further composition.
</para>
<para>
The solution is simple: the <literal>.override</literal> function should make the

8
pills/15-nix-search-paths.xml
View file

@ -23,7 +23,7 @@
In the shell for example, when you execute the command <command>ping</command>, it's being searched in the <varname>PATH</varname> directories. The first one found is the one being used.
</para>
<para>
In nix it's exactly the same, however the syntax is different. Instead of just typing <command>ping</command> you have to type <literal>&lt;ping&gt;</literal>. Yes, I know... you are already thinking of <literal>&lt;nixpkgs&gt;</literal>. 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 <command>ping</command> you have to type <literal>&lt;ping&gt;</literal>. Yes, I know... you are already thinking of <literal>&lt;nixpkgs&gt;</literal>. However, don't stop reading here, let's keep going.
</para>
<para>
What's <varname>NIX_PATH</varname> good for? Nix expressions may refer to an "abstract" path such as <literal>&lt;nixpkgs&gt;</literal>, and it's possible to override it from the command line.
@ -72,7 +72,7 @@
</para>
<screen><xi:include href="./15/mypkgs-path.txt" parse="text" /></screen>
<para>
Yes, <command>nix-build</command> also accepts paths with angular brackets. We first evaluate the whole repository (<filename>default.nix</filename>) and then peek the <package>graphviz</package> attribute.
Yes, <command>nix-build</command> also accepts paths with angular brackets. We first evaluate the whole repository (<filename>default.nix</filename>) and then pick the <package>graphviz</package> attribute.
</para>
</section>
<section>
@ -98,7 +98,7 @@
</para>
<screen><xi:include href="./15/mypkgs-query-all.txt" parse="text" /></screen>
<para>
By default <command>nix-env</command> parses all derivations and use the derivation names to interpret the command line. So in this case "graphviz" matched two derivations. Alternatively, like for <command>nix-build</command>, one can use <arg>-A</arg> to specify an attribute name instead of a derivation name:
By default <command>nix-env</command> parses all derivations and uses the derivation names to interpret the command line. So in this case "graphviz" matched two derivations. Alternatively, like for <command>nix-build</command>, one can use <arg>-A</arg> to specify an attribute name instead of a derivation name:
</para>
<screen><xi:include href="./15/mypkgs-install-attr-graphviz.txt" parse="text" /></screen>
<para>
@ -108,7 +108,7 @@
For completeness: you must install <literal>graphvizCore</literal> with <arg>-A,</arg> since without the <arg>-A</arg> switch it's ambiguous.
</para>
<para>
In summary, it may happen when playing with nix that <command>nix-env</command> peeks a different derivation than <command>nix-build</command>. In such case you probably specified <varname>NIX_PATH</varname>, but <command>nix-env</command> is instead looking into <filename>~/.nix-defexpr</filename>.
In summary, it may happen when playing with nix that <command>nix-env</command> picks a different derivation than <command>nix-build</command>. In that case you probably specified <varname>NIX_PATH</varname>, but <command>nix-env</command> is instead looking into <filename>~/.nix-defexpr</filename>.
</para>
<para>
Why is <command>nix-env</command> having this different behavior? I don't know specifically by myself either, but the answers could be:

8
pills/16-nixpkgs-parameters.xml
View file

@ -6,7 +6,7 @@
<title>Nixpkgs Parameters</title>
<para>
Welcome to the 16th Nix pill. In the previous <link linkend="nix-search-paths">15th</link> pill we've realized how nix finds expressions with the angular brackets syntax, so that we finally know where is <literal>&lt;nixpkgs&gt;</literal> located on our system.
Welcome to the 16th Nix pill. In the previous <link linkend="nix-search-paths">15th</link> pill we've realized how nix finds expressions with the angular brackets syntax, so that we finally know where <literal>&lt;nixpkgs&gt;</literal> is located on our system.
</para>
<para>
We can start diving into the <link xlink:href="https://github.com/NixOS/nixpkgs">nixpkgs repository</link>, through all the various tools and design patterns. Please note that also <literal>nixpkgs</literal> has its own manual, underlying the difference between the general <literal>nix</literal> language and the <literal>nixpkgs</literal> repository.
@ -66,10 +66,10 @@
I'm sure on the wiki or other manuals you've read about <filename>~/.config/nixpkgs/config.nix</filename> (previously <filename>~/.nixpkgs/config.nix</filename>) and I'm sure you've wondered whether that's hardcoded in nix. It's not, it's in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/32c523914fdb8bf9cc7912b1eba023a8daaae2e8/pkgs/top-level/impure.nix#L28">nixpkgs</link>.
</para>
<para>
The <filename>all-packages.nix</filename> expression accepts the <literal>config</literal> parameter. If it's <literal>null</literal>, then it reads the <varname>NIXPKGS_CONFIG</varname> environment variable. If not specified, <literal>nixpkgs</literal> will peek <filename>$HOME/.config/nixpkgs/config.nix</filename>.
The <filename>all-packages.nix</filename> expression accepts the <literal>config</literal> parameter. If it's <literal>null</literal>, then it reads the <varname>NIXPKGS_CONFIG</varname> environment variable. If not specified, <literal>nixpkgs</literal> will pick <filename>$HOME/.config/nixpkgs/config.nix</filename>.
</para>
<para>
After determining <filename>config.nix</filename>, it will be imported as nix expression, and that will be the value of <literal>config</literal> (in case it hasn't been passed as parameter to import <literal>&lt;nixpkgs&gt;</literal>).
After determining <filename>config.nix</filename>, it will be imported as a nix expression, and that will be the value of <literal>config</literal> (in case it hasn't been passed as parameter to import <literal>&lt;nixpkgs&gt;</literal>).
</para>
<para>
The <literal>config</literal> is available in the resulting repository:
@ -90,7 +90,7 @@
<para>
In this case, nix does a trick:
<itemizedlist>
<listitem><para>If the expression is a derivation, well build it.</para></listitem>
<listitem><para>If the expression is a derivation, build it.</para></listitem>
<listitem><para>If the expression is a function, call it and build the resulting derivation.</para></listitem>
</itemizedlist>
</para>

10
pills/17-nixpkgs-overriding-packages.xml
View file

@ -27,7 +27,7 @@
This will build <package>graphviz</package> without X support, it's as simple as that.
</para>
<para>
However let's say a package <literal>P</literal> depends on <package>graphviz</package>, how do we make <literal>P</literal> depend on the new <package>graphviz</package> without X support?
However, let's say a package <literal>P</literal> depends on <package>graphviz</package>, how do we make <literal>P</literal> depend on the new <package>graphviz</package> without X support?
</para>
</section>
@ -38,7 +38,7 @@
</para>
<screen><xi:include href="./17/p-graphviz-override.txt" parse="text" /></screen>
<para>
Given <literal>pkgs.P</literal> depends on <literal>pkgs.graphviz</literal>, it's easy to build <literal>P</literal> with the replaced <package>graphviz</package>. On a pure functional language it's not that easy because you can assign to variables only once.
Given <literal>pkgs.P</literal> depends on <literal>pkgs.graphviz</literal>, it's easy to build <literal>P</literal> with the replaced <package>graphviz</package>. In a pure functional language it's not that easy because you can assign to variables only once.
</para>
</section>
<section>
@ -79,7 +79,7 @@
</para>
<screen><xi:include href="./17/newpkgs-override-set.txt" parse="text" /></screen>
<para>
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.
</para>
</section>
@ -87,7 +87,7 @@
<section>
<title>Overriding nixpkgs packages</title>
<para>
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 <literal>nixpkgs</literal> 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 <literal>nixpkgs</literal> is a giant set of attributes that depend on each other.
</para>
<para>
To do this, <literal>nixpkgs</literal> offers <literal>config.packageOverrides</literal>. So <literal>nixpkgs</literal> returns a fixed point of the package set, and <literal>packageOverrides</literal> is used to inject the overrides.
@ -134,7 +134,7 @@
<section>
<title>Next pill</title>
<para>
...we will stop diving <literal>nixpkgs</literal> 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 <literal>nixpkgs</literal> 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?
</para>
</section>

4
pills/20-basic-dependencies-and-hooks.xml
View file

@ -32,7 +32,7 @@
<para>
For the simplest dependencies where the current package directly needs another, we use the <varname>buildInputs</varname> attribute.
This is exactly the pattern in taught with our builder in <link linkend="generic-builders">Pill 8</link>.
This is exactly the pattern used in our builder in <link linkend="generic-builders">Pill 8</link>.
To demo this, let's build GNU Hello, and then another package which provides a shell script that <command>exec</command>s it.
<screen><xi:include href="./20/two-hellos.nix" parse="text" /></screen>
</para>
@ -138,7 +138,7 @@
As a final convenience, we have environment hooks.
Recall in <link linkend="inputs-design-pattern">Pill 12</link> how we created <envar>NIX_CFLAGS_COMPILE</envar> for <literal>-I</literal> flags and <envar>NIX_LDFLAGS</envar> for <literal>-L</literal> flags, in a similar manner to how we prepared the <envar>PATH</envar>.
One point of ugliness was how anti-modular this was.
It makes sense to build the <envar>PATH</envar> in generic builder, because the <envar>PATH</envar> is used by the shell, and the generic builder is intrinsically tied to the shell.
It makes sense to build the <envar>PATH</envar> in a generic builder, because the <envar>PATH</envar> is used by the shell, and the generic builder is intrinsically tied to the shell.
But <literal>-I</literal> and <literal>-L</literal> 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.
</para>