| 14 Jul 2025 |
 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 |
| GGG | * like in the nodejs world there's mkYarnDeps and fetchNpmDeps | 18:35:50 |
| Corngood | what do you mean by "its own builder" exactly? like using plain stdenv? | 18:36:03 |
| GGG | I mean as in making nugetDeps be a derivation that the builder then accesses to add the nuget deps to path, instead of a wrapper | 18:36:33 |
| Corngood | what is the builder though? | 18:36:49 |
| GGG | then move the nuget env setup to a hook | 18:36:50 |
| Corngood | oh, you mean just with hooks? like a dotnet-sdk hook? | 18:37:19 |
| GGG | yeah, make a hook to setup the nuget env to use the packages that will be in the path that will be passed with nugetDeps | 18:37:45 |
| Corngood | that's mostly already done for e.g. avalonia | 18:38:03 |
| GGG | instead of what we have with addNugetDeps, so that people have more control over how the nuget deps are set up and patched | 18:38:03 |
| Corngood | configureNuget. there's just currently no buildPhase=dotnetBuildPhase or anything like that | 18:38:35 |
