| 2 Sep 2022 |
 @linus:schreibt.jetzt | aah. I don't think so then. Not sure though. | 21:08:16 |
 @yuka:yuka.dev | * nix-instantiate -E '... builtins.getFlake ....' --pure-eval. | 21:08:29 |
| @yuka:yuka.dev | options.set_pure_eval(self.path.is_flake()); | 21:09:01 |
| 3 Sep 2022 |
 @blaggacao:matrix.org | In reply to @zhaofeng:zhaofeng.li
There still need to be some kind of versioning and/or a contract, because David Arnold (blaggacao) is making a framework (std) that will emit this structure with its own logic I'm totally fine with a pre-1.0 versioning for the time being (i.e. without special care). I'm pretty used to tracing and chasing upstream changes on a commit basis in the nix ecosystem. | 02:31:36 |
| @blaggacao:matrix.org | In reply to @yuka:yuka.dev
In my flake, I now do:
outputs = { self, nixpkgs, colmena, ... }@inputs: {
colmenaEval = colmena.evalHive {
# whatever was in outputs.colmena before
};
nixosConfigurations = self.outputs.colmenaEval.nodes;
};
I'd do __colmena to be consumed by the CLI... Kind of alludes python's marking of an internal something | 02:34:16 |
| @blaggacao:matrix.org | In reply to @yuka:yuka.dev
Can any of the evaluators take advantage of the eval cache? The only thing on the horizon to make tooling CLI tooling better that itself depends on some sort of Eval output that I know of is numtide/nix-eval-cache. That's not really satisfying, thought. i'd support a builtin.evalCache key thing if that was proposed. | 02:38:43 |
|  @lara:uwu.is joined the room. | 11:35:33 |
|  @ronnypfannschmidt:matrix.org left the room. | 12:06:11 |
