| 30 Jun 2025 |
 Matt Sturgeon | It looks like the same errors occasionally shows up in upstream's CI too. E.g. here | 17:35:27 |
| Matt Sturgeon | * It looks like the same (or similar) errors occasionally shows up in upstream's CI too. E.g. here | 17:39:46 |
| 1 Jul 2025 |
 Corngood | In reply to @mattsturg:matrix.org
I'm wondering if it is practical to move the tests into a passthru.tests derivation 🤔
That way 1) end-users wouldn't need to run the tests to build the unfree package, 2) intermittent tests wouldn't cause build failures on hydra.
I'd still like to uncover the actual issue, but I'm curious if extracting the tests to a separate derivation is possible?
I guess the test derivation would need the same src as the main package, to access the test cases and relevant build properties. It'd also need the main package as an input, to get the built binaries.
That sounds reasonable, but what I'm unsure of is how easy it'd be to tell dotnet test to run the local test cases against the pre-built binaries from the main package?
One way to do this would be to disable tests and just put an override with them enabled in passthru.tests.
Is it consistently crashing in certain tests? Maybe we can get away with disabling only certain tests or projects? | 01:19:19 |
| Matt Sturgeon |
One way to do this would be to disable tests and just put an override with them enabled in passthru.tests.
Good idea. I've opened https://github.com/NixOS/nixpkgs/pull/421459
Overriding is a simple solution, but it means building the app twice... I was hoping we'd be able to reuse the binaries from the main package, as an input for the test package.
Is it consistently crashing in certain tests? Maybe we can get away with disabling only certain tests or projects?
I'm not sure; I don't think it prints which test failed in the logs. It might be hidden in the v:diag logs somewhere though. I also suspect it is a specific test or project, so if we can identify it we can disable it and report the issue upstream.
| 10:37:33 |
| 6 Jul 2025 |
|  JamieMagee joined the room. | 02:25:27 |
| 11 Jul 2025 |
|  felschr left the room. | 16:52:34 |
| 14 Jul 2025 |
|  znaniye joined the room. | 13:17:33 |
| znaniye | Hey, what can i do if i need to overrideAttrs nugetDeps? Has anyone here ever been in this situation? | 16:59:18 |
 K900 | Why? | 17:19:22 |
| Corngood | Is it definitely broken? I'd like it to work. | 17:21:19 |
| znaniye | Due to this, i mean.
Overriding nugetDeps is just one example that caused issue. For example overriding projectFile wouldn't work either...
| 17:33:00 |
| znaniye | Or any other attribute from that list | 17:34:14 |
| Corngood | I guess we either need to pass all these attributes through, or add something like `overridePythonAttrs`.
I don't love either of those options | 18:03:47 |
 GGG | probably something like overrideDotnetAttrs | 18:04:18 |
| GGG | making it works with plain overrideAttrs would require to move any and all logic done in nix in buildDotnetModule over to bash which would make it much worse | 18:05:04 |
| Corngood | It doesn't actually have to be in bash, but it needs to use finalAttrs, and stuff would get leaked into bash | 18:24:14 |
| GGG | that feels like it'd end up being a major mess | 18:24:38 |
| GGG | a mix of finalAttrs and non-finalAttrs usage or some other type of hack | 18:25:04 |
| znaniye | By removing line 215 locally, shouldn't I then be able to override nugetDeps properly with overrideAttrs? | 18:30:36 |
| Corngood | Possibly not, if it's not using finalAttrs.nugetDeps | 18:31:01 |
| znaniye | just to see things working | 18:31:04 |
| GGG | no, because what you want to affect is on line 233 | 18:31:15 |
| znaniye | oh, i see | 18:31:34 |
| Corngood | Here's an issue about python moving away from overridePythonAttrs to overrideAttrs: https://github.com/NixOS/nixpkgs/issues/379602 | 18:32:02 |
| GGG | it'd only work if it was something like inherit (finalAttrs) nugetDeps; | 18:32:02 |
| GGG | I see, I didn't know overridePythonAttrs was discouraged | 18:32:45 |
| Corngood | I was hoping extendMkDerivation would help with this sort of thing, but it doesn't. | 18:32:48 |
| Corngood | I think the current situation is that override, overrideAttrs, and overridePythonAttrs don't really work together intuitively. | 18:33:26 |
| GGG | for the general refactoring I was planning for nuget deps, I think we could solve both problems with it, since I was planning to make it be something like nugetDeps = mkNugetDeps ...; which then the hook would read directory to access the folder with the nuget deps | 18:33:45 |
| GGG | that way it'd work with overrideAttrs and we wouldn't need to change anything to use finalAttrs | 18:34:03 |
