| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
the store of course makes a distinction, but that is not relevant here
|
|
|
|
the longer SHA-256 hashes are not truncated, but in fact processed.
Co-authored-by: Thomas <twatson52@mac.com>
|
|
Co-authored-by: Thomas <twatson52@mac.com>
|
|
|
|
Nix omits E O U T characters for some reason.
|
|
Nix itself does care a lot about what type of store object you have.
|
|
Co-authored-by: Thomas <twatson52@mac.com>
|
|
|
|
this has the weird but nice emergent property that terms at the same
height are roughly at the same level of abstraction.
|
|
this is not as compact any more, but it more closely resembles the
chapter structure, and clearly shows that the closure property is the
key idea on which most of Nix operates.
|
|
|
|
invert arrows to/from derivation:
- we need closures to form derivations
- we need derivations to perform builds
|
|
this should help nativate the chapter by indicating which terms should
be known to understand a given concept.
|
|
the various levels of detail should describe the same things.
|
|
try not to be too fancy, it's just for reading the diagram out loud.
|
|
clarify that we are copying between different stores. we have not
introduced that notion or why it would be interesting, but for now it
should be fine to keep it in context of the store directory.
we could move that later to a more detailed explanation of different
store types.
|
|
using JSON notation is unwarranted and not explained.
|
|
use singular for terminology uniformly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: John Ericson <John.Ericson@Obsidian.Systems>
|
|
garbage collection is now incremental, and may (in theory) never delete all unreferenced objects if it is slow enough.
|
|
at this level of abstraction we do not really care about build instructions or what they are, and also build instructions including their arguments really amount to the build task.
|
|
this also looks more diverse, hopefully easier to distinguish
Co-authored-by: John Ericson <John.Ericson@Obsidian.Systems>
|
|
|
|
|
|
|
|
group description of data instead of spreading it across the section.
that should help direct skimming. as it turns out, people do not
actually read any of that.
|
|
|
|
change prose description to visually resemble the data structure
|
|
|
|
|
|
|
|
|
|
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>
|
