👍

@edolstra @rbvermaa This needs to wait for NixOS/nixpkgs#2540 for the new flag to be usable, but can you comment on any of the design decisions here before then? Anything blocking a merge once nixpkgs is ready?

Why is the --modular-expressions flag needed? It seems undesirable to have two distinct modes of evaluation.

@rbvermaa insisted this be backwards compatible, I can think of many hacky heuristics but no foolproof way to automatically distinguish between modular and non-modular deployments.

Do you have examples of modular networks somewhere? I seem to remember so but I can't find them.

All of the ones we have contain private info currently, I can scrub one and upload it somewhere but essentially it looks like:

{
  imports = [ ./some-module-with-options.nix ];

  # environment is an option that for example defaults all machines to vbox when "development"
  zalora.environment = "development";

  description = "My network";

  resources.machines.machine = { pkgs, ... }: {
    environment.systemPackages = [ pkgs.hello ];
  };
}

Also in addition to the normal config, options, lib arguments each deployment-level module gets passed a deployment argument as an alias for config

Closing as this doesn't seem wanted.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/colmena-yet-another-nixos-deployment-tool/11506/22