| 14 Jul 2025 |
 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 |
| GGG | oh, my bad, I misunderstood what addNugetDeps did, I misrembered what it did | 18:39:39 |
| Corngood | I'm just not sure how you'd handle fetching without a wrapper around the derivation like addNugetDeps | 18:39:46 |
| GGG | I thought it set up env vars and stuff, but no, it just adds things to buildDeps | 18:39:52 |
| Corngood | yeah, just that and adding fetch-deps plus the derivation override that it uses for that | 18:40:22 |
| GGG | my plan was to make something like nugetDeps = mkNugetRepo ./deps.json; and then a hook would set up the env var for dotnet restore to use | 18:41:05 |
| Corngood | I would really like things to be more composable. like avalonia with multiple npm projects and nuget deps | 18:41:09 |
| GGG | exactly how it is done with npm and yarn | 18:41:22 |
| GGG | because they aren't added to buildDeps afaik | 18:41:45 |
| GGG | I'm not sure if that's right or wrong (I assume wrong most likely), but that'd make it easier to override them out, because otherwise the only choice people would have is to filter out the old buildDeps | 18:42:26 |
| GGG | * I'm not sure if that's right or wrong (I assume wrong most likely), but that'd make it easier to override them out, because otherwise the only choice people would have is to filter out the old buildDeps and add new ones | 18:42:38 |
