i don't think it's clunkier. after letting it rest for a couple of days I actually was surprised why the field is not of type optionType, because why can a function not be str -> str?
the deployment method is decidedly not hard-coded here at all. the environment owner specifies that by providing an implementation, where they can use any provider just the way they want.…
transposing may be slightly easier on the eyes in the two places where we iterate over resources. not sure, it's just a thought we can ignore until it starts hurting. at the moment we don't have…
I don't think it makes a difference here, except more braces?
no, mkDeployment is simply required to at least get something out of the deployment's module expression. looking inside is not very helpful though, as you see from the test. it has a bunch of…
in this example, the "single NixOS VM" environment has a shell as a resource.
divergent thought: if we could deploy single users to NixOS VMs (why not, in principle), a shell could play the…
why would it take multiple inputs? here in the test we only touch it in order to do some granular analysis of intermediate steps. in practice this is not part of the public interface. each…
it sure is clunky, but that's what we have to ensure type safety. we don't strictly require it, we may as well reduce implementation to functionTo output-type, but it makes things more…
oh yeah, maybe it should also say "as far as it is currently encoded".
the purpose of this PR is exactly to show a minimal example that one can still understand in limited time. in practice you will probably want a resource of the size and complexity of an entire…
proxmox-*.sh scripts
Because that's how one tends to wrap Bash scripts with Nix. What I mean is more like: We have an executable here. Wrap that executable in a derivation and do everything in there. Then whatever…
But why didn't we move the derivations to build as checks in to checks? Then the change to the YAML could have been roughly nix flake check.
makeResourceModule
If you want to be extra clever, you can do name = builtins.baseNameOf ./.;
makeResourceModule
We may as well have a module that sets _module.args, the additional imports and imports ./common/resource.nix, because that is what all of these share. The extra split into *Injector doesn't make it more obvious what's happening.
proxmox-*.sh scripts
I mean, this is a NixOps4 proxmox provider in disguise, just turned inside out, right?
proxmox-*.sh scripts
Hm, I'm generally rather confused why we call a bash script through nix-shell --run rather than building a script with writeShellApplication and run that after building it with Nix. Too late to complain now, but still, why actually?