| 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 |
| GGG | yeah, but I was thinking of making it its own builder instead of a wrapper around mkDerivation | 18:35:28 |
| GGG | like in the nodejs world there's mkYarnDeps | 18:35:39 |
| GGG | * like in the nodejs world there's mkYarnDeps and `mkNpmDeps | 18:35:45 |
