| 19 Aug 2025 |
 emily | I'm pretty sure nixpkgs-review on a pytest change will rebuild most of the package set | 18:47:27 |
 jade_ | i also think this will happen :P | 18:47:36 |
| emily | I would recommend testing direct dependencies only (which will still be a billion things) | 18:47:37 |
 raitobezarius (DECT: 7248) | In reply to @commentator2.0:elia.garden
raitobezarius: can you punch ci/pipeline for 3992? it just says "verfied -1" without any explenation and doesn't update on push it's the ASAN flakiness | 18:48:05 |
| jade_ | hm, is there a way to bazel uquery 'rdeps(//:pytest)' in nix? | 18:48:06 |
| raitobezarius (DECT: 7248) | i kicked it again | 18:48:08 |
| emily | trofi has a script lying around somewhere. you can also just rg | 18:48:29 |
| emily | there is a simple design that could be used to add a --depth argument to nixpkgs-review I cooked up a while ago | 18:48:39 |
| emily | but nobody has offered to get nerd sniped into implementing it | 18:48:45 |
| jade_ | okay, that's fair. hm, i wonder if i can write a treesitter query for it actually | 18:48:48 |
| jade_ | worth learning it | 18:48:51 |
| emily | well the hard part is not finding the files. | 18:48:57 |
| emily | the hard part is knowing how to build those files | 18:49:01 |
| emily | thankfully by-name and python-modules have fairly uniform structure | 18:49:11 |
| jade_ | hm, intersection of "meta.position" and attr paths? | 18:49:23 |
| jade_ | i wish we had tooling for operationalizing that type of thing | 18:49:29 |
| emily | position doesn't tell you what overrides might apply, etc. | 18:49:39 |
| emily | the correct solution is to do it by .drv, which is how nixpkgs-review --depth would work if someone felt like implementing it | 18:49:52 |
| jade_ | oh sure, i just want to know attr names that come from a given file name | 18:49:53 |
| emily | you can just arrange the graph of changed .drvs such that you only test things that aren't changing only because something upstream changed, and tier those so that --depth 1 builds directly changed packages, --depth 2 builds packages that use directly changed packages, --depth 3 builds packages that use those, etc. | 18:50:47 |
| jade_ | https://github.com/Mic92/nixpkgs-review/issues/554 filed a bug so that it's at least tracked where someone might find it if they're bored | 18:52:25 |
| jade_ | how does it match drvs? trivially by name or by similarity metric plus name or? | 18:52:46 |
| emily | I had a more written up design somewhere but not to hand. I think you do not actually need to match .drvs at all | 18:53:15 |
| emily | like it's something approximating "cut off things that mention the .drvs you are rebuilding in this tier". and the lowest depth is, rebuild packages that do not mention any .drvs that are present in the before eval | 18:54:32 |
| emily | though that would punt things you directly change but that depend on other things you directly change to the next depth | 18:54:46 |
| emily | to avoid that you'd need to match up .drvs yeah | 18:54:58 |
| jade_ | mmm | 18:55:41 |
| jade_ | the lack of ability to get metadata into drvs is rather irritating | 18:55:51 |
 K900 | I have like 80% of this in nix-drv-index tbh | 18:56:42 |
 aloisw | In reply to @raitobezarius:matrix.org
oh lol vcunat intervening in that commit in the comment area I remember a staging-next breaking due to the introduction of incorrect floating-point behaviour in unrelated code. | 19:50:50 |
