| 14 Jul 2025 |
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 |