Using nixosSystem? Flake future?

[tv42]

Hi. It seems mainstream NixOS is heading toward using nixpkgs.lib.nixosSystem, and standard ways of defining nixos hosts in a flake.nix: https://nixos.wiki/wiki/Flakes#Using_nix_flakes_with_NixOS

Any thoughts on integrating with that world with colmena? I'm keen to keep my configuration as close to "mainstream" as I can, while using remote deploys (some of my hosts are definitely too weak to build themselves).

It seems mainstream NixOS is getting remote deploys too: nixos-rebuild --flake .#mymachine --target-host mymachine-hostname --build-host localhost switch

[CRTified]

Hi,

I'm solving this problem with a small helper function:

      colmena = {
        meta = {
          description = "My personal machines";
          nixpkgs = pkgs; # This is just a let-binding to `import nixpkgs`, with overlays and so on - not important for this, in general
        };

      } // builtins.mapAttrs (name: value: {
        nixpkgs.system = value.config.nixpkgs.system;
        imports = value._module.args.modules;
      }) (self.nixosConfigurations);

For the nixosSystem-call, I'm then adding this argument:

        extraModules = [ colmena.nixosModules.deploymentOptions ];

Note that you'd typically use the argument modules, not extraModules. modules is used in the colmena host-expression (value._module.args.modules), so using extraModules introduces the whole deployment-option tree for nixos-rebuild --flake .#hostname, without interfering with the colmena deployment.

[blaggacao]

I've noticed recently, that lib.nixosSystem implements a function that adds _file attributes based on heuristics where it's missing.

That's handy to improve error reporting on "anonymous" modules.

[selfuryon]

+1, working with lib.nixosSystem is a more convenient way to work with flakes

[PaulGrandperrin]

Thanks a lot, this should be on the main README! I use a standard flake conf with nixosSystem (from https://nixos.wiki/wiki/Flakes) and I couldn't understand how colmena's example could work for me!

[lovesegfault]

IMO the best solution would be to mimic what deploy-rs does, which is to turn deployments into just an attrset with the config options and one of the keys is the deployment profile path. c.f. https://github.com/serokell/deploy-rs#overall-usage

This lets you integrate seamlessly with any way users might want to generate NixOS configs. For example, I use a similar mapAttrs to the above , but it lets me completely decouple the system config from the deployment info.

[zhaofengli]

I've been hesitant of separating the deployment configs from the system configs due to lower composability (e.g., adding deployment.tags from modules). I have written a bit more on that here. But since https://github.com/zhaofengli/colmena/commit/d4dcf1c6e97efd13151107071c845a52ece7c530, such use cases can now be better supported downstream which can generate evaluated hive configurations without going through the evaluation logic bundled with Colmena (example). This should allow for easier integration with alternative config structures like divnix/std.

[Aleksanaa]

Hey everyone, I've got a better workaround! Just try this:

{ config, self, inputs, ... }:

# add colmena compatibility
let
  conf = self.nixosConfigurations;
in
{
  colmena = {
    meta = {
      description = "my personal machines";
      # This can be overriden by node nixpkgs
      nixpkgs = import inputs.nixpkgs { system = "x86_64-linux"; };
      nodeNixpkgs = builtins.mapAttrs (name: value: value.pkgs) conf;
      nodeSpecialArgs = builtins.mapAttrs (name: value: value._module.specialArgs) conf;
    };
  } // builtins.mapAttrs (name: value: { imports = value._module.args.modules; }) conf;
}

Also tested with flake-parts. Just change colmena to flake.colmena and everything works.

Special thanks to @figsoda for reminding me the specialArgs in _module.

[arachnist]

Hey everyone, I've got a better workaround! Just try this:

{ config, self, inputs, ... }:

# add colmena compatibility
let
  conf = self.nixosConfigurations;
in
{
  colmena = {
    meta = {
…
      nodeNixpkgs = builtins.mapAttrs (name: value: value.pkgs) conf;
…

FYI: I just hit an issue caused by setting the nodeNixpkgs option. tl;dr is that it resulted in nixpkgs.overlays contents being duplicated, and that resulted in a package from another flake being re-evaluated twice, with postInstall script being added twice, and the build failing because of that. See this commit and this post