| 1 May 2022 |
 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 |
 David Arnold (blaggacao) | 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 |
| David Arnold (blaggacao) | Also the problem gets exacerbated by the handling of system. | 21:15:25 |
| David Arnold (blaggacao) | 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 |
| David Arnold (blaggacao) | * 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 |
| David Arnold (blaggacao) | 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 |
| David Arnold (blaggacao) | 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 |
| David Arnold (blaggacao) | Well, the flake.nix is a user flake. It needs to have a co.pat layer right there to work with colmena. | 21:24:01 |
| David Arnold (blaggacao) | std has no middle ware to do that conversion for the user. | 21:24:38 |
| David Arnold (blaggacao) | Essentially, std has just gotten rid of it's last compatibility layer that projected the schema onto something that nix itself requires. | 21:25:41 |
| David Arnold (blaggacao) | The reason is that rhe end user should also have a consistent view of the std mental model when entering the repl. | 21:26:17 |
| David Arnold (blaggacao) | The only way to communicate metadata in std is .#__std. | 21:26:37 |
| David Arnold (blaggacao) | (by design) | 21:26:46 |
| Zhaofeng Li | So you are essentially expecting all tools to be .#__std-aware (either natively or through some out-of-tree hackery like this), not the other way around. I'm not sure that this is a workable way forward. | 21:33:54 |
| David Arnold (blaggacao) | The problem with the other way round is that it very fundamentally breaks a homogeneous out-of-the-box experience.
std expects for it's purpose (and within it's boundaries) self.outputs to be it's exclusive domain.
It therefore expects all tools that it ships with to be schema neutral. | 21:39:53 |
| David Arnold (blaggacao) | If adapters are necessary, they can be done by the user via std.growOn. But the user has to conscientiously implement those adapters. | 21:41:07 |
| David Arnold (blaggacao) | So for an out-of-the-box experience, std expects tooling that it ships with to be flake schema-neutral | 21:42:52 |
| David Arnold (blaggacao) | std.grow, on the other hand, can't produce an output schema that doesn't correspond to the folder layout. | 21:45:16 |
| David Arnold (blaggacao) | In reply to @zhaofeng:zhaofeng.li
So you are essentially expecting all tools to be .#__std-aware (either natively or through some out-of-tree hackery like this), not the other way around. I'm not sure that this is a workable way forward. For clarification, that is actually not technically correct. .#__std is the mechanism by which metadata is transferred to the TUI, including actions. Those actions can transport an arbitrary command sequence. | 22:45:34 |
| David Arnold (blaggacao) | So these actions could just provide plain colmema commands with its built-in schema.
But then, I couldn't provide such actions out of the box, because they would depend on the compatibility layer, which is the user's domain. | 22:47:14 |
| David Arnold (blaggacao) | * So these actions could just provide plain `colmena` commands with its built-in schema.
But then, I couldn't provide such actions out of the box (for `copmena`), because they would depend on the compatibility layer, which is the user's domain. | 22:47:40 |
| David Arnold (blaggacao) | * So these actions could just provide plain `colmena` commands with its built-in schema.
But then, I couldn't provide such actions out of the box (for `colmena`), because they would depend on the compatibility layer, which is the user's domain. | 22:47:47 |
| 2 May 2022 |
 Wanja Hentze | Would you accept a PR to that effect, or do you prefer to do this yourself? | 13:13:52 |
| David Arnold (blaggacao) | Zhaofeng Li: I added a harvester: https://github.com/divnix/std/issues/60#issue-1223217085 for easier compat. But it still wouldn't accept to be system-neutral. That mapping is just too complicated. | 18:43:27 |
| 6 May 2022 |
|  Jeff joined the room. | 04:36:25 |
| 7 May 2022 |
|  dantefromhell joined the room. | 00:45:18 |
