The motivation is to create one powerful entrypoint shared by the GUI as well as the CLI in order to not having to maintain too much separate code paths.
As a next step, generate_vars can probably also be removed.
Changed sandbox_exec_cmd to return a context manager that automatically
handles profile file cleanup. This ensures the temporary profile is
always removed, even if exceptions occur.
Adds macOS sandboxing support similar to Linux bubblewrap implementation:
- Created clan_lib/sandbox_exec module with sandbox profile creation
- Implemented file system isolation allowing only tmpdir and nix store access
- Added network restrictions (deny outbound except localhost)
- Integrated sandbox-exec command into vars generation on macOS
- Added comprehensive test suite for macOS sandbox functionality
- Fixed working directory handling for generators writing to CWD
Stores now get machine context from generator objects instead of storing
it internally. This enables future machine-independent generators and
reduces coupling.
- StoreBase.__init__ only takes flake parameter
- Store methods receive machine as explicit parameter
- Fixed all callers to pass machine context
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`
- Change Generator class to store machine name as string instead of Machine reference
- Update Generator.generators_from_flake() to only require machine name and flake
- Refactor check_vars() to accept machine name and flake instead of Machine object
- Create Machine instances only when needed for specific operations
This continues the effort to reduce dependencies on the Machine class,
making the codebase more modular and easier to refactor.
Replace all calls to machine.vars_generators() with direct calls to
Generator.generators_from_flake() to make the dependency more explicit
and remove unnecessary indirection.
This reduces coupling to the Machine class, making the codebase more
modular and easier to refactor in the future.
- Remove _serialized field from vars interface to prevent serialization
errors with throwing passBackend field
- Implement direct selection of generator fields using multi-select syntax
- Refactor vars_generators() to use new Generator.from_flake() method that
selects only safe fields (avoiding non-serializable values)
- Remove unused legacy methods: Generator.from_json(), Var.from_json(),
Prompt.from_json()
- Update precaching to match new selection approach
This fixes the serialization errors that were preventing vars from working
with the new password-store implementation by avoiding the problematic
_serialized field entirely.
- 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
- Remove nix(), eval_nix(), and build_nix() methods from Machine class
- Add select() method that handles machine-specific attribute prefixes
- Update all usages to use machine.select() directly
- Handle Path conversion and tmp_store logic at call sites
- This simplifies the Machine API and prepares for deployment.json removal
This makes it clear that this should be used with care
It is potentially more expensive to create the full object, therefore it should be discouraged by its longer name
This listing is implemented based on the basic listing, where each item is turned into the bigger machine class
