In reply to @linus.heckemann:matrix.mayflower.de
I tried the latter, it resulted in infinite recursion in combination with imports = [ inputs.nixos-mailserver ];

{ config, pkgs, inputs, ... }:

{
  imports =
    [
      inputs.nixos-mailserver.nixosModule
    ];

In reply to @linus.heckemann:matrix.mayflower.de
also, a feature I'd like in colmena: the ability to pass in nixos evaluations rather than nixos configs. That would open up a lot of possibilities, including a nixus-like system where the whole deployment can be made of nixos modules too. Not sure if that goes within the "vision" of colmena though, and if not that's fine --- I don't want colmena to succumb to feature creep either :)

In reply to @zhaofeng:zhaofeng.li
Admittedly I ran into the problem a couple of weeks ago in my setup when I rebased against master, but there were comments about it blocking the channel so I disabled it locally without looking closer. Then I kind of forgot about it 🙁

In reply to @linus.heckemann:matrix.mayflower.de
also, a feature I'd like in colmena: the ability to pass in nixos evaluations rather than nixos configs. That would open up a lot of possibilities, including a nixus-like system where the whole deployment can be made of nixos modules too. Not sure if that goes within the "vision" of colmena though, and if not that's fine --- I don't want colmena to succumb to feature creep either :)

I thought more about it, and don't think it's a good idea since the deployment options are version-specific and Colmena depends on the structure to deserialize it correctly. Colmena should be self-contained, and confusing errors can easily occur if we allow people to "bring their own deployment options" which is required if you want to pass in an evaluated config directly.

Exposing the deployment option module for external use is fine, but Colmena should use its own when it's the one running the deployment.

In reply to @zhaofeng:zhaofeng.li

I thought more about it, and don't think it's a good idea since the deployment options are version-specific and Colmena depends on the structure to deserialize it correctly. Colmena should be self-contained, and confusing errors can easily occur if we allow people to "bring their own deployment options" which is required if you want to pass in an evaluated config directly.

Exposing the deployment option module for external use is fine, but Colmena should use its own when it's the one running the deployment.

In reply to @willi:butz.cloud
I did the exact same thing. I'll check the fix later today

I verified that it's fixed on v0.2.1.

had to comment out buildOnTarget though :>

In reply to @willi:butz.cloud

I verified that it's fixed on v0.2.1.

had to comment out buildOnTarget though :>

Jane Jasperous: You can just use imports. e.g.

colmena.my-host = { name, nodes, ... }:
  imports = [
    a-module
   (import another-module.nix)
];

Jane Jasperous: You can just use imports. e.g.

colmena.my-host = { name, nodes, ... }:
{
    imports = [
      a-module
     (import another-module.nix)
  ];
};

Jane Jasperous: You can just use imports. e.g.

colmena.my-host = { name, nodes, ... }:
{
   imports = [
     a-module
    (import another-module.nix)
  ];
};