divnix / nix-book Goto Github PK

Somewhere in section 3. The Nix Language, IFD should probably be explained. What it is, why it's useful, why it's problematic, and the fact that it's not allowed in nixpkgs.

Just need to write these down before I forget:

• Dev shells through nix
• wrapping
• overrides
• How to debug builds (nix develop .#)
• hardware acceleration (addOpenGLRunpath)
• Shell Hooks
• Common trivial builders
• patching
• pname + version vs name?
• meta?
• How contribute to nixpkgs
• flakes
• overlays
• Example build section?
  • go
  • cmake
  • gnumake (this is kind of already covered in the stdenv section)
  • autotools
  • rust
  • python

In https://book.divnix.com/ch05-01-language-basics.html#strings, it should probably mention that the maximum indentation level common across all lines in a '' string is stripped.

This section:

The "Phases" chapter seems to be empty. If that's expected, it might help to have a note in there about it.

With Nix and its ecosystem evolving, I expect regular updates of the book.
Consider using https://semverdoc.org/ from the beginning to avoid confusion in the future.

Somewhere in https://book.divnix.com/ch05-01-language-basics.html inherit foo; and inherit (foo) bar baz; should probably be explained, as well as the fact that they can be used in both lets and attrsets.

At this point:

In https://book.divnix.com/ch05-02-functions.html#functions, it should probably mention that the space after the : in function syntax is not optional, especially since it doesn't mention url literal syntax. It's one of the aspects of syntax I found most confusing when learning nix, but as long as url literal syntax is still accepted, we can't do anything about it other than warn about it preemptively.

(x: x) is the identity function, (x:x) is the string "x:x".

Somewhere in https://book.divnix.com/ch04-00-derivations.html#fixed-output-derivations-fods it should probably mention the dangers of doing complex things inside FODs, given that this is a common newbie trap.

Maybe something like:
You may be tempted to put your build process itself into a FOD, particularly if your build system expects network access, but this is generally a bad idea in practice, as it results in fragile hashes, which make the resultant derivation impossible to reproduce before long. FODs should really only be used for processes that can be reasonably expected to produce bit-for-bit identical results, even across updates of the involved software and expected changes in the responses to network requests. Downloading a url, for example.

This:

This:

There may be an upstream nomenclature emerging. When it does, shall we adopt?

Let me find the link, again...

A couple of code examples make use of classical nix, such as import <nixpkgs>.

Since it's already hard to teach nix, it's probably even harder to teach a mixed syntax.

Don't have a strong opinion, this just jumped to my eyes, while flying over the text.

https://book.divnix.com/ch05-01-language-basics.html#attribute-set-attr-set should probably mention that you can set keys in nested attrsets with foo.bar = , and that you can set multiple keys under the same top-level key with multiple lines, not necessarily grouped together:

{
  foo.bar = 1;
  quux = 2;
  foo.baz = 3;
}

The fact that this also works for lets... we can probably skip. :-P

Here are some typos that you can easily find with search:

Should be "its":

because it's assumptions

Typo:

Sytems

Should have capital "D"

Fixed-Output derivations

Misspelling:

yeild the store path that they create

This: