| 8 Aug 2022 |
 David Arnold (blaggacao) | * Zhaofeng Li: I find this resumes well the impetus of a swappable evaluator. We have to introduce the two thought categories of _vartical_ software feameworks and _horizontal_ ones. True _congruent configurations_ (even: _hypercongruent_) need both interfaces. I'm copying my agrument from a private discussion:
> `styx` has the same problem as `colmena` , `deploy-rs`, et al.
> It evolved into a _vertical_ (tool centric) framework that is a bit hard to marry with a _horizontal_ (integration centric) one like `std`.
> I understood this abstract pattern with colemna and came up with a solution that involves for such tooling to have a pluggable evaluator interface to accomodate integration-centric evalutors, while still mostly preserving the look & feel (and branding/docs) of the native tooling. | 17:09:50 |
| David Arnold (blaggacao) | To put it with physics, we need to iprove the bond-energy of otherwise linux-philosophy tool-atoms.
On the command line, the bond is very clear, usually it's |.
But that simplicity doesn't apply for a nix fabric. | 17:15:22 |
| David Arnold (blaggacao) | * To put it with a chemistry analogy to assent the argument: we need to iprove the bond-energy of otherwise linux-philosophy tool-atoms.
On the command line, the bond is very clear, usually it's `|`.
But that simplicity doesn't apply for a `nix` fabric. | 17:15:56 |
| David Arnold (blaggacao) | * To put it with a chemistry analogy to assent the argument: we need to improve the bond-energy of otherwise linux-philosophy tool-atoms.
On the command line, the bond is very clear, usually it's `|`.
But that simplicity doesn't apply for a `nix` fabric. | 17:16:16 |
| David Arnold (blaggacao) | * To put it with a chemistry analogy to assent the argument: we need to improve the bond-energy of otherwise linux-philosophy tool-atoms.
On the command line, the bond is very clear, usually it's `|`.
But that simplicity doesn't apply for a repository-spanning (i.e. world-spanning) `nix` fabric. | 17:16:52 |
| 10 Aug 2022 |
|  luxus joined the room. | 09:54:50 |
 dantefromhell | In reply to @blaggacao:matrix.org
To put it with a chemistry analogy to assent the argument: we need to improve the bond-energy of otherwise linux-philosophy tool-atoms.
On the command line, the bond is very clear, usually it's |.
But that simplicity doesn't apply for a repository-spanning (i.e. world-spanning) nix fabric. very true, as someone who has 20+ years of itops this still feels mostly unresolved and often unthought of.
I'm curious if you can provide more details to the solution you found? | 21:14:41 |
| David Arnold (blaggacao) | 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. | 21:21:43 |
| David Arnold (blaggacao) | From the bundler docs:
A bundler must be a function that accepts an arbitrary value (typically a derivation or app definition) and returns a derivation.
| 23:50:31 |
| 11 Aug 2022 |
 Jane Jasperous | man nix3-bundle | 08:24:47 |
| Jane Jasperous | * man nix3-bundle
and
https://github.com/NixOS/bundlers
| 08:25:57 |
| Jane Jasperous | * man nix3-bundle
and
https://github.com/NixOS/bundlers
I had missed this
| 08:31:04 |
| 13 Aug 2022 |
|  @ronnypfannschmidt:matrix.org joined the room. | 12:01:57 |
|  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 |
