| 19 Aug 2025 |
 raitobezarius | yes it is | 18:43:05 |
 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 |
