| 31 Jul 2021 |
|  yusdacra changed their profile picture. | 17:17:58 |
 @timdeh:matrix.org | I can't remember... did we ever decide to export profiles, so one can use another devoser's profiles from their own configuration? | 23:47:55 |
| @timdeh:matrix.org | David Arnold: Pacman99 ? | 23:50:18 |
| @timdeh:matrix.org | * David Arnold: Pacman99 ? ^^ | 23:50:28 |
| 1 Aug 2021 |
 David Arnold (blaggacao) | No, only modules or whole configs. | 01:10:27 |
| David Arnold (blaggacao) | I'm not sure if sharing profiles would be really a good idea, in theory. Modules are the "generics" and profiles the concrete implementation. I find it to be a good balance between convenience and responsibility to pass "ownership" of any concrete implementation to the user. | 01:12:49 |
| David Arnold (blaggacao) | It might be just the right amount of an "entry level" challange to onboard users. | 01:13:43 |
| David Arnold (blaggacao) | But that presumes a world where modules are crafted in such ways that they can best serve that "onboarding challange". | 01:14:39 |
| David Arnold (blaggacao) | * It might be just the right amount of an "entry level" challenge to onboard users. | 01:24:34 |
| David Arnold (blaggacao) | * But that presumes a world where modules are crafted in such ways that they can best serve that "onboarding challenge". | 01:24:45 |
| David Arnold (blaggacao) | The problem with sharing profiles is that we might drift into the real of mkForce, which isn't terrible, but surely a "semantic deviation". | 01:26:00 |
| David Arnold (blaggacao) | * The problem with sharing profiles is that we might drift into the realm of `mkForce`, which isn't terrible, but surely a "semantic deviation". | 01:26:52 |
 Pacman99 | Yeah I proposed the idea a while ago but I don't really support it anymore for that reason | 01:32:18 |
| Pacman99 | Profiles doesn't really make sense to share | 01:32:48 |
| David Arnold (blaggacao) | Maybe we can orchesteate a momentum to produce more "shareable" modules, though. That is ones that where carefully made with an downstream user in mind. | 01:40:46 |
| David Arnold (blaggacao) | * Maybe we can orchesteate a momentum to produce more "shareable" modules, though. That is: ones that are carefully made with an downstream user in mind. | 01:41:06 |
| David Arnold (blaggacao) | * Maybe we can initiate a momentum to produce more "shareable" modules, though. That is: ones that are carefully made with an downstream user in mind. | 01:41:27 |
| David Arnold (blaggacao) | * Maybe we can initiate a momentum to produce more "shareable" modules, though. That is: ones that are carefully made with a downstream user in mind. | 01:41:56 |
| David Arnold (blaggacao) | If a module implements a "styled"/"fashioned" or "enhanced" upstream module, it can still made be generically available through an enable flage, where the profile then just implements the enable = true. | 01:45:37 |
| David Arnold (blaggacao) | * If a module implements a "styled"/"fashioned" or "enhanced" upstream module, it can still made be generically available through an `enable` flage, where the profile then just implements the `enable = true`. Does that make sense? | 01:45:49 |
| @timdeh:matrix.org | I mean, we could just let it be known that profiles are more opinionated and users should pull the source and modify them directly if they want to change them. I just think it could help onboarding more than anything to have a working configuration an import away, and if you mature and decide to change it, just rebase, modify or start from scratch from there. | 02:43:07 |
| @timdeh:matrix.org | Or we could simply make a wrapper around all profiles, to pass mkDefault to all values, making them trivially overridable. | 02:44:12 |
| David Arnold (blaggacao) | In reply to @timdeh:matrix.org
Or we could simply make a wrapper around all profiles, to pass mkDefault to all values, making them trivially overridable. That could be an interesting idea 👍 | 02:48:12 |
| David Arnold (blaggacao) | This issue seems to be a recurring problem when resolving merge conflicts on updating from core to develop | 04:05:56 |
| David Arnold (blaggacao) | * This issue seems to be a recurring problem when resolving merge conflicts (the wrong way) on updating from core to develop. It seems logical to keep ones own modifications, but in this case, they need dropping. And rather it needs to be revised if rake leaves does actually rake the same leaves as /module-list.nix and otherwise that folder needs restructuring. A typical issue that is caused by this: https://github.com/divnix/devos/issues/351 | 04:07:59 |
| @timdeh:matrix.org | also, the iso seems to be broken if any other fileSystem entries exist for root, which would be pretty common if your making one of your system or even the generic host atm. | 04:34:18 |
| David Arnold (blaggacao) | In reply to @timdeh:matrix.org
also, the iso seems to be broken if any other fileSystem entries exist for root, which would be pretty common if your making one of your system or even the generic host atm. That should be a matter of bumping nicpkgs, see: https://github.com/NixOS/nixpkgs/pull/131760 | 04:46:32 |
| David Arnold (blaggacao) | (it's backported to 21.05) | 04:47:03 |
| @timdeh:matrix.org | is this in nixos-unstable? | 04:47:19 |
| @timdeh:matrix.org | no, only nixpkgs-unstable | 04:48:31 |
