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 |
| kjeremy joined the room. | 13:30:18 |
11 Jan 2025 |
Lucas Eduardo | In reply to @hsngrmpf:matrix.org
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)
What is the deal with splicing? What is it? Is there any doc around the concept? | 22:44:45 |
Philip Taron (UTC-8) | It's not a doc, but I found this whole thread worth reading.
https://discourse.nixos.org/t/frustrations-about-splicing/49607 | 23:00:25 |
12 Jan 2025 |
| @strutztm:strutztm.de joined the room. | 00:25:08 |
14 Jan 2025 |
Robert Hensing (roberth) | I'm not aware of any blockers, but it's the kind of thing where not many of the possible solutions are correct... | 08:24:13 |
15 Jan 2025 |
| SomeoneSerge (Ever OOMed by Element) changed their display name from SomeoneSerge (utc+3) to SomeoneSerge. | 19:02:41 |
16 Jan 2025 |
| FliegendeWurst (@GPN23) joined the room. | 09:38:55 |
Lucas Eduardo | interesting
nixpkgs-vet only reports an error in ratchet if the error was introduced by the change
if the error appeared in base and main has changed in a way that it didn't change the error state it will not raise a failure
like if you change code that is in tree of a top level with lib, the bad state is already there so if someone touches that code in any way it will not be reported
it will only report if the issue wasn't happening on that file and the change introduced it
interesting | 18:22:17 |
Lucas Eduardo | * interesting
nixpkgs-vet only reports an error in ratchet if the error was introduced by the change
if the error appeared in base and main has changed in a way that it didn't change the error state it will not raise a failure
like if you change code that is in tree of a top level with lib, the bad state is already there so if someone touches that code in any way it will not be reported
it will only report if the issue wasn't happening on that file and the change introduced it
| 18:22:26 |
Lucas Eduardo | actually what I wanted was for it to notify about the error if any code inside a top level with is changed, but if it's not necessary it's fine by me | 18:24:31 |
Alyssa Ross | that sounds like it would be extemely annoying to anybody making changes that are not refactorings | 19:35:35 |