I think this interface is not necessary and using the equivalent upstream interfaces would lead to less confusion.

• In a flakes world, the way to determine meta.nixpkgs would be as follows: inputs.colmena.inputs.nixpkgs.follows = "";

It is really a nightmare in terms of composability to have this attribute exposed via meta. I wonder if it would be possible instead to expose it via the normal (composable) module system and shallow evaluate for peek. something like this:

let
  colmenaNixpkgs = {
    options.colmenaNixpkgs = {};
  };
in (nixpkgs.lib.evalModules { modules = [colmenaNixpkgs]; check = false; }).colmenaNixpkgs

I saw your efforts to speed up evaluation. This might be a project that you might keep an eye on: https://github.com/kamadorueda/santiago

Not immediately useful.

• the reason for this change is to have more transparent separation of concern between effectuations of the module system and pre-module system effectuations

• with improved flakes support down the line, pre-module system effectuations will get more complex

• if the code was clean before, this does not introduce a change in behaviour. Unclean prior code, could now be surfaced by this.

In reply to @jhillyerd:matrix.org
Hi. Thinking about moving my legacy nixops config over to colmena+flakes. I know colmena doesn't create machines on the fly, which is fine since I'm running my setup on bare metal. But I like testing on VMs first when I make big changes. How does one go about testing against a staging environment in colmena? Import that same config into two different host entries?

Something like this in your flake should give you the VMs as a nix build .#vm-hostname target:

  packages = with nixpkgs.lib;
    mapAttrs' (host: sys: {
      name = "vm-${host}";
      value = sys.config.system.build.vm;
    }) self.nixosConfigurations;