If someone particularly interested in the documentation / discovery / help problems has time for a project, mining Ianās whole series of Nix posts for actionable bits would be a good one.
(Some actionable bits might be doc fixes/additions, some might be things that the community can help out with via blog posts / videos / etc.)
The last post on getting nix-shell to work with any shell itās invoked (zsh) is a big win I think.
Iād love to understand how to upstream that.
fwiw, you can do this without any real effort if you use direnv
You revealed a bug in my OpenGraph titles
mining Ianās whole series of Nix posts for actionable bits would be a good one
I have actually done this mining myself, having read over all of my posts as a precursor to making documentation improvements. (Which I havenāt⦠actually done. Post forthcoming with weak excuses as to why).
But if anyone is hankering to improve the docs⦠just rewrite the quick start guide. I believe itās the single biggest source of pain and confusion for self-taught Nix newcomers. As a close second, rewrite the example derivation so that itās a default.nix
instead of a Nixpkgs contribution, so that people can actually follow along with it.
Beyond those, here are my raw, unedited notes to myself. Lots of subjective opinions, so take these with a few grains of salt:
- Glossary
- Definition of āderivationā is not useful to someone who doesnāt already know what a derivation is.
- Says that substitutes live in the Nix database, which they donāt.
- The definition for āvalidityā is completely circular. Never explains how a derivation might be invalid.
- āStore derivationā is a term used frequently ā including in the glossary! ā but never defined.
- installation
- For the macOS instructions, the diskX bit is confusing. But otherwise itās pretty good, I thought.
- quick start
- Almost nothing in the quick start guide is correct.
- 9
- documentation around
--file
could be better -
nix-env -qas
is not good. Usenix-env -qasA
. - This is the first time we see the term āset.ā
- documentation around
- 10
- Diagram of profiles is immensely complicated and unnecessary.
- It would have helped me if the manual explained that every file is symlinked (maybe mention something about
fixupPhase
canonicalizing the locations so that that makes sense?)
- 11
- It was weirdly hard for me to figure out where the nix config file is supposed to live? The man pages do not really explain this.
- No explanation of
keep-outputs
orkeep-derivations
. Or rather, the explanation given actively lies about what they do? It is at least very misleading.
- 12
-
.tar.bz2
is now.tar.xz
.
-
- 14
- Written assuming
nixpkgs
, which is not good - I think the treatment of stdenv isnāt great
- Should describe function call syntax; thatās not going to be familiar to a lot of people.
- āBuilding something from other stuff is called a derivation in Nixā
- āWe perform a derivationā
- āmkDerivation is a function provided by stdenv that builds a package from a set of attributes.ā
- Uses āsetā instead of attribute set
- Should call out that a path is not a string.
- Mention that the
$stdenv
env var is set becausestdenv.mkDerivation
- Maybe some pointers to later discussions of
stdenv
? - I was very confused whether or not
$stdenv
was required. - Mention that
fetchurl
is a derivation- āThe
src
attribute was bound to the result of fetching the Hello source tarball from the network, so thesrc
environment variable points to the location in the Nix store to which the tarball was downloadedā
- āThe
- āThe
perl
environment variable points to the location of the Perl package (since it was passed in as an attribute to the derivation)ā could be more clear - Maybe mention that this script must create ā
$out
ā as a file or directory
- Written assuming
- 14.3
- This is describing how to add a package to
nixpkgs
. It should describe how to write a simpledefault.nix
file instead. -
foo = import bar { inherit qux; };
maybe deserves a callout explaining how to parse that. - I was upset by the
callPackage
thing, but I donāt think thereās really anything to change there.
- This is describing how to add a package to
- 14.4
- āYou can now try to build Helloā no⦠you canāt. The manual has not given a working example at this point.
- This is where i got confused by the
bin/
thing, but I think that should be explained earlier, not here. - āThe
-A
option selects thehello
attributeā is confusing to me.
- 14.5
- āGeneric Builder Syntaxā no it isnāt
- I thought
pkg/nix-support/setup-hook
was stale, because I didnāt realize that it was talking about a path in the Nix store, not the Nixpkgs repo.
- 15
- āIts main job is to describe packages, compositions of packages, and the variability within packages.ā I still have no idea what this statement is supposed to mean.
- Maybe worth mentioning that because Nix is expression-oriented, every file has one value.
- Should really mention
nix repl
right off the bat.
- 15.1
- I hate that ābasic typesā are separate from regular types. Show me all the types at once.
- Derivations are not listed as a type, although they sort of are their own type, maybe, in some ways that I still donāt understand.
- The string interpolation section is very confusing; just show concrete examples. Nix Pills has a better treatment.
- Should mention paths can like⦠filter files. They are not isomorphic to strings.
- Sets should use the term āattribute setsā at least once, to prevent frustration.
- The
__functor
example is very confusing, usingx
twice in two different contexts.
- 15.2
- I would call out the difference between variables and bindings.
- 15.4
- āTo figure out your platform identifier, look at the line āChecking for the canonical Nix system nameā in the output of Nixās configure script.ā Or justā¦
builtins.currentSystem
. - I had a really bad time by not setting
out
as an output name. There shouldnāt be an example in the manual that does that. - I had a lot of trouble with
args
; I donāt think thatās too important. Maybe a note that you shouldnāt useargs
; you should use environment variables instead. - āEach output path is a concatenation of the cryptographic hash of all build inputs, the name attribute and the output nameā oxford comma
- This section is about derivations but it never actually says what a derivation is. Nor does the section on types.
- āTo figure out your platform identifier, look at the line āChecking for the canonical Nix system nameā in the output of Nixās configure script.ā Or justā¦
- 15.5
- Never explains
throw
vsabort
. No idea what the difference is. -
toString
might want to mentiondrvPath
in addition to__toString
- Absolutely no idea what
builtins.placeholder
is for. -
seq
anddeepSeq
are not explained. - This list leaves out lots of other builtin functions.
- Never explains
- 18
- āThis hook is only executed if the results are not the same, this hook is not used for determining if the results are the same.ā should be a semicolon
- 19
- āusing theā title is cut off
- 20
- There is documentation in this chapter about arrays, and an example of array indexing with
foo.3.bar
syntax. This concept just⦠doesnāt seem to exist in Nix? What is this?
- There is documentation in this chapter about arrays, and an example of array indexing with
- 22
-
--set-flag
is sort of weird and confusing. But this barely matters. - The manual uses the term āpackageā when I think it means āderivation.ā Unless it actually means like⦠derivations with a
meta
field? I donāt know. The term āpackageā is never defined or explained. - Manual states that
nix-shell
āDefaults to thebash
found inPATH
.ā This is⦠technically true, pretty misleading. I would say that it defaults tonixpkgs.bashInteractive
in yourNIX_PATH
, and falls back to yourPATH
'sbash
if that doesnāt exist.
-
Thanks for compiling this. It will be really helpful with GitHub - divnix/nix-book: The Nix Package Manager