| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
convention: describe every data type in prose, and illustrate with
a class diagram, and a textual representation of an abstract
data type.
right now we save ourselves the trouble of doing class diagrams, we can
add them later. but they are important.
|
|
use file Contents instead of Data, as that flows more naturally in the
prose.
simplify explanation of the idea behind scanning for store paths
remove references to unfinished sections.
|
|
- use singular for the "class"
- more consistency in type definition
- minor fixes in wording
|
|
it should be pulled out of the branch before we go for merging
|
|
|
|
|
|
|
|
attempt to explain used and documented terminology, as well as how
the declarative programming paradigm relates to building software.
in the future one could highlight encouraged terms to shape future
material into higher consistency.
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
|
|
|
|
following ideas found in Architecture of Gazelle[1]
[1]: https://github.com/bazelbuild/bazel-gazelle/blob/56d35f8db086bb65ef876f96f7baa7b71516daf8/Design.rst
|
|
|
|
the diagram is a first approximation and only covers that same section.
of course there is much more going on, and other features should at some
point also be illustrated.
we also have to think about presentation format and technicalities
behind it. the manual has to render to `man`, but we may want something
more refined for web view.
|
|
there should be a meta section for each chapter to give motivation of
the presented structure. the structure itself is visible from the table
of contents.
|
|
idea: sections could be read in different orders by linking them in
different ways (e.g. depth-first or breadth-first). adding hard-coded
transitions makes that confusing.
|
|
Co-authored-by: Valentin Gagarin <valentin@fricklerhandwerk.de>
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
we will use a translation table to introduce nix-specific terms
|
|
trying to capture alternative terms in one go here, mirroring everyday
use:
derivation - build plan
realise - execute build
there will be more of that sort.
|
|
The idea and most of the execution are @fricklerhandwerk's. I changed a
few things best I could based on @edolstra's corrections, and a Bazel
glossary.
Valentin Gagarin <valentin@fricklerhandwerk.de>
|
|
|
|
|
|
See https://edolstra.github.io/pubs/phd-thesis.pdf, page 91.
|
|
|
|
|
|
|
|
In particular, Nix is *not* like Git, so that needs to be fixed.
|
|
|
|
|
|
This matches the terminology in Eelco's thesis.
|
|
Co-authored-by: Matthieu Coudron <teto@users.noreply.github.com>
|
|
Co-authored-by: Valentin Gagarin <valentin@fricklerhandwerk.de>
|
|
Co-authored-by: Valentin Gagarin <valentin@fricklerhandwerk.de>
|
|
Co-authored-by: Valentin Gagarin <valentin@fricklerhandwerk.de>
|
|
|
|
|
|
They are too advanced for up front.
|
|
|
|
|
|
|
|
The current docs are all "how to do things" and no "what is Nix" or "why
are things the way they are".
I see lots of misconception on the wider internet, and I also think we
would benefit from a "living document" to answer some questions people
currently turn to the thesis for.
I think a new section of the manual can address all these issues.
|
|
it is out of date, all over the place in level of detail, is really
about `nixpkgs`, and in general instructions should not be part of
a reference manual.
also:
- update redirects and internal links
- use "Nix language" consistently
|
