In reply to @dantefromhell:matrix.org
i'm curious if tests as described here suffice your requirement?
https://nixos.mayflower.consulting/blog/2019/07/11/leveraging-nixos-tests-in-your-project/

In reply to @dantefromhell:matrix.org
i'm curious if tests as described here suffice your requirement?
https://nixos.mayflower.consulting/blog/2019/07/11/leveraging-nixos-tests-in-your-project/

In reply to @dantefromhell:matrix.org
i'm curious if tests as described here suffice your requirement?
https://nixos.mayflower.consulting/blog/2019/07/11/leveraging-nixos-tests-in-your-project/

Can I also run the evaluation of my configuration on a separate host? Currently working around multiple issues where I can't update the configuration of my x86_64 Linux host, because I am running on a M1 Mac.

I was able to work around the issue of

error: assertion '(stdenv).isLinux' failed

by running a Linux (micro-)VM. Unfortunately evaluation still fails because of my architecture:

error: Package ‘iucode-tool-2.3.1’ in /nix/store/bwkwywd5wrwlk7106vi3z6d96dfhpdc7-source/pkgs/os-specific/linux/microcode/iucode-tool.nix:19 is not supported on ‘aarch64-linux’, refusing to evaluate.

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:

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.

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.

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?

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.

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.

man nix3-bundle

and

https://github.com/NixOS/bundlers

man nix3-bundle

and

https://github.com/NixOS/bundlers

I had missed this