| 2 Sep 2022 |
 Yureka (she/her) | In reply to @blaggacao:matrix.org
But, I don't know if that may break the paraleval I don't think that would be influenced by this kind of change | 18:38:13 |
 Linux Hackerman | same | 18:38:38 |
| Yureka (she/her) | I will try to prepare a PR that solves most of the problem without too many changes | 18:38:40 |
| Yureka (she/her) | If that's fine with y'all | 18:38:51 |
| Yureka (she/her) | first not even focusing on producing a nixosConfigurations, but giving a first stepping stone in that direction | 18:39:14 |
 Zhaofeng Li | In reply to @yuka:yuka.dev
You could just tell the users that the colmena binary has to be from the exact same version as the hive expression There still need to be some kind of versioning and/or a contract, because David Arnold (blaggacao) is making a framework (std) that will emit this structure with its own logic | 18:41:35 |
| Yureka (she/her) | I mean, how is the current interface versioned? | 18:42:16 |
| Zhaofeng Li | The current interface isn't versioned at all and the expressions are embedded into the Colmena executable | 18:43:44 |
| Yureka (she/her) | I mean the interface between that expression and my flake | 18:44:03 |
| Yureka (she/her) | There is still an interface, even if it's at a different level | 18:44:11 |
| Linux Hackerman | (aside: an interface that I'd love to see changed, to avoid mixing the nodes with special attrs like defaults and meta!) | 18:45:07 |
| Zhaofeng Li | In reply to @yuka:yuka.dev
I mean the interface between that expression and my flake That's also poorly defined at the moment, documented mostly as examples. One possibility is to use the NixOS module system to define the schema, which is what NixOps may be heading towards: https://github.com/NixOS/nixops/pull/1508 | 18:47:31 |
| Linux Hackerman | nixos modules for that would be great, I think that approach was pioneered by infinisil in nixus | 18:48:21 |
| Linux Hackerman | defining modules that have the entire deployment as their scope instead of an individual host is 😘🤌 | 18:49:15 |
| Yureka (she/her) | definitely, but I'd like to not mix up multiple issues/improvements too much | 18:49:49 |
| Linux Hackerman | yeah. I'm also not sure that should be colmena's responsibility. | 18:50:11 |
| Yureka (she/her) | https://github.com/yu-re-ka/colmena/commit/cd558fee7f4251719d1101f9677dce2581f6f58e | 19:19:20 |
| Yureka (she/her) | This is enough changes to make it work for me | 19:19:34 |
| Yureka (she/her) | In my flake, I now do:
outputs = { self, nixpkgs, colmena, ... }@inputs: {
colmenaEval = colmena.evalHive {
# whatever was in outputs.colmena before
};
nixosConfigurations = self.outputs.colmenaEval.nodes;
};
| 20:11:45 |
| Yureka (she/her) | though somehow it does not like to do pure eval | 20:12:14 |
| Zhaofeng Li | Yeah, if the git repo is dirty, nix flake metadata will not return a locked flake URI that's usable in pure evaluation mode. That's one gotcha I encountered when looking into pure eval. | 20:13:32 |
| Yureka (she/her) | Does the assets wrapper flake solve this? | 20:14:10 |
| Zhaofeng Li | Yes, the locked URI of the assets flake encompasses the inputs as well. | 20:16:01 |
| Zhaofeng Li | Your solution should work if the git repo is clean | 20:16:35 |
| Yureka (she/her) | In reply to @zhaofeng:zhaofeng.li
Yes, the locked URI of the assets flake encompasses the inputs as well. also if it is a dirty git repo | 20:16:50 |
| Yureka (she/her) | In reply to @zhaofeng:zhaofeng.li
Yes, the locked URI of the assets flake encompasses the inputs as well. * also if one of the inputs is a dirty git repo? | 20:16:56 |
| Yureka (she/her) | I mean it would be neat if I could also use --override-input etc. with colmena | 20:17:16 |
| Zhaofeng Li | * Yeah, if the git repo is dirty, `nix flake metadata` will not return a locked flake URI (with the `narHash` query parameter) that's usable in pure evaluation mode. That's one gotcha I encountered when looking into pure eval. | 20:21:04 |
| Yureka (she/her) | In reply to @linus:schreibt.jetzt
I'm currently doing a hack like
nixosConfigurations = lib.mapAttrs (name: config: let
nodeNixpkgs = self.outputs.colmena.meta.nodeNixpkgs.${name} or self.outputs.colmena.meta.nixpkgs;
nodeNixos = import (nodeNixpkgs.path + "/nixos/lib/eval-config.nix");
in nodeNixos {
modules = [
self.outputs.colmena.defaults
config
inputs.colmena.nixosModules.deploymentOptions
{
_module.args.name = name;
_module.args.nodes = self.outputs.nixosConfigurations;
nixpkgs.overlays = [ nodeNixpkgs.lib.flakeOverlay (import ./overlay.nix) ];
}
];
inherit (nodeNixpkgs) system;
}
) (builtins.removeAttrs self.outputs.colmena ["meta" "defaults"]);
to be able to get at least an approximation of the configs (enough to be able to build it in hydra, for example)
there is a way easier thing to do this | 20:48:11 |
| Yureka (she/her) | that doesn't need any changes to colmena | 20:48:20 |
