I've enjoyed participating in the docs team but lately I haven't had the time
to attend the meetings and contribute.
My interests lie elsewhere in Nix at the moment and I would like to dedicate my
time to exploring them.
rephrase slightly for brevity and clarity.
re-use the examples from the ad-hoc environment tutorial both for
simplicity as well as to give it some continuity.
Co-authored-by: Alexander Groleau <alex@proof.construction>
remove references to "towards reproducibility" as that's not very
focused, and at that point readers will likely be familiar with the
concept such that they only need the reference, if anything
this fits the global outline we developed, and also makes the tutorial
more immediately visible - working with the Nix language is a core skill
we want to teach after all
readers don't even need to think about it, as it's encoded in the pinned
source. at best this would be a note to maintainers, but we should know
that as well.
- use the same Nixpkgs release to avoid massive downloads
- continue using `pkgs.nixosTest`; the new thing is completely undocumented
- use a shorthand module; `lib` is not used
- use an empty nginx config; commented-out code is confusing
- move explanation of the test script to the end; use imperative
- add instructions to run it
while section headings are good for linking, this is not very important
here. the heading distract from the sequential structure, which the list
exposes more clearly.
change "build task" to "derivation" in tutorial
"build task" invokes associations with pre-existing knowledge. As long as they are clearly explained, it is easier for beginners to pick up a new word than it is to add a new definition to an existing word that subtly differs from the other definitions it has. To that extent, "derivation" is probably a great word for Nix as, at least in this domain, it is very Nix specific and so, with clear definition, it should be easy to convey the idea to other folks that we are talking about something Nix specific.
