| 10 Oct 2023 |
|  @cafkafk:gitter.im changed their display name from Christina Sørensen to cafkafk. | 03:39:06 |
| @cafkafk:gitter.im changed their profile picture. | 03:39:26 |
| 11 Oct 2023 |
 @piegames:matrix.org | inherit (callPackage ../desktops/gnome/extensions { })
gnomeExtensions
gnome38Extensions
gnome40Extensions
gnome41Extensions
gnome42Extensions
gnome43Extensions
gnome44Extensions
gnome45Extensions
;
I find this a bit silly, since I'm simply inheriting all attributes from the attrset. This is noisy, adds churn and is error-prone.
I know that using something like by-name isn't a thing yet for package sets, but why couldn't I just // (callPackage ../desktops/gnome/extensions { }) to the attrset instead? Much simpler and less pain to maintain
| 14:35:32 |
 infinisil | piegames: That would give you infinite recursion, because the attribute names of an overlay now depends on final | 14:36:15 |
| @piegames:matrix.org | Ah and also as I've recently learned, the above is sub-optimal in the current Nix interpreter, because it will stupidly re-do the callPackage import for every single attribute | 14:36:20 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: That would give you infinite recursion, because the attribute names of an overlay now depends on final Um, I don't understand that | 14:36:38 |
| infinisil | piegames: I guess here's a way to show the problem: What if the gnome extensions set defines callPackage = ? | 14:40:02 |
| @piegames:matrix.org | Hm, fair. Can we somehow prevent that with some infrastructure? Some helper function which says "import everything from here into our attrset, and make sure to use super.callPackage to avoid infinite recursion" | 14:42:49 |
| @piegames:matrix.org | On the other hand, shouldn't this still work as long as the package set doesn't define a callPackage? Because stuff is lazy etc. | 14:43:28 |
| @piegames:matrix.org | Well, attribute names are not, but still | 14:43:39 |
| infinisil | Actually lazy attribute sets would allow this: https://github.com/NixOS/nix/issues/4090 | 14:43:59 |
| infinisil | piegames: It can't now whether it defines a callPackage without evaluating it | 14:44:25 |
 tomberek | lazy attrsets... lazy attsets ... lazy attrsets. Or __getter (https://github.com/NixOS/nix/issues/8187#issuecomment-1501258036) or builtins.mkProxy..... or something | 14:45:43 |
| @piegames:matrix.org | Hm, are there any other ways to solve my current problem? | 14:45:53 |
| @piegames:matrix.org | How does by-name work around this? | 14:46:01 |
| @piegames:matrix.org | While I do approve of the function-as-attrset idea, I have a very strong aversion towards underscoreunderscore magic attribute names, and generally want to see less of them in the language | 14:47:29 |
| infinisil | piegames: The attribute names of pkgs/by-name don't depend on final, they're only computed using lib | 15:28:58 |
| infinisil | See https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/by-name-overlay.nix | 15:29:17 |
| @piegames:matrix.org | but it does self.callPackage? | 15:30:10 |
| infinisil | piegames: It doesn't need that to compute the attribute names though | 15:31:47 |
| infinisil | It's only the attribute values defined using callPackage, which is the same as all-packages.nix | 15:32:15 |
| tomberek | making it a builtin is another way to do it | 15:33:07 |
| @piegames:matrix.org | But what is one puts some by-name/callPackage in there? (hypothetically) | 15:34:39 |
| infinisil | piegames: The order of overlays would determine which one gets the final (hah) say: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/stage.nix#L284-L295 | 15:37:49 |
| @piegames:matrix.org | So my idea would work if I represent it as an overlay? | 15:38:17 |
| infinisil | Oh but also, there's CI to ensure all of pkgs/by-name are derivations | 15:38:23 |
| infinisil | piegames: Only if the attribute names of the overlay don't depend on final | 15:38:55 |
| @piegames:matrix.org | So I am basically pushing down the trust/invariant to the files being imported. Which sounds doable | 15:39:49 |
| infinisil | Btw here's a simplified example of the problem:
nix-repl> lib.fix (lib.extends (self: super: { y = 10; } // self.x) (self: { attrs = { z = 10; }; }))
| 15:40:16 |
| @piegames:matrix.org | Okay now I slowly begin to understand the situation and the difference to by-name. In the latter case, the names are static as file paths | 15:40:42 |
