| 11 Oct 2023 |
@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 |
infinisil | Just an overlay and a fixed-point function, but this causes infinite rec because the attributes of the overlay depend on final/self | 15:40:51 |
@piegames:matrix.org | Therefore it is not possible to just enforce this as an invariant, since it will already blow up once there is the possibility of this happening? | 15:43:44 |
@piegames:matrix.org | So for example, importing a file with an attribute set where every attribute function is a callPackage-callable function would be fine again, because then I can import the attrset and force its attributes without requiring callPackage and the packages itself. But that would be quite a sad thing to do … | 15:45:26 |
@piegames:matrix.org | In reply to @infinisil:matrix.org
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; }; }))
How would this one work with lazy attrnames? How does the evaluation semantic of // even look like then? | 16:02:48 |
infinisil | piegames: I don't thin that would work like that with lazy attrs | 16:04:08 |
infinisil | You can try out lazy attrs btw, https://github.com/NixOS/nix/pull/4154 should be in a working state, even if it's outdated | 16:04:49 |
@piegames:matrix.org | But then how would lazy attributes help with my problem? | 16:04:52 |
tomberek | it allows making a "dynamic inherit" without statically knowing the attrnames up front | 16:05:25 |
infinisil | Hmm yeah though I'm actually not sure now if it would actually allow what piegames wants here | 16:08:53 |