Code Staging in GNU Guix
describes the code staging process for package definitions in Guix package manager; mainly describing roam:Guix G-expressions
creating package definitions often certain parts of the definitions to carry through the build stage; oftentimes, these parts of code include additional build instructions for non-trivial packages and additional inputs for that package
while S-expressions (sexp) are nice, they can be verbose at times; this is where G-expressions (gexp) comes in handy
gexp are hygenic — they preserve lexical scope across different stages
they can easily refer to the high-level objects (e.g., packages, local file) in the store (i.e.,
/gnu/store)first-class Scheme values
binds deployment to staging — when brought into staging, all inputs are also deployed as well
use cases for gexps
code sharing between multiple stages; this is mostly present such as defining packages and building them
cross-compilation — there are additional operators to denote "nativeness" where it will refer to the "native" version rather than the target version
package definitions — less verbose definitions which is always nice especially with the use of referring to the absolute file names from the store
system services — the process and lifecycle of system services is similar to defining packages being composed of multiple stages: one in definition and one in building the services in the init system
system tests — they can be defined through the
operating-systeminterface which are derivations describing entire operating systems; in Guix, this is implemented through a tool calledmarionettewhich introduces another stage in the pipeline