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

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.