| 11 Oct 2023 |
 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 |
| Robert Hensing (roberth) | is it using pull_request_target? If not, maybe that helps? | 13:48:02 |
| Robert Hensing (roberth) | it runs in the context of the base | 13:48:12 |
| Robert Hensing (roberth) | I would assume they mean the tip of the base branch, but maybe that's exactly what you're running into | 13:48:38 |
| infinisil | Robert Hensing (roberth): It does use pull_request_target, but restarting the job doesn't seem to affect the workflow file used, even if the base branch changed it | 14:51:21 |
| infinisil | Here's my test: https://github.com/tweag/nixpkgs/pull/74
This PR was done against a base branch that had a working check at first, but then I committed a change to break it: https://github.com/tweag/nixpkgs/commit/4276e597262ddfcf5dce1c4050a2ca999e950a45 | 14:52:35 |
| infinisil | But retriggering the check from https://github.com/tweag/nixpkgs/actions/runs/6500830578/job/17657034351?pr=74 doesn't cause it to fail still | 14:53:03 |
| infinisil | But it did use an updated base branch, just due to how it fetches the merge ref, which github always updates automatically:
- Before base update: https://github.com/tweag/nixpkgs/actions/runs/6500830578/attempts/1?pr=74#summary-17657001189
- After base update: https://github.com/tweag/nixpkgs/actions/runs/6500830578?pr=74#summary-17657034351
(note how the stated base branch commit changed)
| 14:55:13 |
