In 0fb8e4d I forgot that flake input-following exists. I don't _have_ to
ship nixhelm myself, but I do need to include it so I can stop bundling
data for an oudated AT version.
In fact, I need not bundle _anything_ for the AT library to be useful;
it's better to make the builder's `chart` arg mandatory and let the user
supply their own (usually taken from nixhelm). If they get bored of
supplying the chart to every AT instance they can factor it out,
as I have in my own deployment.
In fact, my deployment relies on the AT library, which I used to provide
as a flake output -- but it didn't make sense to have one version of the
turboprop library available inside service definitions and another
available outside. So I've made the whole library a flake output.
This may bite me in the future.
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.
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.
- Moved external ServiceEntry generator to `lib.resources`.
- Gave it some company: a generator of HTTPRoutes for gateway/svc.
- Gave `lib.vars.svcGateway` a parentRef generator, at the cost of
another level of recursion, and some variable renaming.
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.
