There are several ways to run services on NixOS - NixOS itself, Home Manager, oci-containers, quadlet-nix... I would love to see extractors for all the popular methods in nix-topology. All these extractors could share a common service registry (names and icons). I am creating this issue to discuss an architectural proposal - to split the services registry from extractors/services.nix.
I proposed a design in PR #81, but that PR grew in scope, so I'm splitting out the architectural discussion here. Basically, it is an attribute set in a separate file, each service is described with a name, icon and identifying information: NixOS config path or a set of well-known container image names.
{
adguardhome = {
name = "AdGuard Home";
icon = "services.adguardhome";
nixos = {
path = [
"services"
"adguardhome"
];
enabled = cfg: cfg.enable or false;
detailsFn =
cfg:
let
address = cfg.host or null;
port = cfg.port or null;
in
mkIf (address != null && port != null) {
listen = {
text = "${address}:${toString port}";
};
};
};
oci = {
repos = [ "adguard/adguardhome" ];
};
};
alloy = {
name = "Alloy";
icon = "services.alloy";
nixos = {
path = [
"services"
"alloy"
];
enabled = cfg: cfg.enable or false;
detailsFn = _: { };
};
oci = {
repos = [ "grafana/alloy" ];
};
};
}
This way, service extractors can take care only of the actual extraction, without having to declare the list of services separately. And if this registry is exposed to users, they will be able to describe new/absent services and display custom information without having to make changes to nix-topology.
This refactoring can be done in a separate smaller PR. There are already two PRs for oci-containers and I would like to create an extractor for quadlet-nix as well, this change would be the first step towards new service extractors.
There are several ways to run services on NixOS - NixOS itself, Home Manager, oci-containers, quadlet-nix... I would love to see extractors for all the popular methods in nix-topology. All these extractors could share a common service registry (names and icons). I am creating this issue to discuss an architectural proposal - to split the services registry from
extractors/services.nix.I proposed a design in PR #81, but that PR grew in scope, so I'm splitting out the architectural discussion here. Basically, it is an attribute set in a separate file, each service is described with a name, icon and identifying information: NixOS config path or a set of well-known container image names.
This way, service extractors can take care only of the actual extraction, without having to declare the list of services separately. And if this registry is exposed to users, they will be able to describe new/absent services and display custom information without having to make changes to nix-topology.
This refactoring can be done in a separate smaller PR. There are already two PRs for oci-containers and I would like to create an extractor for quadlet-nix as well, this change would be the first step towards new service extractors.