- https://codeberg.org/kiara
- Joined on
2025-02-04
down the road we may want to look into guaranteeing our different components use and expect the same structure, but having any check here definitely improves on what we had already :)
if we were to at some point plug existing nix modules into this, we might consider a schema export ignoring (rather than crashing on) fields too complex in their defaults/type. i don't know if clan cares for a PR in that direction, otherwise we could fork.
looking forward to the PR, both to clarify/explain the diff, as well as to separate concerns - as far as i'm concerned (until merged) feel free to pull this from such a fork rather than inlining here
iiuc this is still unused (as per your comment below)?
what's the replacement for? maybe clarify in a comment
@kevin makes sense. i guess with the declarative approach of our form putting it in the form kinda sucks too, as it would then remain exposed. that maybe seems like a broader challenge in our…
4f4bea2a01
use a mutable HOME in TF for nixos-anywhere to make a .ssh dir in - will this not backfire?
8e83f5b00c
untrack TF generated provider/module stuff - local dev now requires following launch/README.md
be9cbfb8c5
update nixos-anywhere to fix error 'installable ... does not correspond to a Nix language value'
caa497c4a2
get TF in prod to the same 'installable ... does not correspond to a Nix language value' for non-flakes
2ed7f3ebe5
get TF in prod to the same 'installable ... does not correspond to a Nix language value' for non-flakes
in the PR description, please reference the underlying ticket to [auto-close](https://docs.gitea.com/1.18/usage/automatically-linked-references#actionable-references-in-pull-requests-and-commit-mes…
it's okay if you like to do logging, but if you'd like to be able to leave them in then please use a logger over print