Refactoring in Nixos
Table of Contents
- system is not a package and vice versa
- symlinking the store derivation path to the package dir of src
- writing a pill to build p and calling s,q from it to get p'
- writitng a flake with builinputs including q,s, get p''
- pinning to the git commit of p, eg using import ,which has q,s' in the system level flake or config file
- write a shell which does one or more of the above to keep the p-env independent of system level env
- more provisioning , refactoring
- Observations
- in/correct builds can share the profile, so profile is innocent, unless found otherwise.
- Analysing the diff of the build (or profile) pair can help trace the exact culprit, do that before filing a bug report
- flake –rollback or switch-generation works, iff you have an older profile, else you need to reboot from the last working profile and then rebuild-switch be get the configuration, building which you broker the build/
- Once fixed set that profile as default boot
- deterministic
- Logic in Flakes
- patterns
Why
CI/CD without continuous refactoring is digital equivalent of horading – @GrdayBooch
Test case - Lisp env for Emacs
What
You are doing n projects with conflicting deps,envs and due overlaps.
Intersection I in configuration.nix.
In shell.nix
Instead of too many crossing symlinks
This gets tricky
Say you get sbcl in a ~/workdir with nix shell, which doesn't import system env
How
Say your make file for a lib/package has both internal and of course external conf
mySourceRegexes = [ "^app.*$" "^.*\\.cabal$" "package.yaml" ];
Deps
Self
Itself - (recursive) 1
Super
Let application or function to Compose everything else and return to self, add set of all the properties, itself, constraints , accessed dep paths to it, as your function composes everything (dep from self and returns everything to itself. Its like symlinking or man fetching clothes fromt the closet and wearing them.
Loops in, loops around
the sub/supersets of parametrs , as it accesses them and fetches them
What does it call itself
attr
Trasitive dep 2
code can generate them and parse them, like a graph
name
pname
shell name
env name
Transitive closure of dependency relationships - Includsion of references
You can define the process precisely with Natural Deduction using the inference rules
how do they combine ?
Like sur/nick name
attrname + commit hash -> version
pname3 $INPUT, version -> package name
curl -/-> any of this : pure vs impure
How does it call itself
callpkg
let
otherwise
Key ideas
system is not a package and vice versa
However, a package p may depend d on other set of system-level-packages s : {S} or its own set of plugins packages q: {Q}
This can be resolved by either
symlinking the store derivation path to the package dir of src
writing a pill to build p and calling s,q from it to get p'
writitng a flake with builinputs including q,s, get p''
pinning to the git commit of p, eg using import ,which has q,s' in the system level flake or config file
write a shell which does one or more of the above to keep the p-env independent of system level env
more provisioning , refactoring
Observations
in/correct builds can share the profile, so profile is innocent, unless found otherwise.
Analysing the diff of the build (or profile) pair can help trace the exact culprit, do that before filing a bug report
flake –rollback or switch-generation works, iff you have an older profile, else you need to reboot from the last working profile and then rebuild-switch be get the configuration, building which you broker the build/
Once fixed set that profile as default boot
deterministic
later
Process Isolation
one process/ kernel/machine/ metal , unlike flakes , to which you can add as many build inputs as you need.
| OS | Kernel | machine | Metal |
|---|---|---|---|
| sunixi | Metal | ||
| hermitux | docker | Pine | |
| Nixos | Genode | ||
| OSv | firecracker | RISC V | |
Logic in Flakes
patterns
single repository
Gentoo puts package descriptions all in a single repository.
"inputs" pattern allows our expressions to be easily customizable through a set of arguments. These arguments could be flags, derivations, or whatever else. Our package expressions are functions
reaptedly overriding , reusing patterns and keeping them maintainable
using a central repository like nixpkgs, and defining overrides on our local machine without even modifying the original package
Created: 2022-11-16 Wed 10:01