In reply to @linus.heckemann:matrix.mayflower.de
that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string

In reply to @linus.heckemann:matrix.mayflower.de
Is there a way to pass the flake inputs on to all machine configs? I'd like to do things like imports = [ "${inputs.nixos-mailserver}/default.nix" ]; in my machine configs.

In reply to @zhaofeng:zhaofeng.li
You can pass the inputs using either meta.specialArgs.inputs = inputs; or _module.args.inputs = inputs; in a node config

In reply to @github:maunium.net
[zhaofengli/colmena] JCapucho opened issue #50: Nixpkgs fails to build on unstable

Hi, I'm using colmena with a flake to build a node that uses the nixos-unstable branch of nixpkgs (commit is https://github.com/NixOS/nixpkgs/commit/689b76bcf36055afdeb2e9852f5ecdd2bf483f87), but it's failing to build.

In the start of the log I see a warning with

capucho-nixos | trace: warning: The following Nixpkgs configuration keys set in meta.nixpkgs will be ignored: path

Which leads me to believe that the issue might be caused by ignoring the path attribute introduced in https://github.com/NixOS/nixpkgs/pull/153594

Here's the log of running colmena build --show-trace --verbose log.txt

In reply to @linus.heckemann:matrix.mayflower.de
maybe specialArgs doesn't have that problem though? I'll give it a try

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 :>