... instead of loading both keys and raise an error
This is important for testing when one wants to override SOPS_AGE_KEY_FILE
New prio: `SOPS_AGE_KEY` > `SOPS_AGE_KEY_FILE` > `~/.config/sops/age/keys.txt`
Move the `tests` folder to `clan_cli/tests`.
As we now want part of our tests to live next to the functions that are
tested - tests that are not in the `/tests` module also need access to
the configured test fixtures that are exposed by the `pytest_plugins`
declaration.
The following folder structure doesn't support this model:
```
├── clan_cli
│ ├── api
│ │ └── api_init_test.py
├── tests/
│ ├── conftest.py
│ └── ...
```
Here `api_init_test.py` even when importing the test functions will not
have the fixtures configured.
There is a way to configure python to import the fixtures from another
[`project/module`](https://docs.pytest.org/en/stable/how-to/fixtures.html#using-fixtures-from-other-projects), but this seems to *generally* be discouraged.
So moving the `conftest.py` to the toplevel and the `/tests` folder into
the toplevel seems to be a sensible choice choice.
* Switch `Generator`'s `validation` from a regular property to
an `@property` annotated method backed by `Machine`'s `eval_nix()`.
* Ensure that `Machine`'s flake cache is flushed after each
effectful generator execution (rather than only after all
generators have been executed).
* Additionally, update `insert`'s input type hint to support None values
(as they are already selectable and (one shot) insertable).
This is necessary to appease the linter wrt the added test.
On macOS mktemp returns a temporary directory in a symlink.
Nix has a bug where it won't accept path:// located in a symlink.
This avoid this issue by always resolving symlinks as returned by
TemporaryDirectory.
We implement that by actually raising `KeyError` in `inventory.delete_by_path`
(as advertised in the docstring), since it makes more sense to catch a
`KeyError` than a generic `ClanError`.
When a machine is deleted with `clan machines delete`, remove its
vars and legacy secrets, and update any secrets that reference the
machine's key.
This command is a superset of `clan secrets machine delete`, and I am
wondering if we could remove the `clan secrets machine` subcommand,
unless there is an use case for having a machine defined without its
key, and any secrets/vars?
Note:
- This deletes the `ListSecretsOptions` dataclass, as it did not seem to
bring any value, especially since `list_secrets` was receiving its
individual members instead of the whole dataclass. We can always bring
it back if complexity grows to demand it.
- `delete` lets you delete a specific var under a specific generator;
- `delete_store` deletes an entire store.
The `delete` method could be useful to "garbage-collect" unused vars as
a machine's configuration changes.
The `delete_store` method can be used to delete all the vars for a
machine when the machine is deleted. The current behavior is to leave
everything behind.
Important point:
- `delete_store` needs to be idempotent because public and
"private"/"secret" vars for a machine can share the same physical
store (directory), and deleting either type of store (public or
private) will delete both.
