| 21 Jul 2021 |
 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 |
 fufexan | this makes sense, thanks for the thorough explanation! | 20:45:41 |
| David Arnold (blaggacao) | ... but not in your case with the well crafted overlay. Let's see for a while if we need to come up with a better solution. | 20:46:14 |
| fufexan | what I wanted to split the overlay for was, I have it in this repo but I want to import wine-tkg and winestreamproxy to be used in my dotfiles overlay, which looks like this
{ inputs }:
let
osu = inputs.osu-nix.overlays;
in
final: prev: {
discord-electron = prev.callPackage ./discord {
branch = "stable";
pkgs = prev;
};
kakoune-cr = prev.callPackage ./kakoune.cr { inherit (inputs) kakoune-cr; };
picom-jonaburg = prev.picom.overrideAttrs (
old: { src = inputs.picom-jonaburg; }
);
rocket-league = prev.callPackage ./rocket-league {
wine = final.callPackage osu."nixpkgs/wine-tkg" { };
winestreamproxy = final.callPackage osu."nixpkgs/winestreamproxy" { };
};
technic-launcher = prev.callPackage ./technic-launcher { };
}
| 20:48:18 |
| fufexan | now I'm not sure if callPackage is the way to do this, but it seems to work with neither that nor import ... {} | 20:48:56 |
| David Arnold (blaggacao) | Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
{
pkgs = import nixpkgs { config = {}; overlays [ osu."nixpkgs/wine-tkg" osu."nixpkgs/winestreamproxy" ];};
wine-tkg = pkgs.wine-tkg;
}
| 20:55:10 |
| David Arnold (blaggacao) | * Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
{
pkgs = import nixpkgs { config = {}; overlays [osu."nixpkgs/wine-tkg" osu."nixpkgs/winestreamproxy" ];};
wine-tkg = pkgs.wine-tkg;
}
| 20:55:16 |
| David Arnold (blaggacao) | * Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
{
pkgs = import nixpkgs { config = {}; overlays [
osu."nixpkgs/wine-tkg" osu."nixpkgs/winestreamproxy"
];};
wine-tkg = pkgs.wine-tkg;
}
| 20:55:28 |
| fufexan | 😲 that makes sense | 20:55:32 |
| fufexan | I haven't thought of that | 20:55:37 |
| David Arnold (blaggacao) | Beware, the order of overlays is important. so wine-tkg overlay would have to go before winestreamproxy overlay | 20:56:16 |
| David Arnold (blaggacao) | * Overlays would have to be applied, then the packages are avaliable as usual. Something like:
{
pkgs = import nixpkgs { config = {}; overlays [
osu."nixpkgs/wine-tkg" osu."nixpkgs/winestreamproxy"
];};
wine-tkg = pkgs.wine-tkg;
}
| 20:57:10 |
| David Arnold (blaggacao) | * Overlays would have to be applied, then the packages are available as usual. Something like:
{
pkgs = import nixpkgs { config = {}; overlays [
osu."nixpkgs/wine-tkg" osu."nixpkgs/winestreamproxy"
];};
wine-tkg = pkgs.wine-tkg;
}
| 20:57:18 |
| fufexan | now nix flake check fails with
error: attribute 'currentSystem' missing
at /nix/store/vmcb8svgl9h84mkqmg1nazl9zgpgn7q0-source/pkgs/top-level/impure.nix:18:43:
17| # (build, in GNU Autotools parlance) platform.
18| localSystem ? { system = args.system or builtins.currentSystem; }
| ^
19|
| 21:00:21 |
| fufexan | oh wait not this one | 21:00:47 |
| fufexan | okay it seems like it was that one | 21:01:34 |
| David Arnold (blaggacao) | when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. | 21:01:39 |
| David Arnold (blaggacao) | * when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. | 21:01:46 |
| fufexan | then how should I set the system for pkgs? | 21:02:05 |
| David Arnold (blaggacao) | I can't say much about the concrete reasons of the above error, though. | 21:02:14 |
| fufexan | I feel like I'm either over-complicating something or overlays are that complicated themselves | 21:02:41 |
| fufexan | maybe I shouldn't do what I want using overlays? | 21:02:53 |
| David Arnold (blaggacao) | when you use fup you can pass overlays to the channel's overlaysBuilder | 21:03:55 |
| David Arnold (blaggacao) | Then fup will spit out self.pkgs.<channelname> with the overlays applied. | 21:04:20 |
| fufexan | oh, so that will propagate and I will be able to use prev.wine-tkg for example? | 21:04:53 |
