| 1 Jul 2025 |
 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 |
| GGG | and we'd remove the indirection with addNugetDeps | 18:34:11 |
| GGG | (and as a bonus, make people able to change the patchPhase and fixupPhases of nuget deps) | 18:34:40 |
| Corngood | addNugetDeps is there so that it can be used outside of buildDotnetModule | 18:35:01 |
