| 14 Jul 2025 |
 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 |
| Corngood | it's difficult to think about without some concrete examples. I was hoping to get more libraries in nixpkgs and actually use them (like avalonia) | 18:43:44 |
| Corngood | I just haven't been able to put much time into it lately | 18:44:02 |
| GGG | yeah, although I have to admit I'm rather skeptic about people actually building libraries from source and having them in nixpkgs | 18:44:19 |
| GGG | python and node.js folks have tried (and failed) | 18:44:30 |
| Corngood | the whole dotnet ecosystem is very hostile to it | 18:44:34 |
| GGG | that too | 18:44:43 |
| Corngood | even worse than those other languages, because there's no mechanism for distributing or building source | 18:45:22 |
