| 28 Oct 2025 |
 fzakaria | any good issues I can work on? | 01:58:23 |
| fzakaria | I finished that NAR thing. | 01:58:26 |
 tomberek | @fzakaria:one.ems.host: perhaps a more long term solution to:https://github.com/GrahamDennis/nix/pull/8. We got team approval for "final" to be exposed so that locked fetches don't force a refetch if it already exists. | 02:10:55 |
| fzakaria | expose final to the lock file ? | 02:12:59 |
| fzakaria | or it sounds like assign final to the fetchers if the attrs have whatever flake considers to be final | 02:13:21 |
| fzakaria | (I'm not familiar with this feature so reading in between the lines of the PR)
| 02:13:38 |
|  connor (burnt/out) (UTC-8) changed their profile picture. | 02:19:16 |
| connor (burnt/out) (UTC-8) changed their profile picture. | 02:19:57 |
| tomberek | The idea is that builtins.fetchTree would accept a final = true; parameter and this would signal that the other parameters given (like revCount, lastModified, etc) would be accepted as is when a local store path matches the given narHash. Otherwise what happens is that that source would need to be re-fetched all the time (eg: if the fetcher cache is cleared out) even though the narHas/store-path exists locally, just to fetch those other attributes that are usually provided in a flake.lock/npins/niv/etc situation. In other words, "if final is true, don't bother refetching this source and trust the lockfile's attributes'. | 03:46:23 |
 lovesegfault | Okay, John Ericson Sergei Zimmerman (xokdvium) this is the next step in the grand why-depends-cycle-finding-unification. It's a lot of code, but it's mostly a shim around BGL. You can see the whole work with why-depends here: https://github.com/NixOS/nix/compare/master...lovesegfault:nix:bgl-depgraph | 03:51:56 |
| lovesegfault | I need to look more at why-depends, maybe there's more stuff in there I can reuse the graph for | 03:52:57 |
| lovesegfault | I kinda want to make it always precise, and then non-precise just tosses data out :P | 03:58:02 |
|  lunarizzz joined the room. | 07:49:26 |
| fzakaria | you want to pair on this? | 18:01:18 |
| fzakaria | having a test that shows it download first might be a good step first (capture the regression) | 18:01:32 |
| fzakaria | Redacted or Malformed Event | 18:17:15 |
| fzakaria | what's this new codderrabbit stuff.. | 18:18:49 |
 Robert Hensing (roberth) | Mic92: ^ | 18:21:14 |
| Robert Hensing (roberth) | it's opt-in but quite noisy nonetheless | 18:21:37 |
| Robert Hensing (roberth) | could it be configured not to post that comment? | 18:22:04 |
| fzakaria | or if the template for a PR could include whatever you need to toggle it | 18:24:24 |
| fzakaria | and we just exclude it from posting then -- so people can still find it | 18:24:33 |
 Sergei Zimmerman (xokdvium) | In reply to @roberthensing:matrix.org
could it be configured not to post that comment? Yeah, that was the intention I believe. It can be configured in-repo like mergify. Feel free to send a pr | 18:31:51 |
 Taeer Bar-Yam | In what sense is it opt-in? It ran on my MR and I didn't opt in | 20:02:06 |
 Mic92 | In reply to @roberthensing:matrix.org
Mic92: ^ It was only doing auto review until we had a chance to turn off. I had to go through an org owner though because, i can't configure anything. | 20:06:03 |
| Taeer Bar-Yam |
- Will other people be able to request it's reviews on my PRs?
- Will this be socially acceptable?
| 20:07:22 |
| Taeer Bar-Yam | *
- Will other people be able to request its reviews on my PRs?
- Will this be socially acceptable?
| 20:07:37 |
| Mic92 | Maintainers can request it. The way i do it usually is to triage the responses myself upfront. | 20:09:45 |
| Sergei Zimmerman (xokdvium) | @Mic92 can we also make it stop spamming “auto-review disabled” please | 20:13:50 |
| Mic92 | I'll ask. I had a person reaching out to me. | 20:18:34 |
