| 10 Jan 2025 |
 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 |
 emily | that's not really a ratchet check then is it? | 20:07:00 |
| emily | a ratchet is about ensuring that instances of a pattern can only monotonically decrease rather than increase | 20:07:18 |
| emily | your proposal would make it impossible to do treewide refactorings because every time you remove bad pattern X across the tree the linter complains that you didn't fix bad pattern Y :) | 20:07:55 |
| 17 Jan 2025 |
| Lucas Eduardo | Fair enough | 20:31:45 |
| Lucas Eduardo | So the way it is it's better | 20:31:54 |
| Lucas Eduardo | Right now it will only fail if a file that didn't have the problem started having | 20:32:48 |
| 18 Jan 2025 |
 infinisil | My vision for nixpkgs-vet is that is also starts being able to automatically migrate deprecated patterns | 21:06:17 |
| 19 Jan 2025 |
 WeetHet | Why is checkPhase a part of the derivation build process? It feels like having another derivation which is being fed with the intermediates of the package derivation so disabling/experimenting with tests wouldn't require rebuilding the derivation is a better idea? | 14:39:14 |
| emily | yes in principle, but many technical issues | 14:55:35 |
| emily | intermediates can be huge, for one thing | 14:56:38 |
| emily | installCheckPhase is easier to factor like this | 14:56:38 |
| WeetHet | Some derivations take 1h+ to build and debugging checkPhase is basically impossible | 15:04:14 |
| WeetHet | I can probably run nix develop and execute phases yourself but it's a pain and I would rather prefer that I don't | 15:05:29 |
