note that this does not yet contain the 'type check', as this does not
function yet.
this could be added in `data-model.nix` like:
```nix
function-type-check = mkOption {
type = application.config.config-mapping.function-type;
readOnly = true;
default = input: {
inherit input;
output = application.config.config-mapping.implementation-type
input;
};
};
```
... or even to `function.nix` itself, like:
```nix
function-type-check = mkOption {
type = config.function-type;
readOnly = true;
default = input: {
inherit input;
output = config.implementation-type input;
};
};
```
Closes#103
At last, a fully fledged data model for what Fediversity really is and does. This comes with a test that exercises a very simple but functionally complete arrangement with all ingredients fo the business logic: a dummy resource (login shell), a dummy application (`hello`, which needs a shell to live in), a dummy environment (a single NixOS VM that allows for one, the operator's, login shell), and a deployment of that environment given a dummy configuration (that enables `hello`).
The next step will be to lift this purely evaluation-level test into a VM test which verifies that the resulting VM indeed has `hello` deployed to the operator's user account.
Caveats:
- The exact naming has a bit of room for improvement, and may have diverged from the design document
- The test is not as pedantically type safe as it could be, since we simply use `types.raw` for resources such as NixOS users settings which *could* be more finely delineated
Co-authored-by: Kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-on: Fediversity/Fediversity#481
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-committed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
