| 1 May 2022 |
 @blaggacao:matrix.org | Totally agree! | 20:18:15 |
 Zhaofeng Li | I'm not really sure about this, as I don't want to guarantee any compatibility for the internal eval API. It limits refactorability and can lead to errors indecipherable to the average user. | 20:29:48 |
| @blaggacao:matrix.org | Hm, I see. Alternatively I could just patch colmena, but that would make me responsible for building and caching, which I generally try to avoid. | 20:42:02 |
| @blaggacao:matrix.org | The problem I have with the built-in interface is that it pertains to 'nix as boilerplate' which is fine for power-users but usually quite a non-starter for nix-newbies. | 20:42:50 |
| @blaggacao:matrix.org | It is a real challenge to present newcomers with a consistent and well-designed system that is explicitly free of adapter code and boilerplate. | 20:43:34 |
| @blaggacao:matrix.org | But on the other hand, ofc, I don't claim that std layout should be any officially supported layout. | 20:43:59 |
| @blaggacao:matrix.org | With that draft PR I was thinking to ship a wrapped colemena version with std that makes use of the --eval flag and a custom / purpose-built evaluator. | 20:45:57 |
| @blaggacao:matrix.org | By not documenting that --eval flag, maybe we might have found an acceptable solution? I'm happy to follow-up on the internal interface when there are changes. | 20:47:19 |
| @blaggacao:matrix.org | .hide(true), that is. | 21:00:11 |
| Zhaofeng Li | I know what you mean, but I'm still not convinced that this brings enough benefits for the headaches it will cause (any addition to eval.nix will break this contract). Can your growOn expose a "normal" outputs.colmena/outputs.colmenaConfigurations? | 21:13:40 |
| @blaggacao:matrix.org | Yes it can, but it's not an option due to the non-nix natives that would be confused by this boilerplate. | 21:14:47 |
| @blaggacao:matrix.org | Also the problem gets exacerbated by the handling of system. | 21:15:25 |
| @blaggacao:matrix.org | Essentially, nixosConfigurations live in all top-level system spaces, but are filtered out if the systems don't match. Reducing that to q multi-system typed outputs.colmena would be probably the largest chunk of any stdized flake and pure boilerplate. | 21:16:50 |
| @blaggacao:matrix.org | * Essentially, nixosConfigurations live in all top-level system spaces, but are filtered out if the systems don't match. Reducing that to a multi-system typed `outputs.colmena` would be probably the largest chunk of any `std`ized flake and pure boilerplate. | 21:17:12 |
| @blaggacao:matrix.org | I mean, my use case is explicitly to make the use of nix friendly enough that strong & principled nix opponents don't veto everything. | 21:18:13 |
| @blaggacao:matrix.org | Another problem might be that I can't do a std-native colmenaConfig action. Because for it to work, any end user would have to replicate that boilerplate.
That also means that we directly load the problem of schema-drift out to all the future end users of that boilerplate.
In this scenario, I think it's better for me to maintain this centrally and collocate colmena and schema with pinned versions. | 21:22:25 |
| Zhaofeng Li | In reply to @blaggacao:matrix.org
Essentially, nixosConfigurations live in all top-level system spaces, but are filtered out if the systems don't match. Reducing that to a multi-system typed outputs.colmena would be probably the largest chunk of any stdized flake and pure boilerplate. Could you elaborate? All the conversion can be done in your opinionated std layer, and there is no boilerplate from the user's perspective if they buy into your view. | 21:22:56 |
