The `clan.core.vars.settings.passBackend` option has been replaced with
`clan.vars.password-store.passPackage` to provide better type safety and
clearer configuration.
Changes:
- Remove problematic mkRemovedOptionModule that caused circular dependency
- Add proper option definition with assertion-based migration
- Users setting the old option get clear migration instructions
- Normal evaluation continues to work for users not using the old option
Migration: Replace `clan.core.vars.settings.passBackend = "passage"`
with `clan.vars.password-store.passPackage = pkgs.passage`
- Remove deployment.json file generation from outputs.nix
- Add throw for deprecated deployment.file usage with upgrade instructions
- Remove vars data from deployment.data
- Update Machine class to use direct select() calls instead of deployment property
- Update all deployment property accesses to use direct selectors
- Add precaching for frequently accessed values in update.py:
- Module paths for facts and vars
- Deployment settings (requireExplicitUpdate, nixosMobileWorkaround)
- Services and generators data
- Secret upload locations
- This removes unnecessary JSON serialization and makes the code more composable
For secrets not part of the nix store there is no other way in NixOS to
restart a service after the secret is updated. One example is changing
password in userborn, which doesn't run as a activation script but as a
systemd service.
This filters the secrets to only include the secrets managed under `per-machine` and `shared`,
otherwise new deployments will fail, when using the vars module for multiple machines:
```
[vyr] /nix/store/[…]sops-install-secrets: failed to decrypt '/nix/store/[…]/sops/vars/per-machine/draper/garage/admin_token/secret': Error getting data key: 0 successful groups required, got 0
```
This doesn't fix all the edge cases with this approach.
We get a similar error if we deploy shared vars that are not
encrypted for our machine key. This needs to be addressed when
implementing the shared vars functionality.
