!UUqahLbShAYkkrXmKs:matrix.org

DevOS

35 Members
Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga10 Servers

Load older messages


SenderMessageTime
21 Jul 2021
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid Arnold (blaggacao)At least, that's my currently best answer to the problem. But probably it's not the last?20:43:11
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid Arnold (blaggacao)I see the problem 😄20:45:35
@fufexan:matrix.orgfufexanthis makes sense, thanks for the thorough explanation!20:45:41
@blaggacao:matrix.orgDavid 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:matrix.orgfufexan

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:matrix.orgfufexan 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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:matrix.orgfufexan😲 that makes sense20:55:32
@fufexan:matrix.orgfufexanI haven't thought of that20:55:37
@blaggacao:matrix.orgDavid Arnold (blaggacao) Beware, the order of overlays is important. so wine-tkg overlay would have to go before winestreamproxy overlay 20:56:16
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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:matrix.orgfufexan

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:matrix.orgfufexanoh wait not this one21:00:47
@fufexan:matrix.orgfufexanokay it seems like it was that one21:01:34
@blaggacao:matrix.orgDavid Arnold (blaggacao) when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. 21:01:39
@blaggacao:matrix.orgDavid Arnold (blaggacao) * when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. 21:01:46

Show newer messages


Back to Room ListRoom Version: 6