| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
this leaves open implementation details, especially about store paths
and file system objects, and allows explaining them together were it is
more appropriate. also leaves room to carefully introduce the key
insight behind Nix: applying results from programming language theory to
the operating system paradigm of files and processes.
|
|
while this may eventually introduce ugly diffs, the table will now
render readably on the terminal (e.g. for `man nix` or `nix --help`)
without further intervention.
|
|
|
|
while it appears a bit much for the overview, this way we set the stage
for going directly into data types when describing the store, instead of
first having to say what build tasks are and how they relate to build
plans.
|
|
do not introduce build tasks yet, that is the next level of detail.
|
|
|
|
this displays correct composition again. build inputs and build results
are not part of build plans in terms of data objects.
also this is a much less complicated setup. this will be the first
impression of architecture, and we want to get it right.
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
the overview should only link to the three main concepts presented. the
store is now fairly fleshed out. others can follow later.
|
|
|
|
update summary title to match file contents
|
|
|
|
|
|
closer to "build systems a la carte", satisfies all other complaints
|
|
"step" sounds atomic, while "rule" hints at internal structure, which in
our case consists of mapping inputs to outputs using build instructions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
