| 11 Oct 2023 |
 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 |
| Robert Hensing (roberth) | unfortunate :/ | 15:59:33 |
| infinisil | Hmm but even then it's not perfect, PR's before the introduction of the pkgs/by-name check wouldn't be failing :/ | 16:42:26 |
| infinisil | Alternative is to somehow force all PR's to be rebased | 16:42:57 |
| infinisil | Or even automatically rebase? No that would mess with GPG signatures | 16:43:36 |
| infinisil | Merging master automatically into each PR? No that would be a super messy history | 16:43:50 |
| infinisil | Maybe it's possible to just kind of associate a new failing check run with PR's that should be rebased | 16:44:47 |
| infinisil | Let me try experimenting with that | 16:45:18 |
| infinisil | Aha! This looks pretty good https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28 | 16:49:02 |
| infinisil | This is such a general problem, I'm amazed it isn't solved yet..
Well, there is a solution, it's merge queues | 16:51:22 |
