| 13 Aug 2022 |
|  farcaller joined the room. | 14:26:22 |
| farcaller | o/ I'm a bit confused as to where do I start, given colmena requires a host that's already running nixos (unless I missed anything?) can I just nix-build some base image for a vm myself then? do I need to be somehow specific about it? | 14:28:16 |
| farcaller | actually looking at what it did to a test system it seems that it pretty much wiped everything kubevirt builder did and got the “new” nixos rolling. Am I correct to assume that the base system is effectively lost configuration wise so it doesn’t really matter what I boot into? | 15:33:26 |
|  problems joined the room. | 17:08:05 |
 jhillyerd | Yeah, that's typically how nixos deploys work, the base system is mostly lost. | 17:24:00 |
| farcaller | gotcha, thanks for clarifying | 17:27:47 |
| jhillyerd | I think the old channel configs hang around, so you can end up with some very old environments when using nix-env or nix-shell on those hosts. Not sure if there is a better way to control that. | 18:12:35 |
| farcaller | efficiency wise that means I can’t quite build a base image and finish the configuration with colmena because that will effectively overwrite everything and negate any benefits of deploying from a snapshot, right? | 18:24:44 |
| jhillyerd | If the base and the colmena config are built off of different versions of nixpkgs, then yes, you'd be uploading mostly new /nix/store contents | 18:25:59 |
| farcaller | oh right; and I can freeze those. | 18:28:31 |
| farcaller | thanks! | 18:28:35 |
| 15 Aug 2022 |
|  tim joined the room. | 06:10:23 |
| 16 Aug 2022 |
|  @ruddy:leohoo.xyz joined the room. | 12:12:19 |
| @ruddy:leohoo.xyz left the room. | 12:12:22 |
|  rdk31 joined the room. | 19:39:44 |
|  kayla (she/they) joined the room. | 21:30:57 |
| 17 Aug 2022 |
 Zhaofeng Li | In reply to @blaggacao:matrix.org
Well, colmena uses an evaluator (instead of for example the nix bundle interface) in order to parallelize the evaluation. So at its heart, it's a speed consideración.
The receptor interface is established in src/nix/eval.nix and that defines the incoming schema as well as the intermediate schema that can be processed by the CLI.
There are two solutions:
- don't use an evaluator, but rather consume a well-knowm flake attribute (which is already evaluated - this is the
divnix/std approach with __std)
- make the evaluator swappable
colmena --eval ./path/to/eval.nix so that you can consume arbitrary inout contracts via a custom evaluator.
Since colmena strives for optimization and parallelization, the second option is really the beat choixe.
For something like divnix/styx, I don't know yet, I'll probably just going to wrap the nix bundle interface within the CLI. It's probably not parallelized, but it is easly swappable for a custom evaluator. WIP, so I might get more insight as I go. Ok, finally have some time for Colmena, so let's talk about swappable eval. My primary concern with it is that it may limit the potential for larger changes to the deployment flow, such as support for something like profiles/activators in deploy-rs. I'm also a bit wary of wrapped versions of Colmena with the swappable evaluator overridden exhibiting totally different behavior, causing confusions with the user. | 03:03:38 |
| Zhaofeng Li | A new related development is that flake evaluation is finally pure [1]. The current implementation is to generate a temporary flake containing eval.nix and friends that depends on the user flake as an input.
[1] For nix-instantiate at the moment. The streaming evaluator nix-eval-jobs requires a change to be upstreamed.
| 03:03:56 |
 Winter (she/her) | Has anyone noticed their building with buildOnTarget get slower recently, or is this just me/my network? Even with an existing copy (build then apply), the copying 0 paths... takes way longer than it has in the past/should. | 05:03:59 |
| Winter (she/her) | Not sure how I'd debug this, though. | 05:04:20 |
| Winter (she/her) | * Not sure how I'd debug this, though, as it's most likely a Nix issue or a networking issue... idk. | 05:44:39 |
 David Arnold (blaggacao) | An eval is a transformer that enriches one data-structure with something else to emit a different datastructure that the CLI then consumes. In theory, there is nothing in the evaler that one couldn't also do directly in the target flake.
So it offloads the implementation of an interface onto the tooling when it is considered closer to the tooling domain in order to reduce boilerplate or enforce order on the origin data structure.
That enforcing of a certain order on the origin datastructure is contentions because it forces convergence outside of the tooling domain (where it was precisely deemed more appropriate). This time: not conformance to the target data structure, but to the expected input interface. | 19:23:22 |
| David Arnold (blaggacao) | Actually, similar to my styx approach, I belive that Colmena, instead of working with a wrapper flake, could also make most benefit of the nix bundle interface which doesn precisely that job, is pure, and if I'm not ill-imformed, even has (or could have in future) specialized cross-flake caching support (unlike anything else). | 19:25:33 |
| David Arnold (blaggacao) | * Actually, similar to my `styx` approach, I belive that Colmena, instead of working with a wrapper flake, could also make most benefit of the `nix bundle` interface which does precisely that job, is pure, and if I'm not ill-imformed, even has (or could have in future) specialized cross-flake caching support (unlike anything else). | 19:25:52 |
