| 11 Oct 2023 |
 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 |
| @piegames:matrix.org | This is so great | 19:39:01 |
| @piegames:matrix.org | (Actually I unironically don't find it that bad, or at least not significantly worse than having to manually track attributes in all-packages.nix) | 19:39:40 |
| infinisil | I'd rather fix the core issue than swap out hacks for other hacks | 19:44:37 |
 Robert Hensing (roberth) | What's nice about the inherit is that the evaluator doesn't need to open and parse any extra files to figure out the attribute names | 21:11:25 |
| Robert Hensing (roberth) | probably no big deal for one file, but could be bad if it becomes a widespread pattern, particularly because there'd be no incentive to keep the file small | 21:12:15 |
| Robert Hensing (roberth) | * probably no big deal for one file, but could be bad if it becomes a widespread pattern, particularly because there'd be no incentive to keep those files small | 21:12:26 |
| 12 Oct 2023 |
| infinisil | https://github.com/NixOS/nixpkgs/pull/256792 is now ready to review, this is the next step towards migrating all packages | 00:31:45 |
| 13 Oct 2023 |
| infinisil | This is slowly breaking my brain, but I think I know what to do now.. https://github.com/NixOS/nixpkgs/issues/256788#issuecomment-1760610982 | 01:07:17 |
