| 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 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 |
| WeetHet | * I can probably run nix develop and execute phases myself but it's a pain and I would rather prefer that I don't | 15:05:57 |
 Tristan Ross | You can use the --keep-failed flag and then try debugging it through the tmp directory it put the build in. | 15:06:32 |
| WeetHet | The environment isn't preserved though | 15:07:41 |
| Tristan Ross | In reply to @weethet:catgirl.cloud
The environment isn't preserved though It saves the environmental variables | 15:08:20 |
| Tristan Ross | You can source those | 15:08:28 |
| WeetHet | Wait it does? | 15:08:44 |
| Tristan Ross | Yes | 15:08:51 |
| emily | what would you do to debug/fix it that wouldn't change the original derivation anyway? | 15:08:57 |
| Tristan Ross | env-vars is the file | 15:09:10 |
| WeetHet | Skipping tests that require network/flaky tests | 15:09:33 |
| WeetHet | To be fair, it's probably a non-issue when you have something like crate2nix | 15:10:33 |
