mirror of
https://github.com/NixOS/nix-pills
synced 2024-09-18 03:50:12 -04:00
Replace \... with ...
This commit is contained in:
Noam Yorav-Raphael
Jan Tojnar
parent
6f1bbb0d6c
commit
d7c8d34649
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 ;)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
[...]
|
||||
|
|
|
|||
|
|
@ -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 `<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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 <nixpkgs> {};
|
||||
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?
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue