mirror of
https://github.com/NixOS/nix-pills
synced 2024-09-19 04:00:13 -04:00
Merge branch 'fix-pill-7-inherit-url'
This commit is contained in:
commit
6e67037cb8
|
@ -366,7 +366,7 @@
|
|||
We learned how to query the user environment and to manipulate it by
|
||||
installing and uninstalling software. Upgrading software is also straightforward,
|
||||
as you can read in
|
||||
<link xlink:href="http://nixos.org/nix/manual/#idm47361539520832">the manual</link>
|
||||
<link xlink:href="https://nixos.org/nix/manual/#operation-upgrade">the manual</link>
|
||||
(<command>nix-env -u</command> will upgrade all packages in the
|
||||
environment).
|
||||
</para>
|
||||
|
|
|
@ -51,7 +51,7 @@
|
|||
<para>
|
||||
Nix 2.0 contains a command named <command>nix repl</command> which is a simple command line tool
|
||||
for playing with the Nix language. In fact, Nix is a
|
||||
<link xlink:href="http://nixos.org/nix/manual/#idm47361539226272">pure, lazy, functional language</link>,
|
||||
<link xlink:href="https://nixos.org/nix/manual/#ch-expression-language">pure, lazy, functional language</link>,
|
||||
not only a set of tools to manage derivations. The <literal>nix repl</literal> syntax is slightly
|
||||
different to Nix syntax when it comes to assigning variables, but it shouldn't
|
||||
be confusing so long as you bear it in mind. I prefer to start with <literal>nix repl</literal>
|
||||
|
@ -235,7 +235,7 @@
|
|||
|
||||
<para>
|
||||
To do so, use
|
||||
<link xlink:href="http://nixos.org/nix/manual/#idm47361539166560">recursive attribute sets</link>:
|
||||
<link xlink:href="https://nixos.org/nix/manual/#idm140737322044432">recursive attribute sets</link>:
|
||||
</para>
|
||||
|
||||
<screen><xi:include href="./04/set-recursive.txt" parse="text" /></screen>
|
||||
|
|
|
@ -303,7 +303,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Then we meet the
|
||||
<link xlink:href="https://nixos.org/nix/manual/#idm140737318075200"><code>inherit</code> keyword</link>.
|
||||
<link xlink:href="https://nixos.org/nix/manual/#idm140737322036688"><code>inherit</code> keyword</link>.
|
||||
<code>inherit foo;</code> is equivalent to <code>foo = foo;</code>.
|
||||
Similarly, <code>inherit foo bar;</code> is equivalent to <code>foo = foo; bar = bar;</code>.
|
||||
</para>
|
||||
|
|
|
@ -212,7 +212,7 @@
|
|||
|
||||
<para>
|
||||
The
|
||||
<link xlink:href="http://nixos.org/nix/manual/#idm47361539098656">// operator</link>
|
||||
<link xlink:href="https://nixos.org/nix/manual/#idm140737322063856">// operator</link>
|
||||
is an operator between two sets. The result is the union of the two sets.
|
||||
In case of conflicts between attribute names, the value on the right set
|
||||
is preferred.
|
||||
|
|
|
@ -257,7 +257,7 @@
|
|||
This makes packages self-contained, because we're sure (apart data and
|
||||
configuration) that copying the runtime closure on another machine is
|
||||
sufficient to run the program. That's why Nix has
|
||||
<link xlink:href="http://nixos.org/nix/manual/#sec-one-click">one-click install</link>,
|
||||
<link xlink:href="https://nixos.org/nix/manual/#ch-relnotes-0.8">one-click install</link>,
|
||||
or
|
||||
<link xlink:href="http://nixos.org/nixops/manual/#chap-introduction">reliable deployment in the cloud</link>.
|
||||
All with one tool.
|
||||
|
|
|
@ -62,7 +62,7 @@
|
|||
You can list that directory and realize it's simply a checkout of the nixpkgs repository at a specific commit (hint: <literal>.version-suffix</literal>).
|
||||
</para>
|
||||
<para>
|
||||
The <varname>NIX_PATH</varname> variable is exported by <filename>nix.sh</filename>, and that's the reason why I always asked you to <link xlink:href="http://nixos.org/nix/manual/#idm47361539530016">source nix.sh</link> at the beginning of my posts.
|
||||
The <varname>NIX_PATH</varname> variable is exported by <filename>nix.sh</filename>, and that's the reason why I always asked you to <link xlink:href="https://nixos.org/nix/manual/#ch-env-variables">source nix.sh</link> at the beginning of my posts.
|
||||
</para>
|
||||
<para>
|
||||
You may wonder: then I can also specify a different <link xlink:href="https://github.com/NixOS/nixpkgs">nixpkgs</link> path to, e.g., a <command>git checkout</command> of <literal>nixpkgs</literal>? Yes, you can and I encourage doing that. We'll talk about this in the next pill.
|
||||
|
|
|
@ -96,7 +96,7 @@
|
|||
Finally, the other most used kind of path is when we know beforehand an integrity hash of a file. This is usual for tarballs.
|
||||
</para>
|
||||
<para>
|
||||
A derivation can take three special attributes: <literal>outputHashMode</literal>, <literal>outputHash</literal> and <literal>outputHashAlgo</literal> which are well documented in the <link xlink:href="http://nixos.org/nix/manual/#ssec-derivation">nix manual</link>.
|
||||
A derivation can take three special attributes: <literal>outputHashMode</literal>, <literal>outputHash</literal> and <literal>outputHashAlgo</literal> which are well documented in the <link xlink:href="https://nixos.org/nix/manual/#sec-advanced-attributes">nix manual</link>.
|
||||
</para>
|
||||
<para>
|
||||
The builder must create the out path and make sure its hash is the same as the one declared with <literal>outputHash</literal>.
|
||||
|
|
Loading…
Reference in a new issue