This issue gathers a few ideas I had in mind about batou_ext.nixos.NixOSModule. We talked about the location topic already, but I'd like to have these written down somewhere.
Location of .nix files
The actual Nix expression is now in /srv/s-service/deployment/component rather than /etc/local/nixos. This is not only unexpected (until now one could be sure that everything from AppOps is in /etc/local/nixos), it's also harder to grep for certain patterns in the NixOS configuration on the live system.
JSON vs Nix
I'm wondering if we should rather transform the entire tree into JSON rather than Nix:
Python already has support for (pretty)printing JSON which would save us a lot of code to maintain.
It's probably sufficient to write custom encoders for e.g. Host, Address, etc..
Nix has a builtins.fromJSON and I'd expect it to run quicker than the Nix evaluator given that the JSON parser is pure C++ and far simpler than the one for Nix.
component vs _module.args
The attributes from a component are handed in like this:
{ pkgs, lib, config # from config._module.args
, component # from the Nix file importing this specific file
, ...
}:
The problem I see here is that the arguments in the attribute-set that each module function gets is the value of the option _module.args, we however inject a custom value and bypass the module system which seems unintuitive for people being used to write NixOS modules. Also, we potentially shadow values in _module.args because of //. Generally I'm not sure if we're hitting issues eventually with that now that we leave the path of what's supported and what the module system itself expects.
A common pattern is to define a tree with custom values in config, i.e. config.mydeployment.<...>. Perhaps we want to do something similar here? I.e. config.component.nginx.listen_port where nginx is a component for instance.
This issue gathers a few ideas I had in mind about
batou_ext.nixos.NixOSModule. We talked about the location topic already, but I'd like to have these written down somewhere.Location of
.nixfilesThe actual Nix expression is now in
/srv/s-service/deployment/componentrather than/etc/local/nixos. This is not only unexpected (until now one could be sure that everything from AppOps is in/etc/local/nixos), it's also harder to grep for certain patterns in the NixOS configuration on the live system.JSON vs Nix
I'm wondering if we should rather transform the entire tree into JSON rather than Nix:
builtins.fromJSONand I'd expect it to run quicker than the Nix evaluator given that the JSON parser is pure C++ and far simpler than the one for Nix.componentvs_module.argsThe attributes from a component are handed in like this:
The problem I see here is that the arguments in the attribute-set that each module function gets is the value of the option
_module.args, we however inject a custom value and bypass the module system which seems unintuitive for people being used to write NixOS modules. Also, we potentially shadow values in_module.argsbecause of//. Generally I'm not sure if we're hitting issues eventually with that now that we leave the path of what's supported and what the module system itself expects.A common pattern is to define a tree with custom values in
config, i.e.config.mydeployment.<...>. Perhaps we want to do something similar here? I.e.config.component.nginx.listen_portwherenginxis a component for instance.