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.
kubelib.buildHelmChart can take the target Kubernetes version and
a list of custom APIs, so I'll bind them both up in an attrset
and pass them to `flake-builder.releases`.
Accordingly, the other release-builders will have to become variadic.
Also, I had a brief temptation to move `gatherApis` to `flake-builders`,
but apart from being used in the flake's let-in, it has little in common
with the other builders. I need to lose a direct dependency on kubelib
to try the concept out, though (`flake-builders` doesn't take `kubelib`),
and I ended up keeping the result.
Packages can either output new APIs or expect them in the cluster.
Examples of packages which
- output APIs: Gateway API, which installs various versions of
gateway.networking.k8s.io resources.
- take APIs as input: app-template, which queries the cluster to
choose v1a2, v1b1, or v1 for its HTTPRoute (etc.) objects.
("Packages" here collectively refers to Helm charts and YAML bundles.)
I will have to impose strict ordering on them, i.e., build the former
before the latter.
My long-term vision for this flake is to use it as a control flake:
plug it into your homelab ("data-plane") flake and avail yourself
of its `lib.builders`, et cetera.
In short, I want this flake to be useful to many people, and that
means not shipping my homelab with it.
Everything I need directly from nix-kube-generators is now
handled in `lib/`. Additionally, now that I know buildYAMLStream always
takes a namespace and name, there's no need for the longer-winded name.
The reason I struggled with genericBuilders, and again when I replaced
`remoteYAML`'s NS-name `pname` with `url`, is that I was confusing the
following two things:
1. Things that fetch a resource (a Helm chart, a YAML stream, etc.)
without naming or namespacing it.
2. Things that create a release _by_ giving it a name and namespace
so that lib/output.sh can sort the resultant files into directories.
Additionally, I was questioning the good sense of releases/svc/gateway:
a release with no release, but only extra objects? Turns out I
needlessly bound the concept of JIT namespace injection to that
`extraObjects` feature. Once I abstracted that builder, the more general
solution became clear.
By declaring builders at the module level, only to call them in
flake.nix, I give myself the opportunity to inject `{name, namespace}`
there and need no longer pass these args into every module myself.
Even though I've refactored the values into Nix, I'd like them easily
available as YAML. This is impossible to do inside the flake, because
it requires `nix derivation show`, so I made do with a helper script.
I envision the derivation output to be a directory with nested namespace
directories with each release as a single YAML inside.
But I'm currently stuck at the `nix build` part.
charts/ and src/ both have two levels of children:
- charts/$repo/$chart
- src/$ns/$release
So, why not use one function to rake them both?
Also, the leaf-raking doesn't require nixpkgs or nix-kube-generators so
I moved everything that does (e.g.: `downloadCharts`) into the
`eachDefaultSystem` part of the output, following the example of
nixhelm's flake.
