| 11 Oct 2023 |
 @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 |
| infinisil | It might though, lazy attribute sets allows fancy things | 16:09:17 |
| infinisil | Anyway, my opinion on the originally stated problem is that support for package sets should be improved generally, and inheriting such attributes into the top-level set shouldn't be done | 16:10:06 |
| @piegames:matrix.org | I think it would be feasible with the hack Jade mentioned, of evaluating once with dummy values first:
// (
let mySet = callPackage myPath; in
mapAttrs (name: _: mySet.${name}) callPackageDummy myPath
)
This works as long as the package set function's keys do not depend on its inputs, and no inputs are otherwise forced to generate the output keys (so, no assertions at the top for example)
| 16:24:26 |
| @piegames:matrix.org | * I think it would be feasible with the hack Jade mentioned, of evaluating once with dummy values first:
// (
let mySet = callPackage myPath; in
mapAttrs (name: _: mySet.${name}) (callPackageDummy myPath)
)
This works as long as the package set function's keys do not depend on its inputs, and no inputs are otherwise forced to generate the output keys (so, no assertions at the top for example)
| 16:24:39 |
| * infinisil would rather not 😅 | 19:38:01 |
| @piegames:matrix.org | b-but | 19:38:56 |
