| 19 Aug 2025 |
 jade_ | awesome | 18:43:09 |
 Rutile (Commentator2.0) feel free to ping | is it relevant for me to know what you are (planning to) doing? | 18:45:26 |
 helle (just a stray cat girl) | sweats profusely at this idea oh no jade, I am worried | 18:45:54 |
| jade_ | setting dontWrapPythonPrograms = true on it | 18:47:15 |
| jade_ | globally | 18:47:19 |
| Rutile (Commentator2.0) feel free to ping | raitobezarius: can you punch ci/pipeline for 3992? it just says "verfied -1" without any explenation and doesn't update on push | 18:47:25 |
 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 | 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 | 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 |
