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.

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.

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.

Now, input schema enforcement is on the bundler (which is fine and absolutely what we want anyways).

Output schema enforcement can be placed on the bundler (and can be even provided by a flake input coming from Colmena).

So when a bundler updates the colmena output schema reference, then it would also emit appropriate errors if that new schema isn't satisfied by a target flake.

Vice-versa, the cli can do a preflight check on the bundler (nix eval targetbundled#colemna-version) and error out if compatibility cannot be guaranteed.

In reply to @tpw_rules:matrix.org
is the nixpkgs in the colmena meta used for all thehosts?

In reply to @tpw_rules:matrix.org
is the nixpkgs in the colmena meta used for all thehosts?