| 21 Jul 2021 |
 David Arnold (blaggacao) | Oh I forgot: https://digga.divnix.com/ | 16:15:17 |
| David Arnold (blaggacao) | * Oh I forgot: https://digga.divnix.com/ (initial digga docs are live) | 16:15:29 |
 fufexan | In reply to @blaggacao:matrix.org
fufexan: would you mind also looking over digga's develop branch with the critical eye that inspired https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/84 ? yes, sure thing | 20:15:40 |
| fufexan | how does the lib.exportOverlays work in practice? I'm trying to understand what would get output as "nixpkgs/winestreamproxy" coming from this overlay
{ inputs }:
final: prev: {
osu-stable = prev.callPackage ./osu-stable {
wine = final.wine-tkg;
winetricks = prev.winetricks.override { wine = final.wine-tkg; };
inherit (final) winestreamproxy;
};
winestreamproxy = prev.callPackage ./winestreamproxy { wine = final.wine-tkg; };
wine-tkg = prev.callPackage ./wine-tkg {
wine =
if prev.system == "x86_64-linux"
then final.wineWowPackages.unstable
else final.wineUnstable;
inherit (inputs) tkgPatches oglfPatches;
};
}
| 20:16:55 |
| fufexan | I get that it outputs something like "nixpkgs/winestreamproxy" = final: prev: { }; as written in the doc, but I don't really get what's in the set | 20:17:36 |
| David Arnold (blaggacao) | So it tries to give clearly identifiable names "channel/winestreamproxy" to every overlay. Each overlay was crafted for a specific channel, which still is a local reference. But having a clue what the author regarded as "nixpkgs" at the time of crafting an overlay might get the consumer an idea with wich channel of his own this overlay probably might have a better chance of working. | 20:36:35 |
| David Arnold (blaggacao) | * So it tries to give clearly identifiable names "channel/winestreamproxy" to every overlay. Each overlay was crafted for a specific channel, which still is a local reference. But having a clue what the author regarded as "nixpkgs" at the time of crafting an overlay might get the consumer an idea with which channel of his own this overlay probably might have a better chance of working. | 20:36:56 |
| David Arnold (blaggacao) | in the end, the cuonsumer has to try to know for sure, but if there is something like nixos-19.03/some, then the user might probably be able to guess that it's not going to work with master | 20:37:39 |
| David Arnold (blaggacao) | * in the end, the consumer has to try to know for sure, but if there is something like nixos-19.03/some, then the user might probably be able to guess that it's not going to work with master | 20:37:44 |
| David Arnold (blaggacao) | In reply to @fufexan:matrix.org
I get that it outputs something like "nixpkgs/winestreamproxy" = final: prev: { }; as written in the doc, but I don't really get what's in the set So this would be completed as: final: prev: { winestreamproxy = ...} | 20:38:26 |
| David Arnold (blaggacao) | In reply to @fufexan:matrix.org
I get that it outputs something like "nixpkgs/winestreamproxy" = final: prev: { }; as written in the doc, but I don't really get what's in the set * So this would be completed as: "nixpkgs/winestreamproxy" = final: prev: { winestreamproxy = ...} | 20:38:43 |
| David Arnold (blaggacao) | As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a spearate overlay. | 20:39:38 |
| David Arnold (blaggacao) | * As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. | 20:39:44 |
| David Arnold (blaggacao) | * As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. A good example would be if you manage a single overlays.nix file with all your overlays defined according to your personal needs. A consumer might want to pick one out of these. | 20:40:46 |
| David Arnold (blaggacao) | * As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. A good example would be if you manage a single overlays.nix file with all your overlays defined according to your personal needs. A consumer relatively likely might want to pick one out of these. | 20:40:54 |
| David Arnold (blaggacao) | In you well-crafted example, this splitting does not make a lot of sense and the overlay could / should be consumed as a whole. I think we can't have enough guarantees that overlays will always be well crafted though, so we have to sort of put that burdon on the consumer. | 20:42:52 |
| David Arnold (blaggacao) | At least, that's my currently best answer to the problem. But probably it's not the last? | 20:43:11 |
| David Arnold (blaggacao) | * In you well-crafted example, this splitting does not make a lot of sense and the overlay could / should be consumed as a whole. I think we can't have enough guarantees that overlays will always be well crafted though, so we have to sort of put that burdon (of managing overlay dependencies) on the consumer. | 20:43:59 |
| David Arnold (blaggacao) | I see the problem 😄 | 20:45:35 |
