"Helm releases" is what I'd been terming individual services, but
it makes no sense outside of the internal context of the Helm builder.
I also didn't want to call them "apps", however shorter that term is.
These are not apps.
I've changed release modules' signatures from:
`{lib} -> ... -> <drv>`
to:
`{lib} -> ... -> {out=<drv>; extra=<drv>;}`
Which makes individual derivations more easily findable.
Now, instead of picking them out from a soup of paths in `output.sh`
with a specially-crafted needle (`${ns}-${name}`), I map derivations
directly to paths and use the result as a sort of index. In other words,
I spent some ingenuity in `flake-builders.sh` to save a _lot_ of
ingenuity in `output.sh`.
This affords me the extra convenience, previously spurned because of
the very limitation I've overcome, of symlinking derivations in the
output flake.
I try to insert line breaks where a thought fragment ends (a habit
learnt from writing subtitles), but in comments and Git commit
messages it doesn't make as much sense.
I have my answer to 2638113, and it's what I was suspecting: the
flake-builder was never using clusterData until I added a release
that needs it, at which point I got the dreaded "error: attribute
'apiVersions' missing".
Remediation was simple: realize the wrongheadedness of passing
an empty attrset when the values are already well-known.
Line 62 of this commit's flake.nix should bail with an attribute-missing
error while evaluating `buildDerivations.releases`, at the point where
Nix tries to inherit two variables from an empty `clusterData`.
...Or is it that I will have problems when I add something using
lib.builders.helmChart to `./system`? I'll only find out tomorrow.
- Clarify nature of release paths.
- Explain why I haven't bothered to wedge values.yaml files into the
default derivation.
- Move drv_matcher to copy_drv_output, where it conceptually belongs.
