| 8 Jan 2025 |
 Lucas Eduardo | Actually I did a treewide migration but the PR is too big to be mergeable at once | 17:37:35 |
| Lucas Eduardo | And I am working on adding the check to nixpkgs-vet | 17:37:57 |
| Lucas Eduardo | But I suck at rust | 17:38:09 |
| Lucas Eduardo | Infinisil suggested me to create a ratchet rule, I added many tests there already but I can't figure out how to integrate a ratchet which parses nix | 17:39:08 |
| Lucas Eduardo | Normal rules I was able to somewhat make it work because most of the logic is there but with ratchet I can't figure out how this dependency injection magic works lol | 17:39:46 |
| Lucas Eduardo | For context, the nixpkgs-vet PR: https://github.com/NixOS/nixpkgs-vet/pull/142 | 17:40:25 |
| Lucas Eduardo | That's the treewide nixpkgs PR, which I call big chungus, https://github.com/NixOS/nixpkgs/pull/371665 | 17:41:29 |
 infinisil | Lucas Eduardo: Wanna do a call right now to try figure it out together? | 19:12:01 |
| Lucas Eduardo | Right now I can't. I just finished a few work meetings. | 20:16:25 |
| infinisil | Lucas Eduardo: I'll push something later for you to look at :) | 20:18:22 |
| infinisil | https://github.com/NixOS/nixpkgs-vet/pull/142#issuecomment-2578802706 | 22:45:36 |
| 9 Jan 2025 |
| Lucas Eduardo | I was able to do the validation standalone in a simple CLI app | 12:20:53 |
| Lucas Eduardo | I linked it on the PR | 12:21:04 |
| Lucas Eduardo | Now I just need to integrate it into the PR | 12:21:20 |
| Lucas Eduardo | Maybe tweak up a little the message | 12:21:52 |
| infinisil | @lucasew:matrix.org I hope you saw https://github.com/NixOS/nixpkgs-vet/pull/145#discussion_r1908639140 :)
| 12:55:32 |
| Lucas Eduardo | I saw it and it will help a lot | 12:58:14 |
| Lucas Eduardo | Thank you | 12:58:16 |
| Lucas Eduardo | I rebased my PR on this but I am having a difficulty in this final part | 14:35:22 |
| Lucas Eduardo | https://github.com/NixOS/nixpkgs-vet/pull/142#discussion_r1908920546 | 14:36:13 |
| Lucas Eduardo | I created the comment for the permalink | 14:36:22 |
| Lucas Eduardo | I think I got it but | 15:10:34 |
| Lucas Eduardo | There is a path issue | 15:10:43 |
| 10 Jan 2025 |
| Lucas Eduardo | Well, the tests are running lol | 02:34:25 |
| Lucas Eduardo | But I still think I didnt got it right | 02:34:36 |
| Lucas Eduardo | Maybe if we move the part of blockage of rules to the problems themselves and then the validators deliver those problems directly then when collecting them we filter for only files or attrsets or stuff like that that had an issue | 02:38:13 |
| Lucas Eduardo | It's happening | 03:13:40 |
 DavHau | Hey Folks, I have a question regarding splicing.
I am recently hunting cross related issues and I'm trying to wrap my head around why it works how it works.
My question is: Why do we add __spliced to packages by traversing the top-level?
eg, why is splicing not done in mkDerivation? Why is not every package spliced by default? Wouldn't that be simpler?
The problems I currently see:
- Everything that is not in the top level package set is not spliced.
- dynamic interactions like overrides seem to break splicing (no
__spliced after overriding).
It seems to me that this would not be an issue if mkDerivation itself would take care of the splicing. But probably I'm missing something and I would like to understand what.
John Ericson infinisil Robert Hensing (roberth)
| 03:58:21 |
|  connor (he/him) (UTC-7) joined the room. | 04:41:29 |
|  xanderio joined the room. | 09:16:16 |
