- https://codeberg.org/kiara
- Joined on
2025-02-04
this seems like a weird merge - sources now seems present in both, yet the rest no longer is? if this can work for one, why not for the rest?
we may want to un-hardcode this deployment method in a future iteration, in line with earlier terminology involving multiple distinct run-time environments with their own providers. this could maybe be handled with an attrTag type.
i'll probably still try and compare with my branch later. either way tho, this looks like a clear improvement over main.
had we revisited this consideration already? what do we see as arguments for either option?
maybe submoduleWith with class arg?
when i tested on my branch, i thought that config here seemed to refer to the configuration set by this policy in the abstract (i.e. with apply and resource-type), rather than the actual instantiated configuration of the policy (i.e. with wheel and username). how did you handle that here?
config = { ... } to contain these two?
why not use deferredModuleWith's class parameter?
i recall in the past sidestepping the simplest test of straight-up verifying the full contents of a deployment had been a cope for unresolved evaluation errors. i imagine mkDeployment / evalModules may complicate full inspection, but out of curiosity, is the set-up here still to any extent a cope?
what's up with the mentioned resources being a function - could it take multiple inputs instead, and how might that affect the interface here?
so these functions now are exposed to requests for other resources as well. did we find a use-case for that? otherwise this may mostly unnecessarily complicate the interface here.
this explicit interface to module functions feels clunky, is this not something that could be handled behind the scenes instead?
one might argue the business logic could include portability aspects as well, but sure
our demo code currently has modules depend on other parts of config as well - down the road we may need to consider if those might function as say resources instead, tho for the purpose of this PR this may do
while this change better aligns the semantics with the naming (input-type, output-type), from the DX perspective this seems to make for a slightly clunkier interface, having to manually invoke submodule on these arguments.